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

[Simon Schampijer]

On 12/06/2009 10:20 PM, Tomeu Vizoso wrote:
> 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

I like the concept of an action and object view, too. I was always a bit 
confused by the Journal in that regard. It would definitely present the 
concept of the Journal better.

Regards,
    Simon