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

Eben Eliason eben at laptop.org
Fri Jul 3 23:19:15 EDT 2009


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

I prefer to keep the activity icons always at a constant size. We
played around with smaller lists for the reason you suggest, but we
didn't feel that the resulting designs were suitable for kids, both
because the fonts and icons were smaller and harder to read, and
because the clickable targets were so much smaller.

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

I think this is the right approach.

> 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

I think it's far better to have custom activities for these types of
use cases. I think the Journal should be a really powerful tool for
locating this kind of information, but adding lots of complicated
views for various formats which kids may or may not even have lots of
could easily add needless complexity. I think we should focus on
making the best all-purpose solution.

I'll throw this idea back out there for fun, too. I don't  know if
there's a way to do even this without adding too much complexity, but
we did make some mockups of an "advanced" sort bar, which instead of
sorting on columns allowed creation of hierarchical sorting by
metadata. For example, I could use the "what" filter to select "audio"
files, and then use the sort bar to say: "sort by artist, then by
album, then by track". Any Journal entries which had metadata keys for
"artist", "album", and "track" would then appear sorted accordingly,
and the section dividers would show the values for the various keys so
that the hierarchy was logically browsable.

It's a powerful idea, but so far we just haven't thought it to be
worth the added complexity. Keeping the Journal as simple to use as
possible is paramount.

>> The option complexity is too high for me, and causes horizontal
>> scrolling (mentioned above), though the ability to sort on any arbitrary

I think we should avoid horizontal scrolling at all costs. Not only is
it a nuisance, but I like the logical mapping the scrolling axis to
time (or, I suppose, to whatever sort is selected).

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

Yup. I think we can make the search and tagging even more powerful by
supporting user created metadata as well. This is obviously an
advanced feature, but that's OK with me since it doesn't get in the
way of basic use. Typing in key:value pairs into the tag field should
provide searchable keys. In this manner, it should be possible to do
searches for "color:red" to match only on entries which have the value
"red" for the key "color", instead of all entries which had the tag
"red", or the word "red" in their titles, etc.

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

This was a conscious decision, actually. We didn't want to confuse
kids by imposing a required structure on tags. So, all tags are space
delimited, though my hope was that we could "silently" support quoted
tags if they were typed as such.

In any case, I'm not sure that the fact that the tag string "white
house" being, technically, two tags actually breaks things. These
kinds of overlaps will be few, and a search for the two independent
tags "white" and "house" would still being up the entry in question.

> 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

I just don't think there's a way to expose this in the list naturally
without adding lots of complexity. Something I would like to explore,
though, is exposing metadata within the detail pages of Journal
entries. It would be neat, for instance, if photos taken in record
actually had a "photographer: <kid's name>" label in the details, to
make the detail view more useful and to enhance the detail view for
specific kinds of objects. I have some neat mockups showing a possible
UI for this. I'll try to dig them up.

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

Heh. That is a tricky one. I'll have to think about it. Perhaps we
could somehow represent "type" by showing a stack of the generic type
documents. Maybe it would have the "data" icon on the front page, but
visually have a few documents in the stack. I'll play with it.

>>>  * filter by participants
>>
>> I see that as part of above anyone/who.

Yup, definitely.

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

That's not necessarily true. If you use the "who" filter to select
"Walter", then Walter's buddy icon would appear in the toolbar to
indicate the current filter visually, and that query, in the back-end,
would only show entries which were collaborated on with Walter.

If we're talking about typing the string "Walter" into the search
field, what you say is true, but that's why I think we should also
support keyword searches eg: "who:walter" or "with:walter" (maybe even
both would work) so that it's possible for more advanced users to get
at exactly what they want easily. The provided filters are, of course,
the UI to make this easier for the younger or less advanced crowd.

>>>  * 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 think this is nice, myself.

>>>  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 suppose we could have separate filters for "kind" and "activity" if
we decided it was worth it. This only really makes sense if many
activities produce more than one kind of object.

It sounds like you're describing a NOT filter (eg. kind:text NOT
activity:terminal), though, which the current UI doesn't support, as
all of the filter options are combined with an AND. I think adding
boolean AND/OR/NOT controls to the filter UI would definitely
complicate things too much, but we could again support these kinds of
queries within the search field.

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

For clarity, lets use the term tags and metadata (or, keyword tags).
Some tags have a keyword which effectively group them across entries,
and make more powerful queries possible.

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

These are still separate in the current mockups, right? There's
basically an icon for each "key", where the possible keys are "who",
"what", and "when", plus the generic search field. It's nice that all
of these filtering options are lined up at the top, and that it's
possible to add to the filter to narrow down on the search results by
adjusting more of the filters.

Eben

PS. Gary, the mockups are looking good so far. I'll give some thought
to the icons, and try to dig up some of my past designs for bits and
pieces of this.

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


More information about the Sugar-devel mailing list