Archive for the ‘ui’ Category

everything that is wrong with bookmarks

February 15th, 2011

The history of bookmarks is one of those tragic stories in technology. When bookmarks were first introduced (by Netscape? or maybe it was Mosaic?) they were a huge step forward. Trying to memorize urls or writing them on paper clearly weren't methods that worked well. The idea -- and so simple too -- that the browser could remember the urls for you was the perfect solution.

Sadly, since the "big bang" of bookmarks there have been precious few new explosions.

The basic problem

The introduction of bookmarks, welcome as it was, created a problem that remains with us today. Once you start bookmarking pages, you inevitably produce a list of bookmarks that becomes more chaotic and less useful the longer it gets. Sure, a list of bookmarks is useful when you can look at it and quickly know what is there, and when you can see the bookmark you want to load right now.

But when you start having to scroll the list, and not only that but use the PageUp/PageDown keys to scroll the list quicker, it's a good sign that it's getting out of hand.

A collection of bookmarks is all well and good, but it needs some kind of structure superimposed on it to remain effective.

The bookmark toolbar

The bookmark toolbar encapsulates the insight that some bookmarks are more important than others and offers a number of improvements:

  1. Allows marking some bookmarks as more important/more frequently used.
  2. Gives them better visibility.
  3. Provides quicker access to them (by not having to go into the bookmark menu).

The bookmarks are displayed on a toolbar, either as links or as links-within-folders.


Despite how useful this feature is, browsers have historically treated it as something of a marginal feature. Firefox, for instance, used to view the launcher toolbar as just another folder in the bookmarks collection (albeit with a special name, like "Personal Toolbar Folder"), which you could accidentally rename or delete, and then it wouldn't show up as a toolbar anymore.

Another thing that matters a lot to the usability of the toolbar is the drag-and-dropability of bookmarks onto the toolbar, into the folders, and from one place to another. Even today, for instance, in Google Chrome I can't reorder the items in a folder on the toolbar without opening the Bookmark Manager.

Import/export (and the silo)

It hardly needs stating that once you have a bookmark collection in one browser, you don't want to manually recreate it if you decide to use another one. Browsers have historically been reluctant about giving out their bookmarks. All too often, despite making a show of offering to import your bookmarks from another browser, the import mechanism has bordered on the useless.

First and foremost, every browser vendor since the Ice Age has been eager to supply you with a tasty selection of bookmarks that he was convinced you would love. Importing your own bookmarks, therefore, could at best be seen as a supplement. No browser would ever just take your existing bookmarks and overwrite its own vendor-supplied ones, which is exactly what the user wants. Instead, it would stash them somewhere in the bookmark collection, well out of sight. Any additional metadata that was implicitly stored in your bookmarks would often be lost, like the order in which they were listed.

In particular, the browser would make no bones about trying to find out if you have a bookmark toolbar in there, and replace it with its own (despite the browser having a toolbar feature that worked exactly the same).


So having done an "import", you would typically have to manually organize your bookmarks, nuke the stupid vendor bookmarks, and sometimes you'd even have to recreate the folder structure of your bookmark toolbar, all before you had been able to achieve the same state as in your other browser.

This kind of situation is standard silo behavior. By making the import feature so mediocre, the browser vendor would pretty much ensure that the user would not switch browsers without paying a high price for it. Simply using more than one browser on a daily basis, with an easy way to manage your bookmarks across them by a quick sync, is just not realistic.

Bookmark sync (and more silo)

A way of keeping your bookmarks synced across computers has been a no-brainer feature since the era when people started accessing the web both at home and at school/work. And yet, a working synchronization feature is a pretty recent development in bookmarks. I recall some failed attempts with Firefox extensions in the remote past, but at last it is here.

A number of browsers have a sync feature now, and it's a big step forward in bookmarks. Even if your bookmark collection is a mess, you can at least have the same mess all over the place. Clean it up and it's clean everywhere.

And yet, bookmark sync is yet more silo behavior: you can sync your bookmarks from Opera to Opera, but not from Opera to Firefox. The fact that bookmark sync doesn't do the same half-assed job of the import feature might seem strange, but the motive is very obvious:

  • ability to have your bookmarks up to date in our browser on every computer = good for the vendor
  • ability to have your bookmarks up to date in every browser = bad for the vendor

Browser vendors know very well that if bookmark sync worked as poorly as bookmark import, they couldn't sell it as a feature, because noone would use it.

Bad page titles

Strangely enough, I've come all this way without mentioning just about the most glaring problem that bookmarks have: bad page titles. Since the name of the bookmark is simply the title of the page in 99.99% of the cases, the title ought to be both descriptive and concise. Instead, we have historically seen that web creators much prefer titles that are variations on this theme:

The Excessively Long Title Of My Website Which Is Very Nice Indeed: Section Title: Article Title

With titles like that, all too often you can't even see the title of the article in your bookmark list, because the text is truncated somewhere in the middle.

Quite apart from the length problem, web sites often prefer to give articles catchy titles rather than descriptive ones. So with a title like:

Something Amusing That Makes You Think About What The Page Really Is About

you have the short term benefit of being amused at the cost of the long term benefit of a descriptive title.

Bad metadata

Bookmarks belong eminently to the category of things where the number of items is so large that it would be great to have a way of automating the retrieval/organization of the items.

Yet, despite announcements from Mozilla in the past that they would soon obliterate the old model of bookmarks-as-a-list, and introduce a new and all-conquering search based approach, we still have the list. The fact is that bookmarks don't contain enough metadata to make search useful. A bookmark has two pieces of data:

  1. The name of the bookmark.
  2. The url.

Sure, some browsers give you the option to store other things too, like tags, but if we all agree that the user can't be bothered to keep their bookmarks organized, let's not pretend he will actually input any of the optional stuff. And even if he does, 90% of his bookmarks won't have any other data associated with them, so we're back to the short list above.

So why doesn't search make sense? Because much too often neither the title nor the url contains any of the keywords that you would want to use in order to find this bookmark. Web sites don't pay too much attention to titles, and the real data that would be useful to search is the page itself, which is not available.

Bookmark oblivion

What should seem ironic is that bookmarking a page often has the effect of not bookmarking it at all. The bookmark is saved somewhere in the long list and then never seen again, either because the list is too long to really bother looking at beyond the most recently added items, or because the page title is useless, or because it was bookmarked "for future reference", and by the time we return to this topic we've forgotten about the bookmark.

We tend to grow pretty oblivious as to what's in our bookmarks. Over time, some pages expire, others drift out of our sphere of interest, yet the bookmark collection doesn't get updated.

Just about the most obvious feature a browser might offer is to try loading the bookmarks from time to time, in the background, and marking the ones that return 404.

Another idea might be to offer to list bookmarks according to how often they are loaded, making the never used ones fall to the bottom of the list. Applying this to the bookmark folder might be especially useful, so the user doesn't have to reorder the bookmarks to make the frequent ones quicker to reach.

more bad ui from Adobe

January 27th, 2009

Found this Adobe ui bashing blog today. I really think we need more of this, our standards for ui aren't good enough. We do a lot of criticism for bad code, because we're technically minded. But bad code is less harmful sometimes than bad ui.

There's a reason ui critique is so hard to do without getting into a fit of fury. It's like a guy standing over you saying "no, don't tie your shoe laces like that, do it like this". And then he forces you to do it his way every single day for the rest of your life.

Of course, this isn't the first time we've seen Adobe, the tool builders for the designers of the world, complimented on their ui.

java plugin galore

January 25th, 2009

Ever lay awake at night wondering what happens when you hit a web page with a java applet on a vanilla Ubuntu? Me neither. It turns out that it's this:

Embarrassment of riches! There are a few problems with this feature:

  1. While it's great that you help me install the plugin, I have no idea what all these things are. All I wanted was "java".
  2. There is no "default" or "recommended" choice. I can see that one of them is selected, but for all I know that's because the choices showed up in this order at random.
  3. Even if I were inclined to think that the selected choice is selected for a reason, there's another choice that's exactly the same.
  4. "No description found in plugin database." is not exactly helpful. In fact, it could be just the thing to help me here.
  5. If I wing it and install one of these, and then it turns out it doesn't work (perish the thought!), the little notification at the top of the web page isn't going to show up again (because a java plugin, working or not, would be installed). So there's no way I can come back to this screen.
  6. If I am the kind of user who understands that the choices in this dialog represent packages in the system, then I don't know what they are called, because the package names are not mentioned. So if I want to uninstall a plugin that doesn't work, I don't know what to uninstall.

There is another dialog in the Firefox settings for plugins:

Strangely, there is no option to uninstall plugins here, just disable. But I guess that if I disable the java plugin, I can revisit that java web page and get that plugin selection dialog again (and try a different one). Still, it takes a bit of detective work to figure that out, it could be made more obvious.

This example demonstrates the difference between starting on a problem, and actually solving it. I'm very pleased that we have these helper dialogs now, but it needs a bit more thought put into it.

Bug: #320989
I actually picked this example because there used to be two or three options in that dialog, but now there are five.

konqueror ui regression

August 1st, 2008

Well well, what have we here? The omelet is well underway in the pan, but we've dropped some eggs on the floor, that's too bad. KDE likes to try things, and that's really cool. I'm pleased as long as they do not stop trying until they produce a better, or at least an equally good, outcome. (Which is my experience with KDE so far.)

There is another slight regression here. The click area for the plus (+) sign beside each directory (the one that expands/collapses it) appears smaller now, after the icon has been changed. It's smaller now, and it was already quite small before.

Ubuntu Bug: #254039

KDE Bug: 168379

I'm not submitting it specifically to kde bugzilla given how Shuttlesworth raves about Launchpad's synchronization capabilities to various bugzillas every chance he gets. Hopefully that means they have a link set up with KDE as well. The regression was spotted in Ubuntu anyway.

great ui writing is precious

July 4th, 2008

Writing about ui is difficult, not because it's difficult to describe the flaws of an interface, but because of how emotionally draining and depressing it is to point out the problems in a product with which your experience has been infuriating. It's like re-living the experience, you just want to forget all about it and run away.

It is hereby my pleasure to present to you a piece of wonderful ui writing which describes the beloved Adobe Acrobat Reader. Here's a taste:

After the unpacking, the install process itself took 10 minutes. I could only thank Adobe’s engineers, presuming they were filling up my hard drive with yummy icons, tasty DLLs, and amazing 3D JavaScript add-ons. No matter — the 210 MB it required was there to be used.