[IAEP] Journal criticism

[Lucian Branescu]

Right, that does make it a bit more clear.

I feel however that there should be a way to mount the Journal as a
regular filesystem without losing too much information (put stuff in
folders according to labels, put activities in their own folder, etc.)

2009/5/27 Tomeu Vizoso <tomeu at sugarlabs.org>:
> 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
>>>
>>
>