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

[Eben Eliason]

On Fri, Jul 3, 2009 at 2:17 PM, Gary C Martin<gary at garycmartin.com> wrote:
> On 3 Jul 2009, at 10:01, Martin Langhoff wrote:
>
>> On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin<gary at garycmartin.com> 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
>>
>> Very cool. I do agree the filter is very culture-dependent.
>>
>> On a similar vein, the 'tag' icon has no visual association with the
>> many tags on screen. If they had a similar shape, then it'd be easy to
>> connect, for users who don't recognise a "tag" and the (somewhat odd)
>> use of "tag" to mean "a bit of metadata on a digital resource".
>
> I just 'acquired' the tag/label icon from Eben's mock-ups. Assume he had
> though about this way more than me :-) Sure there are plenty of revisions,
> reworks, and cherry picking.

Heh, you did. Nice. Did those mockups show how we might show the tags
themselves in the UI, though? I do think it's important to make the
label reflect the UI. That said, I'm actually thinking that the tag
dropdown should be an extension of the search field itself. Perhaps
it's just to the right, and only needs to be a little down arrow that
reveals the tags (or perhaps we even modify the search entry to have
this button). Previous mockups I'd worked on were based on the idea
that a tag suggestion window would popup beneath the search field
while typing to show possible tags. The thought for the explicit
dropdown arrow would be to choose tags without having to start typing.

>> Wishlist: "show files by size" filter or option? If the Uruguay
>> experience is any indicator, a fact of life is that users after all
>> *will* hit:

Yes, exposing size in the main list might be worth considering.

>> - problems with fitting files (large and small) in USB disks
>>
>> - problems with their Journal taking too much space
>>
>> - problems with installed Activities taking too much disk space
>
> Good point! Though arbitrary Journal sorting likely breaks many design
> goals***, otherwise you'd have thought we would have the most basic of
> features, sort by creation date, by now ;-) At the very least size taken by
> an entry should be visible on the details view. Right now there is zero
> indication other than just watching your total Journal grow in size via it's
> frame icon.
>
> ***Eben can you clarify this one? If locking folks into a 'view Journal only
> by modification date' was an intentional design choice?

Not at all. The proposed designs include a sort bar, which would
function in the traditional fashion, but be sorted by date ("when") by
default. See http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#03

Tomeu has been working on using the standard GTK TreeView, so I think
we're on track to add sorting by name, date, and participants (we need
to decide what sorting by participants means...I think sorting by
number of participants might be the useful choice, so that it's easy
to surface the collaborative activities). If we expose file size in
this list somehow, that would also be sortable.

Eben

> Regards,
> --Gary
>