A Cranky Critique of Chrome’s “Enhanced” Bookmarks

Or, a brief rant on user interface design.

Recently, I left a job and a vestige of my former employer — some intranet bookmarks that were synced across my computers through the magic of Google — needed expunging. No problem, I thought. ⌥⌘B, select a few bookmarks,⌫, bam, done.

Ah, if only. My inner monologue continued:

1. Huh, clicking on a bookmark opens it in a new window. How do I select?
2. Right-clicking brings up the generic context menu. Not it.
3. Maybe the list view lets me select things? Hmm, nope?
4. Are those three dots (⋮) for reordering? Oh, it’s a menu. Aha, delete!
5. [Proceeds to click drop-down on several dozen bookmarks, one by one. Painful Farmville flashbacks ensue.]

Thus went my introduction to Chrome’s “enhanced” bookmarks. I tweeted how to restore the old interface, and was surprised by how many shared my frustration:

One should always expect some resistance to change, but this seems to have struck a chord. Here’s the thing:

I don’t want to “manage” my bookmarks. It’s shit work. Your responsibility as an interface designer is to make it as fast and simple as possible, and let me get back to my life. I don’t even use the bookmarks menu, bar, or folders. I use address bar autocomplete, so all I care about is whether a URL will autocomplete or not.

The bookmarks interface — and user interfaces in general — should maximize efficiency in performing necessary tasks and minimize cognitive load in doing so. This is especially true if the work has minimal intrinsic value.

So where did it all go wrong?

Missed Conventions

One challenge in browser design is the line between the native user interface and a web page. Do I expect the browser’s interface — such as menus and settings — to behave like a native app on my operating system, or like a web page? Should the context menu be, well, contextual, or should it be generic? Can I use page navigation (back, forward)? Can I use in-page find? Can I bookmark the Bookmarks Manager?

Personally, I want the browser to feel like a native app and web pages to feel like web pages. Vendors are increasingly implementing parts of the “native” browser interface on web technology, and this is revealing subtle differences between the two worlds. (I do not mean to suggest that using web technology is inherently bad; only that crafting a beautiful and usable interface requires careful thought, especially if you are implementing low-level interface concepts like lists and selections.)

In the new interface, commands like ⌘F and ⌘A don’t search or select my bookmarks, respectively. Nor does ⌫ delete. This feels like an oversight. Perhaps it’s reasonable that ⌘N opens a new window, but surely ⌘D in the Bookmarks Manager would be better suited for bookmarking a new URL and not the manager itself.

Well, of course right-clicking does this. What was I thinking?

The old interface wasn’t perfect. The select-all command only worked if you clicked in the “Organize” tab first; the context menu was contextual but looked janky; and certain conventions were missing, like entering a new bookmark by double-clicking the space below existing ones. But it kinda worked, and was simple.

The old, “unenhanced” Bookmark Manager. Despite the name, it can manage more than one bookmark.

Conventions are critical for usability. They allow users to transfer knowledge developed elsewhere, from other applications, to the new application and vice versa. Violating convention is particularly damaging because you are not just asking the user to learn something new but to unlearn something old.

Oh, the Modality!

A human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user’s locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system’s current state. — Jef Raskin

There are other things I am tempted to nit-pick (the generic autocomplete for search, the meaningless colored patterns in “Tile” view, the creepiness of public bookmarks…), but I want to focus on a particularly fatal flaw to usability: pervasive modal behavior.

Just as conventions apply across applications, conventions apply within applications too. Modal interfaces in effect violate their own conventions and are harder to learn because they do not behave consistently: in different contexts, the same input performs different actions. Learning is predicated on consistency because we are building a mapping from input to output through experimentation. A complex mapping will take longer to learn, and an unreliable one leads to frustration.

Consider what happens when you click a bookmark. Normally, this opens the bookmark a new window. That is surprising, but even more surprising is that if you have another bookmark selected, clicking selects rather than opens! The old interface avoided modal behavior by requiring a single-click to select and a double-click to open.

Displays can be modal, too. One of these favicons is not like the others:

Hovering over any bookmark in the list view replaces the favicon with a checkbox. Unfortunately, its minimalist appearance — a square — does not suggest a checkbox; it resembles a broken favicon. Even if you understand it to be a checkbox, its appearance on hover incorrectly implies that clicking anywhere will select the bookmark.

Better would be to always show the checkbox. There’s ample space. If the opening, selecting, editing and deleting actions were more discoverable, you wouldn’t even need a dropdown menu.

I still haven’t figured out what the invisible “Other Bookmarks” folder is, and why I have to put my bookmarks in the Bookmarks Bar to get them to appear in the Bookmarks Menu rather than relegated to this other folder.

I’m just going to leave that unanswered for now.

I have my life to get back to, and you do too.