Designing for Easy Interaction

by Sarah Horton, Whitney Quesenbery

16 Reader Comments

Back to the Article
  1. Nice article/excerpt!  I’m putting together a pattern library now in which the code snippets and templates are just as much a part as the interaction patterns.  Even if you’re the sole developer on a project you think differently on different days, so having your starting code snippets set up to work with WAI-ARIA, for example, would be critical.

    Question: I find hover to be a very useful interaction for affordances and for providing non-critical info.  It can make some things that aren’t at the top of the visual hierarchy more discoverable without painting them in a giant <blink> tag, so to speak.  While I see that it has problems on touch screens, I don’t feel like there has been a useful analog that we could switch to.  What other patterns can fill its place in touch and assistive technology?

    Copy & paste the code below to embed this comment.
  2. It’s worth noting that enclosing the label‘s related input is also perfectly valid (as HTML is not XML).

    &lt;label&gt;&lt;First name:&lt;input type="text" /&gt;&lt;/label&gt; &lt;label&gt;&lt;Last name:&lt;input type="text" /&gt;&lt;/label&gt;

    HTML5 Spec – label element

    Copy & paste the code below to embed this comment.
  3. The enclosure method mentioned by Daniel actually provides additional benefits to users of Braille keyboards. Not knowing the technical term, there is a little blinking dot (below?) the right-most character which is used to indicate that there is additional content in a region. Separating the label and input field subverts this behavior (or at least it used to), hiding the fact that there is additional content available as a form field to interact with.

    Copy & paste the code below to embed this comment.
  4. First, what’s up with A List Apart signup/login? Seems to ignore some of the guidelines of this article and do some other weird things as well.
    Second, what I actually signed in to ask: what about the “for” attribute with alerts, e.g. <span role=“alert” for=“username”>Username is unavailable</span>? Is the for attribute valid and useful in span tags? Or if enclosing the field in the label, should the alert also be enclosed?

    Copy & paste the code below to embed this comment.
  5. Nice article.. really helpful. In addition to all above points, I think following html semantics will always help for easy interaction.

    Copy & paste the code below to embed this comment.
  6. Very Informative thanks a lot for sharing it.

    Copy & paste the code below to embed this comment.
  7. Man the amount of useful UX best practice packed in to this excerpt is impressive. Looking forward to reading the entire book.

    Copy & paste the code below to embed this comment.
  8. @KiplingInscore

    Is the for attribute valid and useful in span tags?

    No it only works on the label and output elements.

    Copy & paste the code below to embed this comment.
  9. Best practice of web designing is to design UX compatible website that gives better user experience.
    http://www.codefire.org/

    Copy & paste the code below to embed this comment.
  10. Just picked up the book and looking forward to the read.

    @Virender

    I’m guessing your comment is spam but if it is not you should reread the article (I’d suggest picking up the book).  The whole point is to design proper UX by including people with disabilities.  http://www.codefire.org is littered with UX that does not include people with disabilities.  The carousel, dialogs, main navigation, etc. could use a little TLC.

    Copy & paste the code below to embed this comment.
  11. @Daniel Imms

    It is valid, but I usually stick to keeping them separate.  If you ever need to target the label text by providing it as a label for something else with let’s say aria-label, this would not be possible as the text AND input might be read:

    <label id=“id”>Label Text<input /></label>
    <input aria-label=“id” />

    You could wrap the label text in an element with an ID, but then why not separate the two and not have to worry?  Whatever works for you, but separating the two always keeps me out of trouble.

    Copy & paste the code below to embed this comment.
  12. @webhipster

    This won’t work:
    <label id=“id”>Label Text<input /></label>
    <input aria-label=“id” />

    If you do that the label for the input will be the string “id” as the aria-label attribute value is a string rather than a reference.  I think you probably meant:

    <label id=“id”>Label Text<input /></label>
    <input aria-labelledby=“id” />

    The other way to go would be to skip ARIA in this situation as there is an added benefit for users when you use the for attribute properly, as follows:

    <label for=“id”>Label Text<input /></label>
    <input id=“id” />

    When the for and id attributes are used then a mouse user can click on the label text and focus is placed on the input.  This is useful for users with limited mobility and is also a nice and easy test for QA testing to ensure that the label is properly associated with the control.

    Copy & paste the code below to embed this comment.
  13. An accessible website is usually a simple website.  Something that bothers me about some new trends on the web is how complicated and confusing they can be.  One example is some giant single-page websites wherein you have to click some nearly invisible arrow to go to another part of the giant page or using scroll to activate an animation. It is nice for getting people’s attention, but it’s just too complicated and interrupts the flow of how users browse the web.

    This excerpt was really useful and I think I will have to buy the entire book.

    Copy & paste the code below to embed this comment.
  14. @Andrew Kirkpatrick

    Oops, yes, exactly what I meant!  It was just a quick example for why I prefer separate labels and inputs ;)

    Copy & paste the code below to embed this comment.
  15. @Scott McDaniel

    Personally, I’m not a big fan of hover events. I’ve watched too many people trying to use the mouse to point to something on the screen, and getting frustrated because some hover element displays right on top of whatever it is they are trying to show me. Sometimes hovers are helpful but often they are a nuisance. My thinking is, if you have something important to say, say it right on the page where everyone can see or hear it. I also try to stick with “click to activate” controls. For dropdown menus I always argue for activating menus on click. But to be honest, I usually lose. :)

    My colleague, Patrick Lauke, tells me one approach people are exploring is to turn the event into a two-step click. While that sounds like a fun dance step, it might not really be that fun. It changes the interaction pattern of click to activate control into click to activate hover, click to activate control. Since hover is often used for supplementary content, this approach makes the content part of the interaction, whether you want to consume it or not. Also, any time you mess with interaction conventions it’s going to cause confusion. (Patrick has some slides with embedded demos: Getting Touchy: an introduction to touch and pointer events—check out slides 15-18 and 84-97.)

    I agree with you that there isn’t a good analog that doesn’t require touch and AT to consume content that is intended to be supplementary. It may be we all start doing the two-step click, but my inclination would be to go with the mobile first approach, which I think of as, if it’s not critical, don’t include it. And whatever is left, display it on the page. But I’ve always been a less is more kinda designer, and I know this approach doesn’t always fly with clients and users.

    Thanks for raising the question, Scott! This is just the type of discussion we need to have for accessible user experience. Let’s keep it going, using #aux on twitter.

    Copy & paste the code below to embed this comment.
  16. Just a note to say that I’ve tried many times to find the fewest words to make the following point, with which you’ve started the chapter: “Success in interaction design is largely a matter of following established patterns.” Now I know how to say it!

    Copy & paste the code below to embed this comment.