[IAEP] Journal criticism

[Tomeu Vizoso]

On Wed, May 27, 2009 at 20:20, Lucian Branescu
<lucian.branescu at gmail.com> wrote:
> I'm new to Sugar, so I may be horribly wrong.
>
> But to me, the Journal seems more of an annoyance than anything else.
> A lot of the work I see done is towards bringing back some of the
> properties that regular filesystems have
>
> What advantage does it have as opposed to a regular filesystem with
> support for versioning and metadata? A filesystem would be more
> compatible with existing software (which could just ignore the
> metadata), at least.

I can very easily understand that for someone who is used to a regular
filesystem, the journal may seem as an annoyance when an attempt to
use it in the same way is done. The same can be said of any other
diversion in Sugar from how Windows/OSX behave.

Though, interestingly, many people have successfully switched from
files-in-folders-in-folders email clients to GMail. Maybe it is
because the journal is not as mature as gmail?

If I think that something like the journal is worth having, it is:

- because I can easily observe how non-technical users are unable to
find the files that they stored in folders some time ago, or forget to
save an important document, or modify a file that Firefox saved to
/tmp and it got deleted after a reboot, etc,

- because people working with children using Sugar have said it's useful.

I think it's very important if we want to keep pushing Sugar that we
distinguish between design decisions and bugs and unimplemented
features. If we bring down good design ideas not by themselves but
because of its implementation status, we risk ending up with nothing
that brings new value compared to existing desktops.

Note that I'm not going to the extreme of saying that we shouldn't
consider the feasibility of a design before pushing for it.

Regards,

Tomeu

> 2009/5/27 Tomeu Vizoso <tomeu at sugarlabs.org>:
>> On Wed, May 27, 2009 at 19:34, James Simmons <jim.simmons at walgreens.com> wrote:
>>> Tomeu,
>>>
>>> I've said this before, but maybe I can repeat it once more:
>>>
>>> 1).  I like the idea of the Journal.  I would not want to change the Journal
>>> proper to support putting items in hierarchies.
>>>
>>> 2).  Having said that, I don't always like the Journal Activity.  The
>>> biggest problem I have with it is it insists on making things that are NOT
>>> in the Journal kind of look like they are.  That's a big mistake.  I would
>>> prefer that SD cards and USB thumb drives that may have files and folders
>>> have a totally different user interface from the Journal interface.  The
>>> interface could be made with a Pygtk tree view.  You could copy a file into
>>> the Journal, as a Journal entry, or copy a Journal entry into a directory as
>>> a file.  The file would be named with the title meta tag plus a suffix based
>>> on MIME type.  Maybe some kind of Journal entries couldn't be copied this
>>> way, so copying would not be supported for them.
>>
>> I agree, and thought I was clear in my last email about this. In 0.84
>> has been work to make this possible, though isn't user visible at this
>> moment.
>>
>>> 3).  Maybe there would be an option to use the SD card as expansion for the
>>> Journal.  If you had a 2 gig SD card you could specify that you wanted it
>>> treated this way, and from then on your Journal would be 2 GB larger.  This
>>> option would destroy whatever data was on the SD card to begin with.  If you
>>> didn't do this, the SD card would have the same interface as a thumb drive.
>>
>> This is part of the original vision but is another task up for grabs.
>>
>>> 4).  For the Journal proper, I agree that a temporal view has value.
>>>  However, in addition to that I'd like to sort by the Title meta tag.  This
>>> would be a natural for etexts, because you could look for a book more easily
>>> if they were all in alphabetical order.  If you had a large library on your
>>> XO the temporal sequence would be annoying.
>>
>> Yup, we have mockups that add this functionality. n_tasks_up_for_grabs++
>>
>>> 5).  When several Activities support the same MIME type (Zip files are BOUND
>>> to be popular) then there needs to be a way of specifying that a particular
>>> Journal entry should be resumed by a particular Activity by default.  You
>>> should be able to change that default at any time, but once changed you'd be
>>> able to open any entry with that default with one click.
>>>
>>> Right now the only way to make a Zip file Journal entry open with the right
>>> Activity with one click is to make the Activity open the Journal entry with
>>> the Object Chooser, then save it back out as a new Journal entry.  Then the
>>> user deletes the original Journal entry.  We need something easier than
>>> that.
>>
>> Maybe open by default in the last activity it was open with?
>>
>> Regards,
>>
>> Tomeu
>>
>>> James Simmons
>>>
>>>
>>>
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>