There were two major threads in the conversation: some people decompose the problem into "finding content" and "consuming content" whereas others view these as a seamless action that occurs across multiple sessions; the latter group is primarily concerned with the ergonomics of the complete interaction.
+
+
Next, we spent some time trying to agree on a deployment scenario: some people were most interested in guided in-core content-usage scenarios whereas others were most interested in unguided server- or cloud-based content usage scenarios.
+
+
We debated whether the Journal should be extended to be a universal portal (with pluggable data layouts) or whether we should rely on disjoint screens for each content acquisition and consumption scenario. We paid particular attention to the question of whether remote/local and past/present/future opportunities should be displayed concurrently. (No consensus was reached.)
+
+
We seem to be in agreement that people want to look into the future as well as the past. It seems that we use similar UIs for doing this, so with careful problem decomposition, we should be able to share lots of code.
+
+
The closing remarks considered resource allocation: perhaps we should try hardest to adapt an existing dominant solution (e.g. Moodle) to work better in Sugar's deployment scenarios. (Specific technologies that were also considered as examples of the UIs we like include Miro, Calibre, Banshee, Eben's Journal designs, and the ICDL website.)
+
+
(Finally, the ergonomics crowd wishes to reiterate that workflows are the central -- the reader and the writer need to fully interoperate and they need to be *slick*.)