[Sugar-devel] Journal feature request--more data in main display

[Aleksey Lim]

On Fri, Jul 03, 2009 at 06:13:24PM +0100, Gary C Martin wrote:
> Hi Aleksey,
>
> On 3 Jul 2009, at 05:25, Aleksey Lim wrote:
>> On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote:
>>> Aleksey was keen to see any Journal mock-up work in progress I had,
>>> early as possible, so here's where I'm at :-) There's plenty to do
>>> still, images are intended to help bounce ideas about, poke at the  
>>> grey
>>> matter between our ears, and get a feel for how things could (or  
>>> not) be
>>> done:
>>>
>>> 	http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes
>>
>> Some thoughts:
>>
>> * what about adding ultra compact list view for objects(not actions)
>>  like list view in Library[1]
>>  the purpose is, if user has lots of objects it could be useful idea  
>> to
>>  show as much as possible objects on one screen
>
> We do want to show plenty of entries, but need to keep in mind visible  
> size of each text/icon row entry. My current call is to make each  
> Journal entry row 'richer' rather than trying to cram on more rows  
> (encourage folks to search/filter down to a small number of results).  

Maybe having several views/layouts(for several purposes) is more useful 
idea then only one common view for all purposes?  I mean:

* compact view
  could be not trivial(horizontal scrolls) but highly
  configured(show/hide columns)
  for people who want narrow lines with additional columns
  (to sort them for example)
* grid view
  and use filters to show what user needs(because there could a lack
  of useful info in this view)

> The grid view is better for looking and scrubbing through many entries. 
> In Library you've made your rows richer by adding many more options for 
> showing extra columns of information (author, artist, date, album, disk, 
> track, genre, copyright, ...) at the cost of lots of horizontal 
> scrolling, and option complexity.
>
>>  * having several column/grid layouts
>>    for example its very useful for books to have columns for author,
>>    genre, date; so, user can see the whole valuable info at once and  
>> sort
>>    objects by these columns; and so separate layouts for video audio
>>    etc. files
>
> The option complexity is too high for me, and causes horizontal  
> scrolling (mentioned above), though the ability to sort on any arbitrary 
> column is a bonus. Personally I think all the extra column information 
> would be much better treated as tags, that way you can use the existing 
> Journal tagging mechinisum, search and drill down to the entries you are 
> after, and with the title + tag row entry still get to directly browse 
> that information if needed.
>
>> * additional types of filters
>>  for example Library has[2] several types to filter objects
>
> As a user, I don't like to see dot notation bundle id's displayed in the 
> UI (i.e org.laptop.sugar.ReadEtextsActivity), it's way too scary :-) I 
> think the anything/what activity/mime filter is more user friendly.

thats was just first implementation(further it will be activity names)

>>  * user tags
>
> Library does confuse me here in that it seems to have it's on separate  
> tagging data and process while ignoring actual Journal tag metadata.

The problem is - user can use any symbols in tag name(including spaces)
at the same time Library needs datastore to make exact query by this
tag and do not mess tag name with words in description field for
example.

So Library stores tags in json string with structure:
[("pretty-tag-name", "__tag_name_especially_to_make_exact_query__"),..]
thats why this string goes to "_tags_" field and not to "tags".

>>  * object traits(additional columns from previous section) like  
>> author,
>>    genre, date for books
>
> Found this separation confusing, if really necessary, are 'traits' not  
> just tags?

thats because they live in separate DS fields to let users sort objects
by them

>>  * activity creators(grouping by activity_id field)
>
> Yes, I have a TODO to add a button and palette for anyone/who.
>
>>  * types of objects(like top section in filter palette)[3]
>
> Yep, that's my anything/what funnel filter icon (looking for better  
> icon) :-)
>
>>  * filter by participants
>
> I see that as part of above anyone/who.

>The most common filter would be 
> to be able to search for Journal entries from "Walter".

but in that case user would get all objects with substring "Walter"
not only objects with participant Walter

>>  * filter by sources(if we are in shared mode)
>
> For your Library Activity, but not sure this is relevant (in short to  
> mid term) for Journal. And, perhaps covered by above anyone/who filter. 
> Once you 'borrow' an entry you now have a local copy in the user colours 
> of the person you borrowed from.

yeah, thats should rethinking during implementation of sharing objects

>>  I'm not sure that all of these modes are useful, but something could
>>  be(or another types)
>>
>> * several levels of chosen filters
>>  dunno about others but for me its very useful
>>  (see bottom panel on [4])
>>  for example I can filter all text/plane files and separate from them
>>  only objects that were made by Terminal activity
>
> I found this complicated in Library, actually I'm not sure I have is  
> solved yet :-) I think tagging is a simple wide ranging panacea for many 
> of these types of search.

In fact all these types of search are *tags*
but some types are objective(like type of object, creator activity for
this object, participants etc.) and some are subjective(like users tags)

The idea to separate this types is: it could be useful for users to view
tags only for one type; for example mixing participants and types doesnt
make sense.

In fact these tags types are only another view on having choices for
"Who", "When" etc. IMHO having all these choices in one place makes
process of filtering more straightforward because all its about
filtering

-- 
Aleksey