Marco Pesenti Gritti wrote:
Remember, we're not starting from a desktop of discrete files which you
need to open. Stuff in the journal will save what activity you last
worked on something with, and that's how it will know how to get back to
it.
What about files that were not created on an OLPC, such as oggs,
theoras, pdfs, or other media? I'm writing an RSS reader for OLPC, and
it downloads files contained in RSS enclosures. If there's no mimetype
database on the system, it seems to cut olpc off from the rest of the
world's content.
The problem of the compatibility with external content is a real one and
something we will have to think about hard. There are two ways to go
about it.
1 Decide on abstract basis that we need a file type - application
association -> Imagine use cases for it and on the base of these define
the exact requirements -> Implement a mime system.
I find it hard to avoid this entirely. For instance, imagine we have a
flashcard activity (not too much of a stretch). It seems like an
obvious implementation to put flashcard data on the web somewhere, as
type application/xml+x-flashcard (or whatever), and then import the data
when that data type is encountered through a browser.
(Question: if so, does the browser query the user about what to open, or
does the activity automatically get opened with the data and the
activity should query the user about what to do? In the case of
importing data, *some* confirmation should happen somewhere. But only
the activity really knows what the data might be used for, so only the
activity can ask for an accurate confirmation.)
2 Define the user experience, i.e. figure out how we want to integrate
external content inside activities in concrete (for example, what do we
want to happen when the user click a link to a pdf file in the browser?)
-> Architect a simple system that can satisfy these requirements ->
Implement it
I don't see how we can reasonably justify specially setting up a
customized system for dealing with flashcard data. Setting up special
sharing mechanisms for every activity also seems difficult.
In the case of flashcards, I'd imagine the application would be both
authoring tool and testing at the same time. But then I would imagine
you would either manually upload the data to a wiki, or the activity
would have some automatic way to upload it to some wiki you've already
specified as your "home" wiki. But from there I think it would be best
if it really was just embedded in the wiki. So the activity wouldn't
have to build in a flashcard data browser, it wouldn't have to provide
all the necessary context for the data, or any of that -- just uploading
(maybe), and rely on all of a wiki's natural talents to provide the rest
of the structure.
IHMO all that the first approach can bring is an over-engineered system
and a disastrous user experience.
I think this all seems rather abstract because the journal/storage
system has not been spec'd out or implemented. Once that happens I
expect these issues to become more prominent. That said, perhaps it is
best we defer this conversation until then.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
