[IAEP] Journal prompts (was: Re: [support-gang] FW: [OLPC Bolivia] No logro aprender Sugar / I cannot learn Sugar)

[Christoph Derndorfer]

Am 15.06.2011 18:12, schrieb Walter Bender:
> All of that said, let me repeat an argument I made regarding the Sugar
> Journal during the EduJam summit last month: we developed the Journal
> not because we wanted to be incompatible with the rest of the world
> but because we wanted to address some pedagogical needs. Specifically,
> we want the children to have a place to reflect upon their work. The
> Journal is their portfolio. Reflection requires effort and some
> developers consider the prompts to write in the Journal as an
> annoyance. But when I ask those same developers if they think adding a
> commit message to their commits in git, they immediately understand
> the value. So some of the annoyance of the Journal is because we have
> not completely solved the UI issues (the good news is that Simon has
> some patches landing that fix some of these issues) but some of the
> annoyance is because we want to make the path of least resistance be
> one where the children are prompted to be reflective-- to write in
> their "lab notebooks" about what they are doing and why and to make
> presentations to their teachers, parents, and fellow students about
> their work. (The latter is facilitated by the new Portfolio activity.)
> 
> In any case, concrete feedback and criticism is welcome. Thanks.

Hi Walter,

I'm not sure whether this really counts as concrete enough feedback but
I'll do my best.

The very short version is that while I think that having a tool for
reflection, annotations, metadata, whatever you want to call it makes
sense yet I personally don't think that Journal prompts are the answer
at this point in time.

Regarding the git-example you mentioned here and at eduJAM! I also think
that the comparison doesn't really work. The main value of git's commit
messages in my mind are:

(a) as a record of changes so you know which version to revert to when
things go awry
(b) as a way to make other developers in collaborative projects aware of
such changes in general

As the Journal currently doesn't provide an accessible way to revert to
older versions of the same entry use-case (a) isn't really available.
Since collaboration is also very seldomly used today and even less on
ongoing projects or activities which span days, weeks, or even months
and additionally we don't have facilities to merge, fork, etc.
collaborative Journal entries also (b) isn't available to Sugar users today.

So what we seem to be left with at this point is a system which tries to
force users to add comments or tags even though there is very little
incentive or supportive mechanisms to actually do much with that metadata.

Now one could argue that just because we don't have the other parts of
the puzzle yet we should still try to get users acquainted with the
general notion. Yet here I would say that there's a significant risk of
conditioning people to simply do whatever it takes to get rid of the prompt.

I don't have any data but would assume research into the effects of such
forced decision making - whether it's Microsoft's classic "Ok or Cancel"
metaphor or Android's App permission system - exists and probably shows
that people click whatever gets them back to what they really wanted to
do as quickly as possible. So from that point of view it seems to make
more sense to wait until tangible benefits are available to users before
confronting them with the prompt.

One somewhat intermediary approach which seems concrete and actionable
here even in the short term (and regardless of whether we have mandatory
prompts or not!) is to use some sort of automatic suggestions for
Journal entries. A very simplistic example would be to copy the
behaviour of traditional office solutions and suggest the first few
words of a Write session as the Journal entry's title.

A more invasive solution would be to take a note from how you can access
a Journal entry and its metadata (though only tags at the moment) when
viewing photos within the Record activity. People like Gary C will
likely have a more fact based opinion here but to me it seems that
offering the ability to add information to a Journal entry while you're
actually working on it is a good option (again regardless of whether you
force prompts upon closure or not).

Last but not least and on a more abstract and philosophical level I
think that Sugar should create possibilities and both implicitly and
explicitly encourage certain behaviour without forcing it on users.
Would we like to see collaboration between users? Yes. Do we make all
activities show up in the neighborhood the moment they're launched? No.
Would we like to see children dive into the source code? Yes. Do we make
them read libabiword man pages before starting Write? No.

More than anything it is about showing Sugar's users the value and power
of tools like naming, tagging and comments. Including relevant
information in teacher training and general support materials such as
the Help activity could probably also go a long way here.

Cheers,
Christoph

-- 
Christoph Derndorfer
co-editor, www.olpcnews.com
e-mail: christoph at olpcnews.com