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

[Aleksey Lim]

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

-- 
Aleksey