Re: [Epiphany] Re: [Usability] User defined metadata (was: epiphany toolbar/bookmarks)

[Marco Pesenti Gritti <mpeseng tin it>]

> Ok, putting the category in the subject might be a solution. But it
> doesn't solve the problem that you are forced to use your keyboard and
> to remember your categories (unless you scroll through all the entries).

I dont think requiring the user to use the keyboard for such corner
cases is a big deal. About remembering, I'm not convinced it's required.
If I'm looking for a consulting work type consulting in the entry is
sort of obvious, if I'm looking for a work in general, going to the work
topic will fastly show me that I had consulting bookmarks there ...
Obviously I could be wrong, need more testing.

> Using a rating/priority setting might be simpler for easy classification
> by the user, but it's not very flexible and it wouldn't be that easy to
> "filter" a list for a certain priority (especially if you can't remember
> which rating you used to mean what).

For that use case a "Sort by rating" functionality would have worked,
probably better than the Near/Far subfolders. From his description it
looks like he was trying to make a distinction between works he liked
more or less. For that the folders solution sounds crack, innatural and
inflexible to my not used to hierarchies mind :)

> Sure, the example was a corner case but in general, I think that further
> classification could be quite useful. A more simple example would be a
> Topic "Gaming", I could add a field "Game" and whenever a bookmark is
> about a certain game I could set it. Now when I want to find bookmarks
> about a certain game, I could open the Gaming topic and select the
> gamename from the Game filter, without using the keyboard and very
> convenient. While I don't use this kind of classification yet, this is
> basically only because it's so cumbersome with submenus (as you
> described) and not possible at all with Epiphany. But if it's done in a
> really powerful and flexible way with metadata, I could very well
> imagine to use it heavily to file larger bookmark collections. It might
> be a killer feature.

It seem to me that using search would work perfectly here too. You know
the name of the game if you "want to find bookmarks about a certain
game".
People use search all the time in browsers ... if you have a big number
of elements to filter and you dont want to make basic filtering hard, I
think you have to use search for the corner cases. Obviously it's matter
to identify what is the corner case. It seem just matter of finding a
good balance.

I read your proposal and it's interesting. I'm just worried it would be
a bit too complex, so that it would add clutter for something most users
will not use. Again I could be wrong and I easily change my mind ...
maybe there is a way to design a simple interface for it.

> I think the question is: Is this unnecessary because users usually don't
> use it or do users usually don't use it because it doesn't work very
> well with sub topics?

I think advanced filtering like what you proposed can be handy when it's
to hard to visually scan topics or bookmarks list.
The HIG suggest to not use more than 15 toplevel submenus, I guess that
can be more or less the number where scanning could begin to be
difficult (bookmarks are sorted so it can be more but ... let's keep
even such low numbers). You cant expect all topics to be filled at the
same way, so let's limit to 10 * 10.
IHMO if we can make an easy interface to manage 100 bookmarks without
requiring search, we have already won ;)
I cant claim to know any not technical user with so many bookmarks.

I'm convinced a metadata approach can allow to manage a lot bigger
collections, but I think we have to be very careful to not add clutter,
in epiphany at least.
The simpler we keep the interface, more chance we give to the vaste
majority of users to be able to use bookmarks functionalities.

Marco