On Thu, Oct 09, 2008 at 12:13:02PM -0400, Eben Eliason wrote: > On Thu, Oct 9, 2008 at 10:15 AM, Carlos Nazareno <[EMAIL PROTECTED]> wrote: > > Hi Tomeu. Some personal feedback: > > > >> 3) Basically - The journal is really hard for people/ kids to use over > >> a longer period of time. Kids and teachers can't find things that they > >> did unless it was done within the last 30 minutes. > >>Could you please elaborate on the difficulties that people have when > >>using the journal? > > > > I've experienced the same problem. Items tend to clutter up in the > > journal over time, it's like viewing your entire web browsing history. > > Its current implementation simply leads to information overload with > > the accumulating number of entries. > > > > IMHO, the philosophy of "nothing gets forgotten" with the journal is a > > bit flawed because as people we don't even naturally do that. We > > selectively choose which information to remember and mark as important > > and discard the rest because that's just information overload. > > You're right on with this comment. Of course, I don't think "nothing > gets forgotten" is really what we're aiming for; in fact, we aim for > much the opposite. However, as it's currently implemented, you're > right! The Journal is actually supposed to retain everything you've > done *quite recently* so that you can always go back and find, remix, > resume, etc. Experimentation is encouraged. > > However, the very principles the Journal was designed around include > the concept of memory, and particularly the fading thereof. Over > time, less used, unstarred, unimportant files will eventually be > backed up and then removed (probably after confirmation, but perhaps > you can opt out of the confirmation step) by the system, so that the > further back in time you look, the less you have left, but the more > relevant the remaining items are to your history with the laptop. > > This is a very important aspect of the Journal that just hasn't had > time to happen, yet. >
You acknowledge that the system is not functioning as well as it should be in its curren state. Please stop saying "we are going to do this" and look for the simplest way to achieve a usable system for our usesr. I will gladly help in this endeavor, but I am concerned by our security system and the frequent implications that we are holding to old designs that my ideas and motivation have no place in this effort. I don't think we can incorporate the concept of memory and forgetting into the Journal in a programmatic way. Forgetting is as much a learned skill as remembering, and attempting to replicate it in software seems like a very difficult, if impossible, task. I feel that we are tilting at windmills if we believe we can reliably produce something so incredible in any conceivable timeframe. I positively advocate a simplification of our expectations about what the Journal will do. Just a system which consistently suggests (but does not enforce) default, intelligent organizations for things in a traditional filesystem, provides manual and automatic tagging support, and indexes the text of written documents will be a giant step forward in terms of reliability and interoperability with the outside world. With metadata about files stashed in a database, such as time, date, text (for indexing and search), tags, creating application, etc. we can do everything the Journal is intended to do, but no sacrifice the simplicity and reliability of the default filesystem in the process of developing the Journal to its full capacity. For this we only need to work on three sets of components: 1) Journal -- a file browsing application which provides numerous views onto the corpus of data the user creates and handles; views being time-ordered, filtered, hierarchical (traditional), tag-based, etc. Allowing other applications to manage files will let contributors create or port existing systems to the Sugar environment to fulfill these functions as well. 2) Indexer -- a simple filesystem crawler that walks across the set of directories to which users are expected to save data (e.g. not Activity directories or hidden directories in /home) and executes plugin scripts which produce indexable metadata and fulltext for use in later searches by the user. The scripts can have a standard IO format, such as used by tracker, and can be installable by inclusion in Activity bundles. 3) Watcher -- a filesystem watcher which uses inotify to watch for changes in the set of directories to which the student writes data. On change, invokes the indexer, which then executes the corresponding metadata / fulltext extraction scripts and adds the file in question to the index accessible and searchable by the Journal. I feel that we are moving in this direction, but to really get there so much has to change in the architecture of Sugar that I am afraid that this work will be unsupported and renegade in flavor. I am furthermore frustrated by the tight integration of the Journal into the window manager. In particular, our security model has the effect of preventing work on this issue that isn't supported by all the core developers. We can only have one file management application. I am afraid that I or another interested developer will implement such systems but find they are rejected by the core developers, and it will be impossible even for users desire to use them to easily do so. Erik _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
