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

[Tomeu Vizoso]

On Thu, May 28, 2009 at 10:41, James Zaki <james.zaki at gmail.com> wrote:
> 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.

I guess there are some concepts that may take some time to grasp, but
what I'm most concerned is not about not being able to understand
those, rather that for someone who is putting all her energy on music
creation or geometry exploring, having to set aside some of her mind
into keeping track of where the files are put may not be so great.
Even more when computers can help a lot with information finding and
retrieval.

I like to think that Sugar is not striving towards "simplicity" but
rather to remove as many obstacles as possible in the path to
learning. Data handling is an area where current computers are failing
people and where we can do much better.

Regards,

Tomeu

> 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
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>