Re: [Epiphany] epiphany toolbar/bookmarks

[Marco Pesenti Gritti <mpeseng tin it>]

On Fri, 2003-05-30 at 10:00, Murray.Cumming@Comneon.com wrote:
> gnomedesktop has lots of vague complaints about the epiphany bookmark
> system, though I can't make much sense of it and I'm not sure whether it's
> just the same kid posting repeatedly. And I've also heard some vague
> criticism of the bookmarks or toolbars from more reliable sources.
> 
> So, if necessary, can we have a quick and constructive thread about this?
> Maybe with real-life examples?
> 
> The GNOME 2.4 feature freeze is June 9th and the UI freeze is July 7:
> http://www.gnome.org/start/2.3/
> I'm not sure which one this affects, but there's a danger that it would have
> to wait until GNOME 2.6 if we don't deal with it fast. Or maybe there's
> nothing to deal with - I don't know what the problem is.

Here you are. Removed gnome-desktop and added usability list (hope it's
ok).

1 First of all, why we did decide to design our bookmarks system in a
different way ?

I think it's pretty clear that the hierarchic way of organizing
bookmarks does not work well for most people. In my experience "normal
users" (and several power users, myself included) never categorize them.
Some of them end up with a mess where it's hard to find them again,
others add them only when absolutely necessary, so they keep the number
of bookmarks very low.
These people are forced to remember a few number of addresses, which
they use often and spend a lot of time with google to find sites with an
address hard to remember. Funnily enough I have seen some users write
down the address on paper sometimes ;)
Trying to do something different, especially if you are not an usability
expert is risky. But in this case I think it's absolutely worth.

2 So, what approach did you take to solve this problem ?

Instead of a filesystem like approach with folders and subfolders we
decided to take a database like approach. The address of the bookmark is
stored with some metadata associated to it. Part of the data is get
automatically (right now only title, address and number of accesses, but
in the future we could put keywords there for example), part is asked to
the user the first time a bookmark is added (the topic/s).
Basically we dont ask to the user to put his bookmarks in folder and
subfolders, but we get information about the adress (automatically,
asking the user and combining both this for the title) and we build a
view of the collection based on these information.
This is an rdf representation of the bookmark in epiphany:

  <item rdf:about="http://www.clarence.com/";>
    <title>CLARENCE - A WWWorld Apart &#xAE;</title>
    <link>http://www.clarence.com/</link>
    <dc:subject>
      <rdf:Bag>
        <rdf:li>Entertainment</rdf:li>
        <rdf:li>News</rdf:li>
      </rdf:Bag>
    </dc:subject>
  </item>

3 This was just the theory, how does it work ?

Wait, there is still a theoric step. We built a prioritized list of
tasks and we based
our interface design on it.
See http://mpgritti.oltrelinux.com/bookmarks.txt

3 Ok ok, I dont care about theory. How does it work in reality ??

Fine.

As in any other bookmarks system you can add a bookmark from the main
window menubar or with ctrl+d. You can edit the title and choose one or
more topics the site is related too. For example if the site is about
cinema news, you will check the News and the Entertainment checkboxes.
See http://mpgritti.oltrelinux.com/add.png

The main way to find your bookmarks again and open them is the bookmarks
view.
We decided to use a window instead of a menu because it's easier to
navigate and you can have search/edit functionalities in the same place.
You can "filter" the bookmarks by topics, search them using a word, see
the most used bookmarks.
You can access the bookmarks collection directly from the desktop,
without opening the browser window.
Also in the same place you can edit the bookmark title inline, like in
nautilus, add more topics, remove bookmarks, associate them
to more categories with drag and drop, edit bookmark properties (title,
url, topics).
I think this is very important, you usually want to change the bookmark
just after you have seen it or navigated it, requiring an extra step is
an usability problem.
That's why context menus over bookmarks menu in galeon was so popular,
but I dont think that's a good solution.
See http://mpgritti.oltrelinux.com/bookmarks.png

There are other convenience way to access bookmarks fastly:
- a list of most used bookmarks in Go menu
- typing a word in the toolbar entry, which is part of our "let's make
urls less
important for browsing" strategy
- the bookmarks toolbars (but requiring "editing" means most users will
not be able to use them I think)

4 Interesting. I see lot of people on gnomedesktop complaining about it
and some others saying that they started to use bookmarks only with
epiphany. What are people complaining about ?

I think it's partially a problem of getting used to something quite
different and partially a few usability problems we have still not
solved. Designing something from scratch, without copying here and there
is hard and can cause temporary regressions for someone. But I think
it's worth to do it when there is a lot to gain and not much
to lose.
Anyway here is some raw data about the problems users have with it.

- Importing bookmarks from mozilla/galeon can make them hardly usable,
if you had subfolders. (But how many people had them ?).

I think we can improve quite a bit here, but it will hardly be ever
perfect.

- A bookmarks menu make the feature more visible and easier to find
It's a sort of standard, people feel odd to have File->Add Bookmark and
Go->Bookmarks..., they often just dont find it.

- Having a window as primary way of accessing bookmarks has adavntages
(easier to navigate, search in place, editing in place) but gives some
problems.People are used to have a bookmarks menu and dont understand
that the main way to access bookmarks is the window. (The article about
epiphany bookmarks that talks a lot about the "type topic in location
entry" convenience feature make the situation worst people thinks that's
the main way to access them).
There is no clear indication of where the double clicked bookmark will
open.
I guess Apple had to embed the dialog inside the browser also for this
reason ?

- There is not a very fast way of opening often used bookmarks. Well
most used bookmarks are listed in the Go menu, but for some reason
people dont use it much, maybe they just dont look in
the Go menu for bookmarks. There are toolbars but requiring editing
means not many people will be able to use them.
If the most used bookmarks was listed in Bookmarks menu, it would
probably work better.

- Searches are currently not very "rich", so if you have 2000 bookmarks,
it can be hard to find them. But on the long time a database approach is
obviously the best also for people with so many bookmarks.

The solution is clear here ihmo. Have more metadata on the bookmark (for
example keywords).

5 So you think GNOME should ship a browser with this bookmarks system,
even if it has some usability issues ?

Frankly I did not start design something different with GNOME inclusion
in mind.
Epiphany was my fun project, I was mainly trying to design something to
convince me to use a feature that I was just not able to use before.

That said, I think system is matured quite a bit recently, that there is
several space for improvements, and that in general we are heading the
right direction.
Shipping it with GNOME will means to generate some flames on
gnomedesktop, no doubt.
There are people that loves hierarchies, that know exactly where to find
their bookmark in the 3 levels of subfolders they have; these will
unlikely be happy with the work we did, even if the usability problems
are solved.

My personal opinion is that GNOME should not aim to make this very low
part of user base happy. Obviously it's worth to improve "compatibility"
with the hierarchic way of organizing bookmarks but keep it just because
it's what power users are used to is not a good idea. Temporary
regressions (for someone) are worth when the percentage of the user
that will likely benefit of the changes is way higher than the
percentage of the users that are perfectly happy with current status.
IHMO current system is already an improvement for most users, compared
to a hierachich system like the galeon one.

Also, even if designed separately we ended with something very similar
to what Apple did with Safari. That confirms that we are heading in a
good direction. That doesnt mean there are no problems, but just that
they can be solved.

Finally I think what we did with bookmarks is in line with the database
like approach (to replace filesystem), where GNOME seem to be heading in
the long time. Testcasing it on a less fundamental feature will be a
gain for GNOME as a whole.

Ok, I hope to have cleared up the issue a bit. Probably Dave Bordoley
will have something more sensible to say about it.

Marco