How to compose link text

When linking part of a sentence, what words belong inside the link? This seems to be a lesson that every new UI designer stumbles on.


Click here to see the next page.

Because readers scan text, the link is read as standalone (“here”) text and is unintelligible.

Still bad

Click here to see the next page.

Link includes the verb – at least the reader knows what action is expected.


Click here to see the next page.

When this link includes the whole sentences as context, it can be scanned and interpreted.


Click here to learn how to compose link text.

Now the link includes an indication of what to expect after clicking. Also note that the destination page’s main heading mirrors the link.

Going overboard

Click here to learn how to compose link text.

Because the destination is the primary goal of the link, you can emphasize it to help the reader focus on the meat of the interaction — the destiation.

Cleaning it up

Learn how to compose link text.

At this point in the life of the Internet, users know that links are clickable. No need for “click here” if the link is styled to look like a link.

35 tips for writing for online and mobile UIs

Writing for web- and app-based UIs often means breaking traditional grammatical “rules,” which were derived from different user contexts (slower publishing/delivery cycles and longer attention spans).

Here are some rules for better interface writing, courtesy of Jakob Nielsen and my own interactive product design experience.

Nielsen’s reader research demonstrates that people scan UIs and apps instead of reading them word by word.

Create scannable text by:

  1. organizing content in an “inverted pyramid,” starting with the conclusion, then supporting information, then background / framework.
  2. cutting the word count at least in half. Users read only 20% of the words (28% at most). This percentage drops as a UI’s total word count increases.
  3. highlighting keywords (links and bold).
  4. using meaningful (not “clever”) sub-headings as organizational demarcations and summary statements.
  5. organizing content into bulleted lists.
  6. focusing on 1 idea per paragraph, in the first few words.

Here are some more “writing for the web” tips from Jakob:

  1. Users scan instead of reading (though users consume long-form content, e.g. ebooks, differently).
  2. The best online content is linear, reader-driven, actionable content composed of specific, comprehensive data. Fragments trump sentences.
  3. Write numbers as integers (1) instead of text (one) to address readers’ desire for “facts.”
  4. Your headline text gets 40-60 characters of attention. It must stand on its own and make sense when the rest of the content is not available.

More rules for writing for the web

These are my own basic style rules, based on ad hoc experience.

Ask “What would the NY Post do?” Think tabloids, not novels.

  1. 1 action per page/screen. My usability tests consistently indicate that users quickly fixate on a single idea “satisfice” within a UI and ignore alternatives.
  2. 1 idea per paragraph. This typically means 1 sentence per paragraph, sometimes 2. A 4-sentence paragraph is almost always too long.
  3. Numbers, not words.
  4. Lists, whether numbered or bulleted, are your friend.
  5. People look at photos first, especially photos of people.
  6. It’s better to display nothing than default images or filler text.
  7. Semicolons are almost never okay.
  8. Short lines of text are easier to read. Lines of text generally shouldn’t be longer than 34 ems long. (An “em” is generally equal to the height of the typeface – it’s a measurement based on the width of the letter M at the text’s current size.)

You’re always better minimizing visual emphasis. Focus on using fewer words, so they aren’t all competing for the reader’s attention.

  1. You can center 1 piece of information per page. Centering breaks a design grid and thereby becomes the most important thing on the page.
  2. Stick with bold for emphasis.
  3. Don’t present text in all caps unless you know the reader will stop – it destroys the letterforms. Sentence case is best. Possible exception – small words in buttons.
  4. Italics are almost never a good idea. Italic sans-serif is a typographic foul and italics generally distort letterforms too much for pixelated screens. Stick with bold. If you need a backup, try changing your emphasis style to display a highlight color on the text rather than italicizing it.
  5. Use bold sparingly. Words, not sentences.
  6. Don’t use bold, italics, and/or caps together on the same word.

Links are often the victim of “form before function” design thinking. Keep links visible!

  1. Use a very different color from the text.
  2. Include verbs in links.
  3. Include the destination page title in the link.
  4. If you hide everything else on the page, the reader should still know what the link will point to by reading the link text.

