[Sugar-devel] Fwd: journal criticism (was Re: Re: Re: [IAEP] [RELEASE] TurtleArt-51)

[James Zaki]

I did not know there was much debate about this, because for me the journal
in its current state made sense for the target audience of sugar.

Understanding hierarchical file structures use the concepts of containers
and recursion with no limits (except for total capacity). It is not
naturally intuitive, like a tree where branches get smaller from the trunk
with fruit/leaves only at the end nodes.

Empirically I've seen many new people approach computers (non-tech
elder-relatives included), and hierarchical structures are not initially
utilised. It was a secondary focus that had to be learnt out of necessity.
At the time I would say this was due to a lack filters at their disposal.

Tools such as GoogleDesktop or, more evidently, OS X  "Spotlight" are
conceptually more approachable to a beginner/non-tech person, and further
defers the need to learn about their tool rather than just using it
effectively immediately.

Perhaps an activity/game could be made that teaches the concepts of a
hierarchical file structure. It could demonstrate inifite recursion with
inifinite capacity at each node, but reward "good" storage somehow. Once
they complete the game to a certain level, then they can unlock heirarchical
file structures in journal?  But I think there is enough on everyone plates
for now before this gets considered.

Cheers,
James



2009/5/27 Tomeu Vizoso <tomeu at sugarlabs.org>

> [forgot to add IAEP and sugar-devel]
>
> ---------- Forwarded message ----------
> From: Tomeu Vizoso <tomeu at sugarlabs.org>
> Date: Wed, May 27, 2009 at 12:11
> Subject: journal criticism (was Re: Re: Re: [IAEP] [RELEASE] TurtleArt-51)
> To: forster at ozonline.com.au
> Cc: Walter Bender <walter.bender at gmail.com>
>
>
> Hi all,
>
> see my replies inline below. To everybody who would like to join this
> conversation: please change the subject line accordingly or this
> thread will become hard to follow.
>
> On Wed, May 27, 2009 at 04:54,  <forster at ozonline.com.au> wrote:
> > Hi Tomeu & Walter
> >
> > I am happy to expand this to the list. I have raised the journal once or
> twice before but mainly kept quiet not wanting to be trollish.
> >
> > http://lists.sugarlabs.org/archive/iaep/2008-August/001475.html
> > & more but i cant easily find
> >
> >
> > The journal and sharing are probably the two central things that
> distinguish sugar as as a purpose built learning platform. The team have a
> huge investment of time and energy and are rightly proud of their
> achievement. That presents a problem for constructive discussion around the
> journal, the last thing I want to do is be trollish and destructive.
> >
> > For me, the workings behind the journal are hidden and there is a lack of
> tools to make it do different things when the default operation is not what
> you want. Also temporal and tagging is fine as a primary method of storage
> but hierarchical storage is not offered as an alternate method.
> >
> > in addition to today's filename issue, other problems that I can
> remember:
> > altering the filenames and extensions of email attachments
>
> Could you please expand on this use case?
>
> > offline web pages do not navigate because the directory structure is lost
>
> This is scheduled to be addressed in 0.86 by downloading the page as a
> zip file and storing that in the journal.
>
> > can't inspect or alter mime to force something to open
>
> This could be fixed in the journal easily, with no need to refactor or
> throw out anything. We need more people to help us with developing
> Sugar further.
>
> > journal spam
>
> In 0.84 landed several modifications that should improve this somehow,
> have you seen if that helped?
>
> > (I haven't found a way to select a block so every spam item has to be
> individually deleted
>
> Would be awesome to be able to operate on multiple items at once, but
> unfortunately it hasn't been implemented yet.
>
> > resume by default will probably cause students to lose work)
>
> Versioning in the journal is scheduled for 0.86, which should address this
> one.
>
> > accidental overwriting of files through autosave
>
> Same as in the previous one, if I understand it correctly.
>
> >> Thanks for the feedback.
> >>
> >> Adding Tomeu, but we should probably expand the discussion to the list.
> >>
> >> I cannot argue with you that the fact that the Journal hid information
> >> from the user is a problem--really I would characterize it as a bug.
> >> But the goal of the Journal wasn't to simplify (and certainly not to
> >> hide information from the user) as much as it was to provide a
> >> representation of the file system that is first and foremost temporal
> >> rather than hierarchical with an emphasis on annotating, tagging, and
> >> searching rather than browsing. Secondary goals are automatic
> >> recording of actions and objects and the ability to extract from the
> >> Journal highlights. These latter goals could as well be accomplished
> >> using a hierarchical representation, but still would require a
> >> database backend of some sort.
> >>
> >> -walter
> >>
> >> On Tue, May 26, 2009 at 7:18 PM,  <forster at ozonline.com.au> wrote:
> >> > Thanks, I now have V51 on my XO
> >> >
> >> > Short rant follows:
> >> >
> >> > This is another example why I do not like the Journal. The Journal
> does not preserve filenames or directory structures. The download showed in
> the Journal as
> >> >
> >> > "File turtle_art-51.xo from
> http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo
> ."
> >> >
> >> > As soon as I downloaded to Windows it was obvious that this was not
> the file that downloaded.
>
> I'm failing to understand the problem. Could you please explain further?
>
> >> > The Journal hides too much of the workings from the user and so
> disempowers the user. The user is denied a deep understanding of what they
> are doing and the opportunity to use the system in ways that were not
> thought of by the designers. They are Users, not Creators or Authors.
> >> >
> >> > The hiding of the file system was well intended, files and directories
> are probably just a passing phase in computing and they cause some confusion
> to beginners, but they are the system which underlies the Journal and the
> way we interface with the www
> >> >
> >> > The price for low entry is too high if it disempowers the user,
> enforces artificial walls and ceiling.
>
> I think we have a problem of miscommunication here, in part I guess
> because our understanding of the problem has changed with time and
> also because it's hard to keep up with everybody's opinions.
>
> How I see this issue is that in the spirit of "low floor, no ceiling"
> we should keep moving forward in our implementation of the journal as
> devised, while adding more intermediate steps that go towards the
> understanding and manipulation of all the pieces of the educational
> machine, regardless of its complexity.
>
> I agree that it would be helpful to have hierarchical views of the
> file system in Sugar, though I don't think they should be the default
> one because IMO a flat view like gmail with good filtering and search
> capabilities is more efficient for users that don't want to spend
> their energy in keeping their data in directories. I understand this
> opinion is very debatable, but it comes from my observation of how
> people around me use their computers and also from the feedback about
> Sugar from the field.
>
> Where I see value in having a hierarchical view of the filesystem is
> in browsing a file system that isn't the main journal (the root
> filesystem, a removable device, etc).
>
> I have done work in the past to make easier to have such a
> hierarchical view and also to be able to browse the contents of the
> journal with traditional file browsers, but my time is very limited
> compared to all that needs to be done and I have decided to focus on
> other areas that IMO have a higher priority.
>
> But I would be very happy to give pointers to anyone who wishes to
> work on this, I have several ideas about how this could be
> implemented.
>
> Thanks,
>
> Tomeu
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090528/bef12201/attachment-0001.htm