[Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt

[Tomeu Vizoso]

On Sun, Dec 6, 2009 at 03:20, Aleksey Lim <alsroot at member.fsf.org> wrote:
> (oops, wrong subject)
>
> Hi all,
>
>
> This post is not about particular feature but about proposed
> to 0.88 features that can be composited to one set.

IMHO, instead of proposing (apparently out of the blue) new features
that change everything including the development and deployment
models, would be better to start from a stated need and then propose
solutions for those.

In the particular case of the Journal, we know from the 0.86 cycle
that the current list widget is not the best we could use. Users are
also demanding a way to select multiple items and perform operations
on them. Sorting has also been requested. Do we really need to decide
on the plugins thing before we solve these simpler issues?

Regards,

Tomeu

> Some of them
> could be implemented in 0.88 partially, some are invasive, some not.
> We lost possibility to push several such features in 0.86 and we have
> a chance to do it once more in 0.88 release cycle. But in my mind,
> start to fix followed issue could be useful even in 0.88.
>
> * Reinforcing the storage metaphor in sugar
>  (w/o loosing dairy component). Since in sugar we have only
>  datastore(existed Journal from users POV) as a data storage(excluding
>  external sources), we have *very* poor instruments to treat sugar
>  object from users POV - user has to face to the whole list of objects
>  from begging(there is not way to keep query - should look like
>  replacement of regular directories), user even can't manually sort
>  Journal objects.
>
>  Could be fixed by:
>  * [5] having sugar "directories" - bookmarks
>  * [6] several views that could provide most useful browsing features
>
> * Having extended storage metaphor, we should save dairy component,
>  so we can start implementing of long discussing Actions feature
>
>  Could be fixed by:
>  * [2] its only a stub, so any ideas are welcome
>
> * Make existed work flows more consistent
>  ("activities vs. objects-that-could-be-treated-as-activities",
>  "activities vs. activity bundles")
>
>  Could be fixed by:
>  * having [5], there is simple behaviour, all sugar objects are
>    accessible from one place but from different views e.g. Hove view
>    is just a special view that contain only "activities"(but could
>    contain other objects too to speed up access) or new Actions view
>    is a "dairy" view
>
> * Encourage activity developers make custom objects views,
>  (having only one object view we either have complicated view or
>  feature less one)
>
>  Could be fixed by:
>  * [1]
>
>
> These features are:
>
> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins
>    the name could be confusing but [1] should provide all features that
>    are mentioned here
>
>    How its invasive:
>    * except [7], non of UI should be changed in default sugar distribution
>    * code will be refactored to support plugins API
>
> [2] http://wiki.sugarlabs.org/go/Features/Actions
>    this page just a stub, so who are original initiators (or have ideas)
>    for this feature, please tweak wiki page to cover all workflows
>
>    How its invasive:
>    * the full implementation of this feature could be too invasive for UI
>      and codebase, but we can just initiate this feature in 0.88 and
>      collect users feedback to improve it in 0.90
>
> [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object
>
>    How its invasive:
>    * adds another confusion when user deletes activity instead of
>      activity objects but having [5], by default, all object sets could
>      not contain activity object except special activity views that can
>      make activity removing more explicit for users
>    * shouldn't be invasive in case of codding
>
> [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles
>
>    How its invasive:
>    * codding shouldn't be invasive
>
>
> Summarising above text, I think we can start implementation of these
> features in 0.88 release cycle(but we shouldn't implement the final
> workflows and make only initial steps e.g. in case of Actions). So, what
> community thinks about how such features could be invasive to users
> workflows and codebase and how it could(invasive changes) be reduced.
>
>
> [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model
> [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model
> [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design
>
> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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