[Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

Aleksey Lim alsroot at member.fsf.org
Wed Jul 1 13:42:14 EDT 2009


On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote:
> On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Lim<alsroot at member.fsf.org> wrote:
> > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote:
> >> Hi,
> >>
> >> in this week we want to talk about the Journal and datastore [1]
> >> improvements planned for 0.86. The Library activity [2] has shown some
> >> interesting concepts as well. What are the common goals, how to move
> >> forward, where to invest?
> >
> > Just some thoughts before meeting.
> >
> > For new Journal we have:
> > * action-centric view
> > * object-centric view
> >
> > In my mind they are quite different,
> > action-centric view relates to timelines when object-centric is more
> > like a browsing of objects(sort, tag them etc).
> >
> > So, what about using Library's code base for object-centric view?
> 
> I think Library and Scott's "Journal 2" are both good sources to pull
> from. From a UI perspective, however, I think keeping to something
> very much like the existing mockups is the best course, both because
> this is a familiar ground for users (the initial vision for object
> view is nearly identical to the current Journal UI) and because it's
> important to keep it simple while finding intuitive ways to extend
> functionality. I think exposing tags, adding tag autocompletion,  and
> improving the selection filters in the toolbar are good places to
> start.

I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1],
maybe having sidebar(like in Library[2]) could make more sense(btw user can
hide sidebar to browse objects in "full window" mode), moreover we could
use several views for entries in sidebar: list(tree) view, tag cloud[3].

> Adding the grid view to expose object previews would also be a
> great addition!
> 
> I also like that Library has started to support sharing. I think there
> have been a number of interesting proposals for how this might work in
> the Journal, and I'd love to see the feature added. Perhaps by
> selecting "View Journal" in the palette for a buddy it would be
> possible to see anyone's shared content.

The original idea of Library in case of sharing was shared(common) collections
of sugar objects i.e.:
* user #1 creates collection(Library object), creation means choosing
  filter for local objects(user tags, properties like mime-type, another
  DS fields)
* user #1 shares his collection(Library object)
* user #2 can join #1's session and see(download) objects from his collection
* user #2 can add his local objects to this shared collection(by setting
  filter for his local objects)
  so, all joined users can view all(from all users) shared objects in
  one place

Having "View Journal" option in buddy menu makes sense as well
But in that case we should provide possibility to mark objects that can
be shared(I guess sharing all local objects by default is not a nice idea).
And Library's method doesn't fit well for this(since it uses filter and
adding one particular object to collection(shared list) is a problem).

I thought about this issue in context of Library.. and what about:
Extend conception of Favorites to Pins. The idea is:

- having implicit list of Library-collections/shared-collections means
  problem to support these lists(if user deletes some object, sugar 
  should update all these collection lists implicitly)
- contrariwise, having in object implicit list of all collection links that
  this object participates in, means also some odd implicit job to
  support these links
+ so, what about delegation this job to users and make this process explicit
+ sugar does not do odd job of implicit supporting lists of links
+ users can understand what objects go to what collections(like
  collection of objects to share, collection of starred objects, users
  collections)
* old Favorites mark would be a "pre-installed" pin
  so, we could have several standard pins:
  * pins for objects to share
  * Favorites could be transformed to pins to show objects in home view
    so any object(not only activities) could appear in home view
  * ...
* each pin could have unique color(and name)
* like Favorites pins could be attached to objects from list view(there
  is no needs to open details dialog)
* each objects can have several pins attached at the same time
* we can render all these attached pins in one cell(not in per-pin cells
  like for participants) i.e. pins will overlap each over

[1] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3
[2] http://wiki.sugarlabs.org/go/File:-1.png
[3] http://wiki.sugarlabs.org/go/File:-2.png

-- 
Aleksey


More information about the Sugar-devel mailing list