Grammar for teh internets:

  1. Log in is a verb. Login is a noun. Same with sign in, back up, etc. You almost always use the verb form.
  2. A lot is always 2 words except when it’s a verb, which is probably not what you mean. Remember it this way: “a pound, a bunch, a lot.”
  3. “It’s” is the contraction, “its” is the possessive pronoun. Possessive pronouns never have apostrophes: his, hers, its.
  4. When creating possessive nouns, use “‘s” for singular nouns, even if they end with s, e.g. “my dog’s collar is silver” or “Chris’s tutorial is helpful.” The latter is optional in some books, but if you always do it this way (“‘s”) you’ll avoid some crazy coding whenever you have to build an interface that creates a possessive noun from dynamic values like usernames.
    Put an apostrophe after the s if the noun is plural and ends in s, e.g. “the 7 dogs’ collars were all silver” or “The Judds’ interview was full of shocking revelations.”
  5. 1 space after periods, not 2. Too much spacing creates visual “rivers” of whitespace within large blocks of text.
  6. “Everyday” means common, mundane, or pedestrian. “Every day” describes the frequency of an occurrence. I wish I could write an epic blog post every day, but I can barely squeak out an everyday post on a quarterly basis.
  7. “Anytime” means “at any time” but I don’t think it’s ever okay to write “at anytime.”

Wireframe porn

Update: See Will Evans‘s extremely thoughtful response in the comments – there’s a method to this madness that I was unaware of when I wrote the post. Thanks Will, for calling me to task so kindly.

Sketches, wireframes, and mockups are an essential part of the product development process and popular standards are beginning to emerge for web/mobile app design. These 4 videos will walk you through the process – they’re follow-up from the “Right Way to Wireframe” seminar at the recent Interation10 conference.

Will Evans, one of the presenters, recently posted 2 great articles on his blog – they more thoroughly describe his process:

I think it’s important to remember, especially in a resource-strapped startup, that nearly everything described in these videos amounts to procedural overhead – the actual end user (customer) never sees these, so they’re only valuable insofar as they help you create great products. Which can be tricky, because as you’ll see, wireframing is fun to the point of distraction. As soon as you’re building wireframes, documents, or any other procedural component at the cost of building the actual product, your ship is sinking.

As a complement (antidote?) to these videos, I’d strongly recommend 4 chapters from 37Signals’ Getting Real ebook:

And now, the wireframe porn
Good explicit definition of the full process, though the wireframes are a little too pretty for my taste. They’re spending a lot of time spend designing a throwaway mockup, which is poor ROI (this is likely a project with big overhead, so they can afford to fall in love with disposable process artifacts). There’s another, arguably more important cost to pretty wireframes: they have a coherent brand and design that can seem so similar to a finished product that they distract the decision makers from the final design and create unintentional biases (e.g. for minimal, grey and blue designs).
The hand-drawn placards are a nice touch, but this one is a bit vague regarding what’s actually going on. Process porn? There is a nice reference to card sorting and site map design as a prerequisite for individual pages, and the focus on hand-drawn sketches initially is a welcome addition to all the wireframing technophilia. Finally, the repeated start-to-finish flows from sketch to wireframe to page mockup help explain the transformation of a UI through each step.
This video skips over explaining requirements and how they become page concepts, which makes it far less useful than the others. The actual page requirements are pretty lightweight too, so there isn’t a whole lot to learn here. Also falls into the category of too-pretty wireframes. Man, I wish this UX calendar were a real project though!
This last one is from the aforementioned and soft-spoken Will Evans. God bless anyone who includes “motherfuck” in a description of the wireframing process. Also nice that he links to the tools usedOmnigraffle and wireframe stencils from Konigi.
Will starts with sketches before moving to the computer, and 1 standout item is the flow arrows that link the initial thumbnails – it’s an excellent alternative to traditional sitemaps and better suited to application-oriented experiences (as opposed to document-oriented). Also unique in the bunch is the inclusion of blue callouts in the wireframes, explaining each feature and grounding this process in a larger dev flow.
Will’s blog post, Shades of Gray: Thoughts on Sketching, does a good job of explaining the role of hand-drawn sketches in this process, which is arguably the most valuable lesson to take from all of the information in these videos.

Thanks to Josh for sending me the initial link.

Know of any other good “how to wireframe” videos? If you share them here I’ll work them into the post.

Peak shift

First read about this on Dustin Curtis’s blog, which describes an experiment where a mouse trained to find food at a rectangle will choose a more rectangular rectangle if the option presents itself.

Lesson: rather than look for specific patterns, animals identify a characteristic features and look for the “peak” instance.

