“Is it a button?”
¶ by Rob FrieselIt started simply enough. A simple 1 question: “Is it a button?” Referring to this:
This is (of course) the “All Sizes” button for any given photo on Flickr. And (also “of course”) depending on how pedantic you want to get and/or how technical, it’s arguably not a button at all:
…it’s an <a> masquerading as a <button>? Or is its “buttonness” defined by its appearance? Or is it defined by its function? Or by some other, harder to define, harder to quantify quality?
It’s an interesting question. On the web–where anything can “be a button”–what makes something a button? What instills an object with “buttonness”? Let’s try a few definitions on for size:
- Only a <button> is a button. If we wanted to be strict about it, this gives us a good baseline. Only that won’t work in any practical sense because then hardly any modern site actually has a button.
- Any <input> element in the DOM with a type of button, reset, or submit. (And maybe also type of image?) Again, this is a decent “strict” definition to use as a baseline but probably not one that is terribly practical. But certainly this gets us closer. Some flexibility in the input types. But still, when I looked at Amazon.com’s homepage, I saw only two <input> elements in the mark-up–and neither was a button. But this arguably isn’t a terribly good definition for a button anyway because you’re still just one line of CSS away from having an invisible button. (And what good is an invisible button?)
- If it looks like a button (and quacks like a button?) then it must be a button. Sufficiently vague? This starts to feel more correct though. Someone needs to be able to look at something and say “when I click on this, something will happen”.
But that brings us around to our original question: is it more the look of the thing that makes it a button? or is it the action of the thing that makes it a button? We know that it can’t be a strictly technical, strictly mark-up definition–because then hardly anyone would have buttons. Where then is the middle ground? What bastardized hybridization of links and graphics and input mark-up and JavaScript 2 turn a “simple link” into button?
Because a link isn’t a button, right? Unless it is a button?
Let’s agree to disagree here; let’s at least settle on this much: there are going to be some times when a link and a button are visually indistinguishable from each other; and there will be times when a link and a button will be behaviorally indistinguishable from each other. So perhaps we can start with this premise to at least differentiate these two concept (maybe un-muddy the waters a little bit):
A link is a navigational tool that moves the user between separate pages (and not necessarily within a given site) with no expectation other than acting on that navigation; a button acts on an object within the page and the user expects some non-abstract contextual change as a consequence of acting through that button 3.
That being said, from a functional perspective, “buttonness” comes from performing an action. (Any action?) What about format then? What is the shape that a button takes?
A couple of questions come to mind almost immediately:
- Must a button have a border? If not, do you embellish in some other way?
- Will your buttons have icons? Always?
- Will your buttons have text? Always?
- Do your buttons ever contain (or is it “conceal”?) a menu of additional/alternate/secondary actions?
- Are buttons always bound to toolbars? Or can they show up anywhere?
In other words: not so obvious, not so straightforward.
A few cases to consider:
Flickr.com
It was their button example that started this whole thing; vide supra. Their design seems to eschew “buttons” in favor of action-bound “links” (e.g., “Add a Person”, or “Add a Tag”). Where they have buttons (which are not actually <button> elements but <a> elements), the buttons are borderless and ghosted until you hover over them; and they’re lined up as though they are in a toolbar but–if you have a portrait-oriented image–that invisible toolbar may extend beyond the boundary of the image (i.e., the object that those buttons act upon). And then there’s the buttons bound to the comment form–which are blue and have no border but are <input> elements. But OK–I’ve heard that the Flickr team are heretics.
Amazon.com
Again, a design that seems to eschew buttons in favor of links. But where we do have buttons, they appear to be graphics that are both bordered and embellished in such a way that they “come off” the page (i.e., with that raised plasticky 3D look) and they’re bound to specific widgets like the carousel (bordered, with icon, no text) or else they are bound to major actions like adding an item to the shopping cart (bordered, with icon, with text).
Hmm… I see a lot of “links” and a few “icons” but no… Oh wait, there’s a button. (And for those keeping score: bordered, no icon, with text.)
A canonical example? Bordered (and with simple corners!), no icons, just the text–and no real special embellishments of any kind save for a little light gradient. (They’re even <input type="submit"> elements.)
Hmm… And hmm again. A pattern emerges? But does the border really make it a button?
Perhaps the whole thought experiment is a bit pedantic but in considering usability and user experience, the button ought to be (instantly?) recognizable. Ultimately it comes down to having a consistent and predictable scheme across your application/site–so if you really aren’t interested in putting borders around every button then I suppose you don’t need to; perhaps always pairing icons with text is enough. But if you’re to crib from the big successful players then we can infer that there is some magic fairy dust sprinkled onto the border.
For my money, I’m not a fan of the “ever-present” border–buttons are usually in toolbars (right? no?) and that ought to be enough to give away its intended purpose. But I think I can come around on the borders. What about you?
- Really? Simple?[↩]
- If there is any need for JavaScript at all.[↩]
- Does that clear things up? No, not for me either.[↩]
Leave a Reply