[Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88

[Tomeu Vizoso]

2009/12/3 Aleksey Lim <alsroot at member.fsf.org>:
> On Thu, Dec 03, 2009 at 12:23:37AM -0500, Eben Eliason wrote:
>> On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff
>> <martin.langhoff at gmail.com> wrote:
>> > On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd <wadetb at gmail.com> wrote:
>> >> When deleting an object from the Journal that is an activity bundle,
>> >> we ought to display an alert with a scary icon.  The alert should
>> >> clearly state that Journal entries will no longer be able to be opened
>> >> until the activity is reinstalled.
>> >
>> > Majority of 6 year old will not understand that.
>>
>> The best way to handle this, I think, is to let kids delete activities
>> but also keep a reference to the source in the form of an update URL
>> or similar, so that fetching the activity automatically when an
>> instance of it is resumed can be done. There's additional UI work
>> there, and we can't guarantee connectivity, etc., but it would help
>> reduce the overhead involved. (I'm not suggesting we shouldn't find
>> ways to make it clearer when a deletion is happening, either, but as
>> noted, the dialog may not work in practice with the target audience.)
>>
>> >> Some of the other operations Aleksey mentioned, like upgrading
>> >> activities, ought to display similar alerts.
>> >
>> > Gentlemen, alerts do not work with young users. We have to just DTRT,
>> > or provide actions that are very clearly different (and even then...).
>>
>> On a more general note, this discussion has many hints of the
>> action/object views that have been tossed around for some time now.
>> This specifically addressed the conflict between the desire to manage
>> all objects and the desire to have the Journal reflect only the
>> actions of the child.
>>
>> In this split, the action view shows actions, which reference one or
>> more objects (activities, people, devices, etc.) This would contain
>> only references to things the children have done themselves. The
>> object view shows objects, which is a more traditional view of
>> everything that's around to be manipulated. Any preinstalled
>> activities would appear in the object view by default, and thus be
>> accessible by kids to copy, share, modify, etc. (and as they do, new
>> actions will be created to record that).
>>
>> Ultimately, the object view would look much like the current Journal
>> view does, and the actions view would be a bit friendlier. One benefit
>> of this is that young kids need only look at the actions view, while
>> those that wanted more control could dig into the objects directly.
>
> Good catch, what about more explicit following "user works all time with
> the same objects but from different views" and add Action view as a
> Journal plugin(and maybe make it default) to [1](technically we need
> addition data to form actions view but for users it could be the same
> (as in objects view) objects but organized to actions.
>
> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins

I agree that the split of the journal in an actions and objects view
would help with this and other problems we currently have in the
journal. The GNOME Activity Journal is also going with this.

Regards,

Tomeu


-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning