Re: [Epiphany] Re: [Usability] User defined metadata (was: epiphany toolbar/bookmarks)
- From: Daniel Borgmann <spark-mailinglists web de>
- To: Marco Pesenti Gritti <mpeseng tin it>
- Cc: GNOME Usability List <usability gnome org>, epiphany mozdev org
- Subject: Re: [Epiphany] Re: [Usability] User defined metadata (was: epiphany toolbar/bookmarks)
- Date: 01 Jun 2003 23:20:13 +0200
On Sun, 2003-06-01 at 18:15, Marco Pesenti Gritti wrote:
> > 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.
Hm true. It's just a bit less convenient in the end. More annoying might
be that you have to write the category in the subject for each bookmark.
> > 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 :)
True again... Some kind of rating for bookmarks could certainly be very
useful in many cases.
> 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".
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).
> 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.
Yes... I think that the most simple kind of user classification would be
good to go, as long as it's not dropped completely. :) Maybe rating
would be enough already, but it has disadvantages.
> 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.
> > 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.
So what should I do now, if I have about ten or twenty bookmarks in one
topic? Stop adding bookmarks? Try to split them up into different
topics? This is the kind of dilemma that killed other bookmark systems
for me. I don't want to care about that, I just want to add every
interesting bookmark and know that I can find and use it again
conveniently, even if this means thinking for a second while adding the
bookmark. But if you force me to use a search based on subject and
keywords before I can use a bookmark, then it's hardly faster than a
Google search. The big advantage of user bookmarks compared to web
searches AFAICT is, that the user can put them into categories and
classify them, which should allow much quicker access.
A practical example would be my aforementioned "Gaming" topic. I have
currently ten bookmarks in there, eight are about one game alone. At a
later date, I might add another ten bookmarks. Then I might get into
another game and add ten bookmarks about this game. Now add a third and
fourth game and the list will grow quickly. I could remove bookmarks for
old games to keep the list small but I might get back to a game. My
interests change quite often (gaming and other things alike), so I can
be sure to face this dilemma a lot. :)
I could solve this dilemma with my suggestion like this:
- Select the Gaming topic and then "Add new fields" [insert better term]
- Add a new field "Game"
- Select all my Quake3 bookmarks and properties, set "Title" to "Quake 3
Arena"
- Do the same with every other game
- Select the game I'm currently interested in from the appropriate
selection box in the topic view.
Absolutely gorgeous now would be the possibility to create a "virtual
topic" which contains something like "SELECT * FROM Gaming WHERE Title =
'Quake 3 Arena'" and then drag this vTopic to my toolbar as "Quake 3".
Yes, this is all extremely advanced behaviour but I think it's
reasonable. Unlike other bookmark systems, it would scale almost
indefinitely from web beginner to 24/7 geek. The only clutter which it
would add would be one more entry in a context menu (which currently
holds two items) and maybe one more entry in the edit menu (which
currently only holds the four default items).
I wouldn't argue for this (or something alike) if I wouldn't assume that
it can be done without reducing usability the slightest.
Another use case came to my mind: When using bugzilla, I often wish I
could easily bookmark bugs so I can check them later. Using bugzilla for
this isn't very convenient for me. However, no bookmark system is
flexible enough for this. A nice solution would be a "Bugzilla" topic
with a "Product" filter and maybe even other bug related filters (like
Status). Using your bookmark window to find a certain bug would be
almost as flexible as finding bugs in a Bugzilla query. :) Granted, this
takes it very far but don't you agree that this has a lot of potential?
It could even be a first step to blur the line between bookmarks and any
other data of interest.
> 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.
I completely agree with all this.
It just would be a shame not to unleash the full potential of this
approach. :)
Daniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]