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

[Tomeu Vizoso]

[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