2013-03-24 by Adam Pritchard
Page actions – the buttons in a browser’s address bar – are a surprising UI failure.
When adding a button for a browser extension, a choice must be made whether to make it a “page action” or a “browser action” (button on the toolbar). But browsers have failed to communicate the interactiveness of page actions, and almost no one – techy or layman – realizes that they’re clickable.
To complement the context menu item and hotkey, and to fulfil a user feature request, I decided to add a button to the Markdown Here browser extension. It turned out that simply deciding where to put the button was a big part of the effort…
I’m going to use the Chrome extension development terminology:
In the screenshot above you can see the two styles co-existing in Firefox, which suggests there’s no real implementation decision to make – just provide both, and let the user decide which style they like. That’s true in Firefox (although there’s still the lesser decision of whether or not to add the toolbar button by default), but in Chrome you can either have a page action or a browser action, not both.
The choice initially seemed pretty obvious: use a page action. From Chrome’s documentation for browser actions:
Don’t use browser actions for features that make sense for only a few pages. Use page actions instead.
Markdown Here’s button is only applicable to some rich-edit compose elements (email, mostly), so that admonition seems to apply pretty directly. Like many people, I don’t like occasional-use buttons cluttering up my toolbar, so I initially implemented the button as a page action.
…And then I showed the cool new button to my significant other, who said something along the lines of “I can click that?” Which is a pretty damning statement, for a button.
I must admit that I had some suspicions about the obviousness of page actions’ clickability. I’m fairly sure it took me a while to realize I could click them, and I’m a) pretty technically savvy, and b) pretty hover-over-everything-that-looks-interesting curious. But what if a user is not both of those things…?
(Yes, there were some people who knew that page actions are clickable. But the fact that many computer/tech/web/UX-savvy people didn’t know is the more significant observation.)
I also asked around among people at the office (coders) and among non-programmer friends, and the vast majority of both groups didn’t know they could interact with page actions. At best they thought of them as status indicators, and at worst they couldn’t remember ever having noticed them before. Ugh.
It’s hard to blame users for this lack of affordance recognition. At least, not yet.
Page actions do not display any of the typical this-is-a-clickable-thing traits. For the most part, page actions:
Some page actions have a verb-based tooltip if you hover long enough. Some. If. Long enough.
It’s a little shocking how poorly the interactiveness is communicated to the user.
Above I coyly dropped “At least, not yet.” There is a trend in UI design toward everything on-screen being interactive unless explicitly disabled-looking. Windows 8 has gone this way, as has Chrome and, to a slightly lesser extent, Firefox. There’s very, very little text or window chrome that’s non-interactive.
But even if you accept the “everything is interactive” ideal, page actions are still different than most other elements, since there’s no hover effect. And page actions are further hampered by the minimalistic design aesthetic that Chrome and Firefox seem to have adopted for them – a monochrome outline icon that can easily be read as disabled.
Maybe once users have fully embraced/internalized the idea that there are no extraneous UI elements, they won’t need hover effects and raised borders. Maybe there’ll be a great awakening to the utility of page actions. But until then…
Page actions need to look less like small, monochrome, passive, static icons. They need some standard button cues, both initially and on hover; they should employ one or more of: raisèd-ness, colour, border, more visual strength.
(I suspect that even the Chrome-style toolbar buttons – like the three-line settings button – are also below most laypeople’s threshold to recognize the click affordance. I’ve seen that in action in my own family-tech-support experience. Those buttons also lack most historical click cues. But let’s tilt at one windmill at a time…)
Finally, Chrome should allow extensions to provide both page actions and browser actions.
In the screenshot at the top of this post, you see can that Pocket’s Firefox extension uses both button styles: the page action is for saving the current page, while the browser action is for showing your saved pages. Similarly for the bookmarks buttons: page action for bookmarking the page, browser action for viewing bookmarks.
(Markdown Here also has a button in each place, but it’s not as compelling a use case, since it’s just a convenience to work around the page action affordance opacity. Both buttons toggle Markdown rendering; the page action only shows when focus is in a valid target; you can hide the toolbar button if you’re one of the few page-action-savvy users. But, still, I wish I could provide the same flexibility to my Chrome users that I do to my Firefox users.)
In Chrome, Pocket only has a browser action (which, oddly enough, acts only like its Firefox page action), and bookmarks only have a page action (and a whole toolbar). I can’t think of any reason for Chrome to prevent extensions from providing both, and there are certainly good use cases for allowing them.
I finally switched the Markdown Here toggle button in Chrome to be a browser action. Even though it clearly, spiritually, should be a page action, I just can’t ignore the fact that most users will not recognize it as clickable in that form.
I have had one complaint about the button location, but the user seemed satisfied that I made the rational choice after I explained it.
Postscript: First blog post ever! Yay! Thanks to Casey Watts for suggesting that I write it.