journal is hard + sugar and the digital age

Eben Eliason eben.eliason at gmail.com
Thu Oct 9 12:13:02 EDT 2008


On Thu, Oct 9, 2008 at 10:15 AM, Carlos Nazareno <object404 at gmail.com> 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.

> Think about it from a browser paradigm. You bookmark important items
> that you want to reuse later on. On the other hand, viewing your
> browser history over a prolonged period of time gets pretty unwieldy.
>
> Another problem I've had is that I tried to offload some programs onto
> an SD card due to the XO's limited internal storage. This can lead to
> hundreds to thousands of files when opening up the SD card in the
> journal. The flat heirarchy makes navigation extremely difficult when
> you have this many files.
>
> Sure, there's search, but that presupposes that you know the names of
> the files you're looking for. What if you stick in something that has
> hundreds of files and you were looking for an image file or something
> that you didn't know the name of?

There has been a lot of discussion around this idea lately.  To
summarize extremely briefly, we intend to tag all files with their
paths (implemented as "ordered tags"), so that it's possible to find
something by typing its path, or part of its path or its parent
directory, or its name, etc.  We also hope to add a dynamic tag "menu"
which, based on relative frequencies of tags, provides a
pseudo-hierarchical structure for "browsing" the contents, up to a
couple levels deep.

> Hmm. I think one improvement that can be added to the journal is to
> improve the display filters?
>
> Like for example, the ability to filter by delineated date? It would
> be a little better if users could browse the journal from a date
> range, like the range of 2 weeks to 3 weeks ago only because that's
> when the user remembers the activity that was used.

Yup.  We should do this. I'd like to see the current options in
addition to a timeline/calendar style display which allows selection
of specific ranges.  That's always been wanted, but again, has much
more implementation cost.

> Another one is the ability to view journal entries by name
> alphabetically. This would help in browsing through entries.

The latest designs (see wiki.laptop.org/go/Designs/Journal) include a
sort bar so that one can sort by title, by date, or by who you worked
with.  We'll also be adding a favorites filter quite soon, so you can
narrow down the list to "just stuff I care about".

> That being said, is there a possibility of creating a separate file
> manager activity? The reality of having to deal with files and folders
> is an inevitability that users will eventually go through once they
> grow in sophistication and interact in other digital environments like
> pcs. I think giving the idea of giving XO users the ability to view
> the sourcecode and muck around with them (a much-touted feature of the
> XO) requires a sophistication levels above navigating through and
> dealing with folders and files.

We're presently experimenting (cscott has done some really interesting
research in this area) with ways to map tags to hierarchical
structures, so that a single system can manage both.

>>could you elaborate on what means for teachers/schools/govts to
>>prepare kids for the digital age? It may be that we are not giving
>>enough importance to that requirement (?).
>
> *Interoperability with current systems.
>
> The sugar environment fosters a new "closed" paradigm/ecosystem that
> is different from pre-established paradigms. The intentional "removal"
> of the file and folder paradigm might make transitioning difficualt
> and I think users are having difficulty because of it.

I think this is fair.  However, we also didn't design Sugar foremost
to be an easy thing to transition to, but instead to be a fresh new
way of looking at data for the "uninitiated". That said, I actually
think that the solutions we're trying to build could be really
powerful, and useful to anyone, once we actually get them
right/complete.  I heard that some of the folks who attended a recent
conference in Boston heard a lecture about how many in the enterprise
sector struggle with file management in the very same ways we/kids do.

I think there are better solutions out there for everyone, if we put
enough energy into finding them.

> Also, for high school students, this means *office applications*.
> They're pretty much a requirement in private schools here where I come
> from. One of the things we hope do achieve with OLPC is to bridge the
> divide between "haves" and "have nots", and that includes giving them
> a boost in IT skills (which is one of the biggest attractions of
> OLPC). I guess that's why governments or educational ministries
> insisted that the XO be able to run windows or no go.
>
> Oh, some more observations slightly off-topic:
>
> Here in Manila, internet cafe rates are now cheap due to extreme
> popularity and proliferation. You can go surfing or playing LAN games
> for 20 Pesos/hour which is about 42 cents. Going home, I pass through
> a depressed area and there are 5 internet cafes in there.
>
> I've seen 6-8 year old street children in groups of about 3, pooling
> together money to play 3D realtime strategy games like the newest
> command and conquer or counterstrike and take turns at the seat
> playing in cafes playing. They have absolutely no problem navigating
> windows.
>
> Hole in the Wall project all over again.
> http://en.wikipedia.org/wiki/Minimally_Invasive_Education
> http://www.businessweek.com/bwdaily/dnflash/mar2000/nf00302b.htm
>
> Only this time they're playing counterstrike and blowing up tanks in
> complex 3D RTS games :-/
>
> This is not something new as groups of street kids in the 90s would
> frequent arcades and play street fighter 2.
>
> We gotta create content that will compete with that on a fun level,
> guys. The rise of casual games and the popularity of stuff like Text
> Twist and Bookworm shows that this can be done.
>
> Some info to mull over.

Thanks for all the feedback!

- Eben

>
> -Naz
>
> --
> Carlos Nazareno
> http://www.object404.com
>
> interactive media specialist
> zen graffiti studios
> naz at zengraffiti.com
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



More information about the Devel mailing list