notes on Journal feedback (was Re: Bundle activity)

Erik Garrison erik at
Tue Oct 7 09:22:53 EDT 2008

On Tue, Oct 07, 2008 at 12:14:13PM +0200, Tomeu Vizoso wrote:
> On Tue, Sep 23, 2008 at 3:47 PM, Erik Garrison <erik at> wrote:
> > On Fri, Sep 12, 2008 at 09:17:16AM +0200, Tomeu Vizoso wrote:
> >> On Thu, Sep 11, 2008 at 10:40 PM, Erik Garrison <erik at> wrote:
> >> > When I was in Uruguay more teachers asked me about issues with the
> >> > Journal than anything else.  I keep poking on this issue to remind
> >> > people that it's not going away in the field.
> >>
> >> Could you please tell us more about the issues reported?
> >
> > 1) Data loss.  Teachers I met mentioned seeing bugs where the students
> > Journal was wiped clean, or where things went missing.  Without live
> > examples this is pretty hard to diagnose.  Perhaps an effect of running
> > on such an old build.
> Yes, this improved in 0.82 and is a big goal for 0.84:

I think that (4) is actually mixed with (1) as well.  The problem is
that the activity API is auto-saving work sessions.  If left unchecked
by the user they'll end up with a Journal full of lots of entries they
didn't intentionally create.  The system doesn't require the
intentionality of its user to save, yet the result of saving and
auto-saving are identical.  It's hard to find the important things among
the pile of unimportant things which result from everyday use of the
interface.  From a user's perspective, or the perspective of their
teacher, this is equivalent to data loss.  

> > 2) Journal startup failures borking the whole system / Journal never
> > completing startup but Sugar starting.  Possibly because of NAND-full.
> > If so we have fixed it.  Interestingly, I heard about kids resolving
> > this issue manually from the command-line (although their teacher didn't
> > know exactly what they did!  I'm guessing they removed their data
> > directory.).
> Yes, IMO, this is the same issue as 1)

Additionally, users could be deleting their Journals from the command
line simply because they can't find anything they need and they don't
care about saving their data.

We have a data manager which doesn't acknowledge files, purportedly for
the benefit of its very young, and technically uninitiated users.  Then,
when it's not working they drop into the command line and delete its
configuration and data caches manually using rm -rf !  (This knowledge
is becoming quite common in at least one of our deployments.  Just
yesterday a kid from Uruguay came into #olpc-ayuda to ask exactly how to
do this.  And this morning a user spontaneously wrote rm
.sugar/default/confis into the channel...)

> > 3) "How do I share files to/from an XO?"  "I just did this work but now
> > where is the resultant file?"  Interface with the outside world.
> How could we better define the "outside world"? Do you think we could
> get a list of the main use cases when taking data out of XO systems?

"Anything that can use a file" would be a good description of all the
main use cases.  How do we get lumps of bits from here to there without
acknowledging the utility of the file abstraction?

> > 4) General usability concerns; questions about why the design was
> > chosen.  Difficulty finding things in the produced action history.
> How could we get to know which are those concerns? Perhaps we could
> try to get the people who can give this feedback on the olpc-sur
> mailing list, have some discussion there in spanish and then summarize
> in the global lists and wiki? And if you could by a chance remember
> any concrete usability concern, please post it here.
> I think we all agree that the journal sucks in a lot of senses. We are
> trying to improve it by implementing the biggest missing pieces and
> patching the biggest wholes, but if it was at all possible to choose
> the priorities based on real feedback from the field, I'm pretty sure
> the result will be much better. Do you think we can get feedback on a
> form we can actually use?

I think we should ask around on olpc-sur!  I also recommend coming to
#olpc-ayuda and talking with the kids who are trying to 'fix' issues
with their Journal via the command line.


More information about the Devel mailing list