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

[Aleksey Lim]

On Mon, Nov 30, 2009 at 12:34:45PM +0000, Daniel Drake wrote:
> On Fri, 2009-11-27 at 22:16 +0000, Aleksey Lim wrote:
> > Hi all,
> > 
> > While preparing new 0.88 features, I encountered some in consistence in
> > "activities vs. activity bundles" case, so I'm going to reveal
> > "Activity as regular objects"(see [1] ml thread) feature but make it
> > less invasive in case existed user experience.
> > 
> > http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object
> 
> I feel that this is quite a fundamental change to the Journal
> philosophy. Until now, the Journal is something that record what the
> user has done, and it only stores the work (or history) of the users
> session within the activities. In tune with this, the Journal is empty
> when you start for the same time. This would no longer be the case with
> this feature.

Well, I'm sure we should start such rethinking sometime since we don't
have any native sugar shell workflow for forking/changing activities
(imho having such workflow could be very useful to encourage tweaking
existed activities in the field). And we can start from small steps like
proposed feature.

> I think this topic needs larger forward-thinking discussion. Personally,
> I prefer the concept of the Journal for what it is now.
> 
> > The major reason for this feature is eliminating confusion when:
> > 
> >     * theres are activities(in Home view) and activity bundles(in Journal)
> >     * user can remove bundle from Journal and activity will be preserved(and vise versa)
> >     * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal 
> 
> I guess it depends on the UI, but I worry this would actually add
> confusion. Users would be prone to accidentally deleting the activity
> installation from their Journal when they think they are just deleting
> some work they have done in that activity.

I guess it relates to another forkflow which is proposed by [2],
bookmarks from [2] is just a set of objects(I think it could be useful
e.g. having fast method to access to some tricky query or for sharing
objects from bookmarks, to not share all objects), so user can
delete/change object from bookmark or from full Journal View and that
shouldn't confuse him(I hope) if he will keep in mind that he is
working with the same object(but from different views) all time.
In that case, having Home view(which is not "just another view") and
Journal with bundles could be really confusing.

[2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model

-- 
Aleksey