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

[Marco Pesenti Gritti <mpeseng tin it>]

> Sure but what if I want to switch between certain games quickly? Not
> saying that typing in the name wouldn't work at all, but it would be
> slightly less convenient. The bigger problem IMO is, that I would have
> to type in the name of the game each time I add a bookmark (if there is
> some kind of user editable keyword list). This might be more annoying
> and I have to remember if I used "Quake3" or "Quake III Arena" or maybe
> just "Quake". I don't see how this data could be generated automatically
> in a consistent way. This problem wouldn't exist with my proposal, as
> old values could appear in the dropdown list of a combobox so you have
> to type each possible value only once (I hope that makes sense).

I guess in most cases Quake will be already in the title. Retitling the
bookmark has often the benefit of make it easier to find (also with
eyes) later. You would have to remember nothing, you want to search
bookmarks related to Quake, you type quak(e) in the search field and all
the cases you listed are found.

> > 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 thought that adding new "fields" (finding a good term for this might
> be a difficult task) could be done via the context menu of a topic or
> the menu of the bookmarks window. This way it wouldn't clutter anything
> unless a user actually adds a fields to a topic. In this case a
> selection box for each field (should be one or two at most) could appear
> below the search bar when the appropriate topic is selected, maybe with
> a "remove" button. The filters could even be inside an expander so they
> can be hidden if you want to see more bookmarks at once.
> When adding a bookmark to this topic, a new dialog could appear asking
> to enter values to this fields (or just pressing enter/ clicking ok for
> no values) in comboboxes so you can quickly select existing values via
> the dropdown list or autocompletion. When editing a bookmark it could
> show those comboboxes inline the properties dialog so they can be edited
> quickly.
> I'm sure there would be even better ways but this sounds quite good to
> me. Or is there anything you would strongly object to from an UI point
> of view?
> The important thing would be that it's completely out of your way if you
> don't use it and still very easy to understand if you do want to use it.
>  

Changing the dialog layout when selecting topics, having properties
dialogs with different layouts depending on they properties, showing two
dialogs for adding a bookmark would be bad IHMO.
In general I think overcategorization slow down the user (and often
without he notice). The real cases I've seen until now are very likely
to be overcategorization (IHMO again).

> > > 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.
> 
> Here is where I disagree... I would assume that every heavy web user,
> technical or not, will collect a huge list of bookmarks very soon, if
> the bookmark system encourages him to actually use bookmarks (which the
> Epiphany system should do :)). Typical bookmark systems tend to break
> after you add so many bookmarks because they don't scale well. This is
> the main reason why I never used bookmarks strongly. Once I can find
> something faster in Google than in my bookmarks collection, it doesn't
> make much sense anymore. Keeping my list small by constantly deleting
> older bookmarks would be more work than it's worth. 

My point was basically that the ability to manage easily 100 bookmarks
would have been already a great gain for most users, not that expanding
this number would have not been positive for everyone.
I have the impression we cant assume the system could work without
remove anyway ... too many bookmarks means they are harder to find, you
can improve but never remove that basic fact.

Marco