Marketing Team/Events/Sugarcamp Boston 2008/Minutes
Presence Scalability
XS scenario
- Search based interface (Morgan Collett)
- Shrink memory footprint (Martin Langoff)
- ODBC ejabberd roaster
- Web based interface for group management
- ejabberd (seems) a convincing implementation (so far)
- ejabberd is very tweakable, configurable, extensible
- Martin working on it, ready in 6-7 weeks?
Global scenario
- Optional feature (privacy, nat, bandwidth...)
- Jabber server buried in remote control panel
- Must restart Sugar to change
eBook reader (Chris Rowe, Bernie, Martin Langoff)
- OLE Nepal asked for an application for opening, reading and browsing PDF books
- OLE Nepal uses a web-based interface to browse for content
- Martin: there are plenty of custom protocols and formats for content librararies
- Martin: the Internet is already a good enough search tool for content
- Chris: 85% of content is PDF, the rest is mostly MSWord
- Chris: OLE Nepal said: "short term, we just want a viewer + some metadata"
- How should the content be delivered to the kid? USB stick? School server? Online library?
- MStone: you can run a web server on the XO!
Remarks:
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*.)