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

[Eben Eliason]

On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Lim<alsroot at member.fsf.org> wrote:
> 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].

I think a solution something like Scott's Journal2 mockups proposed
could work nicely here, without the need to add a sidebar. Collapsing
the text popup menus to simple icons (eg. an activity icon for the
"what" filter, an XO for the "who" filter, etc.) would be a great
improvement, both making the UI more visual, less cluttered, and also
providing us with palettes instead of popup menus for adjusting the
filters.  These palettes could, as you suggest/show, even have grid or
list views; the "when" palette could have a calendar or a timeline; we
could have search fields in the palette for narrowing down long lists
of tags,  people or activities, etc.

This is really just a rearrangement of what you're proposing, without
eating up all the extra screen real estate for a persistent sidebar,
because I think that space really is needed for looking at the
contents of the Journal itself.

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

I see. Cool.

> Having "View Journal" option in buddy menu makes sense as well

I agree.

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

Right. This would be essential. There's definitely some thought that
needs to be done here.

Scott had an interesting proposal which basically exposed the Journal
(or some subset of it) as an RSS feed. This was really neat, because
it meant we could build a UI for someone else's Journal in Sugar,
populating it with that data, but also that these feeds could be
shared globally, for anyone with an RSS reader to benefit from. That's
a really powerful approach in my mind, and there is some starter code
lying around as a proof of concept already!

Eben

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