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

[Gary C Martin]

On 4 Jul 2009, at 04:19, Eben Eliason wrote:
> 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.

I'll maybe try have a go at a simple mock-up. Could either be part of  
a row titling the current columns, as in a subtle little arrow button  
with several sort by options in it – "sort by modified", "sort by  
created", "sort by size". Or perhaps as a regular button & palette in  
the toolbar (though toolbar is filling up fast with icons and is  
likely too 'featureitus' scary already in my mock-ups).

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

+1, the details page is out of the way and could do with some more  
actual details (entry file size being the currently most useful I've  
seen go by so far).

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

Fab, thanks.

> These are still separate in the current mockups, right?

Yes.

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

Yep (though I'd like a quick way to clear a search rather than the  
current trawl through each filter).

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


Thanks. Having a bit of trouble with the when/anytime palette. If we  
want each toolbar icon to visually represent the filter, it means we  
need a series of icons for today, since yesterday, past week, past  
month, past year (have a few misc. icon ideas but not a sensible set  
to cover all).

	http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#When.2FAnytime_palette

FWIW: There's also another shot at a possible tag cloud treatment:

	http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Show_frequency_as_proportional_size

Regards,
--Gary