[IAEP] [FEATURE] [DESIGN] Journal Reload a new attempt

[Aleksey Lim]

(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. 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