notes on Journal feedback (was Re: Bundle activity)

[Tomeu Vizoso]

On Tue, Oct 7, 2008 at 3:22 PM, Erik Garrison <erik at laptop.org> wrote:
> 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 laptop.org> 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 laptop.org> 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:
>>
>> http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability
>> http://sugarlabs.org/go/DevelopmentTeam/DatastoreRewrite#Reliability
>>
>
> 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.

Ok, so 1) was really about journal full issues?

>> > 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

"doesn't aknowledge files"? Can you explain what do you mean by this?

> the benefit of its very young, and technically uninitiated users.

Don't know where you have read that. The Journal is intended to give a
better way to deal with the results of the interaction with the
machine than a folders-based system inspired on office workers.

>  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...)

Can you explain what this has to do with what you originally wrote in 2)?

>> > 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?

I think it's too abstract to be useful. We need actual use cases that
make sense to our users.

>> > 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.

You have been in Uruguay and have talked to teachers, also have shown
a great interest in improving the journal, by your frequent emails
about it. Can you take the initiative of putting all that feedback in
an usable form?

I'd recommend that we continue discussing journal issues each in a
separate thread, as this one is getting a bit unfocused.

Also would like that we start differentiating between implementation
and design. Both the DS and the journal are in a very early stage, so
judging the design by this flaky and very incomplete implementation is
very misleading.

Thanks,

Tomeu