Among the minor tweaks we introduced with the new Basecamp project switcher are some larger link targets at the top of the screen. Since then I’ve been paying extra attention to link target size. Here are a couple examples of generous link targets for inspiration.
Threadless has featured large link targets on its main navigation for a long time. Here’s what the nav looks like:
As a user, when you glance at this nav, you might imagine the specific pixel areas that you need to target like this:
But when you move your mouse toward the nav, you’ll be pleased to discover the actual link targets are much larger:
The end result is a feeling of comfort. It’s just really easy to click the links. It feels like the links are working with you instead of against you.
Flor does the same thing with their links. Here’s the navigation:
Here are the targets you might aim for:
And here are the actual targets:
You might have noticed both of these sites use images for their navigation links. The same effect is easy to achieve with HTML links. Just use padding where you might have had whitespace.
Normally you might have white space between your links like this:
<div class="nav"> <a href="">First link</a> <a href="">Second link</a> </div>
Instead, use clickable padding on the anchors to create space between them:
<style>
div.nav a { padding: 5px; }
</style>
<div class="nav">
<a href="">First link</a><a href="">Second link</a>
</div>
Note how the anchors touch each other with no white space in the second example.
We do this in quite a few places in our apps and think it’s one of those small things that makes a big difference.
Jesper
on 25 May 08It’s precisely because this is fairly old hat from a technology standpoint that this is a good litmus test of sites with a basic clue in usability.
(Luckily, tact prevents me from noting how you, for example, can’t click the balloon or anything but the actual text in the comment count link near the top of this post.)
Brooks Jordan
on 25 May 08Loved hearing about this hidden design element, Ryan. These little things do make all the difference.
Tim Van Damme
on 25 May 08Why can’t you patent blogpost-ideas… Nice write! Just don’t try pushing it, leave the user some space where he can “rest” his cursor. Otherwise it’ll turn into a mine-field.
Tim Van Damme
on 25 May 08Oh and one other thing: Use lists instead of a row of anchors.
Dylan FM
on 25 May 08Be conscious of your baseline when playing with this padding.
ceejayoz
on 25 May 08I believe IE6 (not sure about IE7) requires a link to be set to display: block for the top/bottom padding to show up.
Chris Garrett
on 25 May 08Very good point, definitely one that’s often overlooked. However, it’s really not a good idea to remove white space between the links like you’ve done in the second example, try disabling CSS and seeing what it looks like. Then imagine how a screen reader interprets it. Better to use an unordered list like Tim points out.
Travis Schmeisser
on 26 May 08I remember doing a little happy dance at my desk the morning I noticed the “Back to Dashboard” link had extra padding.
Mike
on 26 May 08Meh. Competent developers have been doing this for years.
Josh N.
on 26 May 08This is something I’ve been doing for a long time using text-based navigation. I’ll build them as an unordered list and style them with CSS. Then I apply my padding to the ‘a’ tag instead of the ‘li’. Next I set the style on the ‘a’ to display:block so the entire space around the element is clickable and also makes IE6 actually show any fancy rollovers I decide to do. It also prevents the non-clickable hairline space between lines of linked text.
It definitely helps with people being able to click on the link.
Evan
on 26 May 08If anyone is interested in further reading, Dave Shea also has an excellent post about this from more of an HCI perspective. Fitts’ Law (mezzoblue.com).
Pat Nakajima
on 26 May 08You’re right. This is a great practice. Another practice that I think should get more attention is styling the :active state differently for links and image buttons. Basecamp and Backpack do a great job of this with the image buttons, but many sites don’t. Or maybe I’m just a web app snob.
Josh
on 26 May 08I thought everybody knew this.
Michael Hartmann
on 26 May 08This technique is especially important for touch screens menus. People usually have a hard time buying tickets at touch screen terminals since the are not as exact as needed (I think because of the screen needs to be extra hard to avoid it to break). Then it’s good to have the items set appart with more padding and have a surrounding area also clickable.
Will Parker
on 26 May 08I’ve been badgering our Flash devs to ‘make the hit boxes bigger!’ for the past year, with excellent results.
I have one modification to suggest. You’re doing a fine thing by increasing the hit area. However, by abutting the hit areas of adjacent links, you’re introducing a potential source of user error.
Consider what happens when a particularly sloppy click lands a few pixels across the line from the intended target into the neighboring link’s hit box.
Voom – your visitor chooses the wrong command or goes to the wrong page. And who gets the blame? The user with the poor mousing skills, or your devs? [A: It ain’t gonna be the user.]
Instead, leave a 5-10 px gap between your hit areas, especially when the consequences of hitting the wrong link might endanger the work your customer has done during the session.
BTW, I understand that the iPhone text input UI increases the hit areas for the keyboard keys predicted to be the more likely upcoming choices.
Don’t go there, because it’s patented, but take it as a hint that you can do some interesting things using the CSS :hover pseudo-class to expand the hit area for the link the user is currently attempting to target. The only trick is to settle on an expansion delta that aids targeting without unduly affecting navigating to adjacent links.
[Feel free to upgrade my Basecamp account if you decide to take that hint, BTW.]
Rabbit
on 26 May 08@ceejayoz
Setting an anchor to display: block is not always desirable. In doing so you must rely on its parent container being the desired width or setting it arbitrarily.
In cases where display: block yields unfavorable results, you can use the line-height attribute to achieve similar results.
@Will Parker
Apple patented their “best guess” hit area enlargement? Weak. Patents are dumb.
RS
on 26 May 08I think clear hover styles prevent that problem by indicating which target is about to receive your click.
Niyaz PK
on 26 May 08Good point.
Rahul
on 26 May 08Pet peeve: paging links that require you to click a 2×5 pixel “1”. Flickr’s inspirational design helped fix this, but there are still plenty of sites that do it wrong.
Robby
on 26 May 08Love how people are trolls for simply saying that yes this is a good idea, but not a new one.
J
on 26 May 08Robby, it looks to me like they are trolls because they aren’t adding any value. “I thought everyone did this” is a pricky know-it-all comment that adds nothing to the discussion. Just my take.
Jim
on 26 May 08@J,
Yes, they are pricky, know-it-all comments. I thought the same thing they did, but refrained from saying so precisely because it didn’t add anything of value.
But pricky, know-it-all comments are not trolls. Trolls are people who argue in bad faith to wind people up. Merely posting a pricky, know-it-all comment does not mean you are a troll.
Labelling them that way gives a worse impression of the host than of them. It feels like they are calling them names to avoid the point. Whether that’s the case or not, it’s hardly adding value. If they are trolls, just hide the comment altogether, don’t drag the discussion down to name-calling yourself.
fbm
on 26 May 08Why do you use this technique only in some places? For instance, the red links (New message, new to-lo list, ...) don’t use it. How do you decide whether to use it or not?
Patrick Hall
on 26 May 08A very clear explanation of this important design point. (Love the images.)
A similar point (and a personal pet peeve) is that texts labeling checkboxes should be wrapped in a label tag with the correct “name” attribute; this makes the label text clickable, otherwise the user is forced to zoom in and click on a tiny checkbox.
Shawn Oster
on 26 May 08@J – The reason a lot of comments probably come off as “know-it-all” is because to some people 37signals posts can sound a bit pompous and no one likes people that are full of themselves. Many people are reacting to the percieved tone of the posts, and then to the tone of other commenters that lavish undo praise upon 37signals for doing nothing more then repeating what many consider common knowledge.
The whole thing really turns into a generational issue. I’ve considered “padding links” a standard practice, especially for menus, for years and didn’t realize people did it any other way but then again I picked up the concept from A List Apart years ago yet there is a whole segment of developers that have probably never read ALA, are just getting into web development, or who just punch the clock and this is probably one of the few blogs they actually read.
Denver Web Design
on 26 May 08Excellent insight. I think we’ve always designed for the size of the text by default, not really thinking of making it bigger and easier to use. Once again, insightful commentary!
Jesse Dijkstra
on 27 May 08Indeed, you make a good point, however from a semantics point of view, as far as I know, leaving the space between the two <a> elements away, you create a somewhat unreadable website when you leave out the css. My opinion has always been: make sure it works and looks good without CSS as well… Then ofcourse comes the issue that most navigation menus that seem correct use list elements :)
Michael Dain
on 27 May 08Very interesting topic, but somewhat disturbing that you mix both HTML elements and clickable images, and then add padding to an inline element, which cannot accept padding by design. However, implementation does not make the topic less true. I tried to find something in response, I recommend this article to clear up a bit about what elements can have padding, and how to make ‘big’ A links. http://www.maxdesign.com.au/presentation/inline/ – unfortunately the behavior you suggest is not inherent but if you follow examples you can easily recreate it.
Matt K
on 27 May 08If you’re interested in Fitt’s Law and other core Human Factor’s concepts, I’d recommend the Universal Principles of Design by Lidwell, Holden and Butler. Very informative and beautifully designed.
Tom G
on 27 May 08This idea is especially important for radio buttons and checkboxes – make the label select the control as well.
RS
on 27 May 08Michael Dain:
Inline elements can certainly accept padding. They just behave differently than block elements. Usually horizontal padding is easy enough. To accommodate vertical padding, increase the line height of the element the inline element belongs to.
For example:
That span will break outside of the line. To accommodate its height, increase the line-height:
Basically the line-height + font size determines the maximum vertical padding you can add before breaking out of the line. So in the case of a navigation bar with padded inline elements, you can increase the line-height until you have enough interior space to use the padding you want. Hope that helps.
Joshua Kaufman
on 27 May 08Yes, this is generally a good design technique, but don’t be mislead: it’s not really Fitt’s Law in action. Fitt’s Law specifically refers to the width of the target. And in each these cases the width of the target is unknown to the user.
I don’t usually condone interfaces that allow you to click on targets when the click target size isn’t obvious, but visual feedback can go a long way in communicating to user where the click target lies.
Lynn Marentette
on 27 May 08This is a good design technique that could enable web-pages to work more easily on touch-screen displays.
Matt K
on 28 May 08Using
ID = LOG2(2D/W) you’ll find that the Index of Difficulty (ID) decreases as W increases. If the user’s previous cursor position is random, then the axis of motion will be random, as will be the distance (D). Therefore, our best guess to increasing W, would be to increase the total area – since this maximizes the distance traveled thru the target.
sir jorge
on 28 May 08when designing flash based navigation, I always allow for such a thing, but css? this is new to me, I’ll definitely look into this for future reference.
Ro
on 29 May 08Ryan, here’s what I do code-wise to get the greatest flexibility—I don’t put the padding on the A element; I put it on its LI parent, and I most definitely use display block.
.nav {width:20em;} .nav li {display:block;padding:5px;} .nav li a { display:block}
I won’t bore you with the details, but trust me this ends up solving a lot of UI issues in the long run, especially vis-a-vis bg images (nav carrots, nav icons, ‘is-parent’ inidicators, etc.)
Good topic - here’s another one that is closely related: for flyout menus, it’s tricky - but very doable—to add a 10px padding to a UL flyout menu… that way the menu doesn’t furstratingly dissappear when user mouses off 1px:
Too much code to put on here, but play with it.
Enrico Teotti
on 29 May 08@Michael Hartmann I never thought about touch screen advantages of this technique, and mobile users will have easier life as well :-)
Enrico Teotti
on 29 May 08@Ro but if you put the padding on the li the anchor clickable area will not be enlarged
Ro
on 29 May 08@Enrico, elements that have the display:block property will always enlarge to fulfill the dimensions of their parent element. So if you put display block on the A elements, they’ll “fill up” their parent LI elements.
@Ryan, come to think of it, I do like to leave a sliver of non-clickability between links, be they horizontal or vertical, just to “refresh” that pointer icon. Just feels right. Maybe 1 or 2 px.
eliza
on 29 May 08Hi,
i read in your article "padded link targets for better mousing. it is verynice and interesting. your suggestion is very useful to me.Thank u
========
eliza
Leading Chicago Children’s photographer showcasing innovative child photography, baby photographs, and family photography portraits.
Chicago Photographer
Geoff Dougherty
on 29 May 08While some developers may have been doing this for years, I can attest that many don’t.
For the inverse of padded nav, check out the Bank of America website, where pinpoint accuracy is required just to check your savings balance.
They’ve somehow found a way to make the select area smaller than the nav text in many cases.
Will Parker
on 30 May 08@rabbit:
Nope. If I recall correctly, they patented enlarging the hit area based on predictive dictionary lookup using the previously typed characters as input.
As far as I know, no one has patented adjusting the size of a hit area for the element currently being targeted via some pointing method, and I doubt if that would withstand a prior art challenge.
Patents “dumb”? I certainly think that patent holders are capable of wielding their patent rights in a pig-headed manner, but patents can also prevent creative individuals from being ripped off by the rich and powerful … which is why the practice was originally adopted.
@RS: You can signal link selection with hover styles, but again, there’s a chance for position error at the edges of every clickable area. This isn’t an issue of feedback or control for the user; it’s about the inherent level of mechanical inaccuracy in the arm-hand-pointer system.
With directly adjacent hit areas, small errors in cursor location due to either hand motion or unstable position sensor feedback can have large consequences. Build in insensitive buffer areas around your clickable areas, and you greatly reduce the chance of this sort of error.
Will Parker
on 30 May 08@Geoff D:
The first time I encountered really poor usability on text links was the day after I started my current job. A Flash developer had inexplicably decided that only the letters in the link text would be clickable. Miss the pixels of the letters, and you got bupkis.
Never trust a programmer who’s completely happy with his own work.
Jim
on 30 May 08@Ro,
Not when you put padding on the LI elements. That’s the whole point of padding, to give room between an element’s contents and its border.
This discussion is closed.