Another example is V.S. Ramachandran’s Herring Gull Test, where he showed that gull chicks identify their mother’s beak via it’s red stripe. When he painted extra red stripes on a yellow stick, the chicks responded to the “beakier” version.

Here’s a fun essay on peak shift for aspiring artists, with this great closing statement:

In depictions of the human figure, Michelangelo’s over-the-top musculature, Renoir’s ample bottomization, and the distortions of El Greco, Giacometti and Modigliani give an idea of what’s to be had.

Much of this seems to come from the excellent BBC/PBS series How Art Made the World.

Surprisingly, there isn’t a page for this subject in wikipedia.

Moderating semantic HTML zealotry

I’ve recently the been letting go of my blind faith in page-wide semantic HTML. Today I found this old post from Jeff Croft describing the myth of content and presentation separation in HTML and CSS, which provides a realistic layman’s take on the situation: semantic HTML is too hard.

While I agree with that sentiment 100%, I’ve also been wondering why semantic markup is too hard and realized it’s because the semantic HTML paradigm is too weak to support a modern web experience.

I use Blueprint CSS on Dub and Reggae (because I use a hacked Morning After WordPress theme for the site), and it’s smashing my face into the brick wall between content and presentation.

Blueprint likes to do things like throw a date string into a div with a class of span-14. Those classes become layout macros, allowing a designer to create and edit a page design very quickly. (Jeff Croft is one of Blueprint’s progenitors.)

But those display-rules-as-classes are a bad bad bad commingling of content and markup, according to a semantic HTML purist. Like other purists, I once believed that people should lose a digit for using divs outside of defining headers, content, sidebars/navs, and footers. And spans? They’re basically an admission of semantic defeat.

Like Jeff, I found that philosophy led to 3 challenges in real life:

  1. It’s nearly impossible to build a web UI without some non-semantic markup.
  2. Purely semantic markup often requires a lot more work from the CSS, which can bloat files.
  3. As a result of the previous points and some other stuff, nearly-pure semantic markup can take a long time to build.

At a certain point, pragmatism takes over: is it worth paying someone to spend extra time building bloated CSS in the name of “future compatibility”? And if it’s so hard, does that indicate some deeper flaw in the semantic HTML model?

While pondering the wall between content and presentation, I thought about another wall: JJG’s division between app UIs and document UIs. Web UIs straddle that wall. Is it realistic to talk about “semantic” application interfaces? Does an app really have any “content” at all? Pragmatically, aren’t app UI components going to choke on forward compatibility anyway, because dimensions, JavaScript hooks, etc., tend to expect a specific context (the web browser)?

Consider the classic argument for semantic markup and forwards compatibility: the mobile device. Shouldn’t that be solved in a stylesheet’s media attribute? Or ignored altogether, as the iPhone presages full browsers one mobile devices (yay, death of WAP).

Here’s a more nuanced take on the whole “semantic HTML or die” philosophy:

  1. Keep markup purely semantic for a web UI’s document component. No divs, no spans, no class=”left”. JS probably shouldn’t touch the document interface, except for typographically-oriented functionality like increasing font sizes.
  2. Use functional markup for a web UI’s application components. Recognize that you’re building chrome from deeply intermingled HTML, CSS, and JS. Put hooks as necessary within the HTML.

Headers, navs, footers, and forms all fall within the application UI camp. Basically, anything that’s in a CMS’s app/template. From a user’s perspective, a website nav is little more than customized browser chrome, living alongside the browser’s location box and back button. With search and dynamic taxonomies exploding content hierarchies, it makes less and less sense to say a nav “should” be expressed as a list. Suckerfish dropdown menus and similar CSS wizardry are interesting because they manage to overcome the constraints presented by HTML, not because they’re elegant or appropriate.

The document UI components should only include the page text – what typically lives in the “content” div and is stored in the CMS database. When people talk about forward compatibility, this is most of what they should consider anyway – the data. This is what HTML was originally designed to represent: text, read and clicked. Keep this interface code semantic.

(Readability is a great browser plugin that hides all of a website’s application UI components, leaving only the document content – it’s a beautiful thing.)

So throw out a blind adherence to semantic markup; instead, focus on semantic document content and recognize that some HTML is actually your app/presentation layer, where it is really just a framework for links, JavaScript, and other functionality.