Adaptive Vs. Responsive Layouts And Optimal Form Field Labels

Advertisement

Editor’s note: Welcome to a new column in the UX Design section on Smashing Magazine! Each month we’ll pick a handful of popular questions asked by our readers around good practices in designing smart and usable experiences. They will be answered by Christian Holst, a regular author here on Smashing and founder of Baymard Institute. Prior to co-founding Baymard Institute in 2009, he worked as a usability engineer in the hearing aid, credit card and consulting industries.

Adaptive Layout Vs. Responsive Layout

“In which kinds of sites/projects is it better to use an adaptive layout (fixed break points)? In which kinds of sites is it better to use a responsive layout (fluid grids)?”

A responsive layout[1] is in theory always better than an adaptive layout, but in some cases an adaptive layout is a more pragmatic solution.

An adaptive layout will give you more control over the design because you only have a handful of states to consider. In a responsive layout you easily have hundreds of states — sure, most of them with very minor differences, but they are different nonetheless — which makes it harder to know exactly how your design will look. This makes a responsive layout more difficult to test and predict with absolute certainty. That said, this is also the beauty of a responsive layout. By allowing some uncertainty on a superficial level, you gain certainty on more fundamental levels. Sure, you can’t predict with pixel-perfection how the design will work in a 943 × 684 pixel viewport, but you can rest assured that it works well — that the fundamental features and layout structures are meaningfully deployed.

An adaptive layout has its merits because it can be a more pragmatic solution that is cheaper to implement and easier to test. An adaptive layout can be considered the cheaper sibling of a responsive layout and can thus be appealing if resources are tight. This is especially true when dealing with an existing website, where a complete rewrite is not always feasible. In such cases, an adaptive layout can be a good (and more manageable) start. Dan Cederholm argues this case well in his article “Adapted”.

Responsive Layout
Image source: Trent Walton.

One argument often brought up in favor of an adaptive layout when compared to a responsive layout is that of typography — in particular better control over line lengths and avoiding orphaned header text. Trent Walton has jotted down some good thoughts on the matter. In essence, by changing font sizes (this is easy when using em), you can ensure readable line lengths (50-75 characters per line) in your responsive layout. This leaves the issue of potentially orphaning header text. While one may argue that this is the nature of the web, there are cases where seeking maximum control over a page headline makes sense. In these cases, using a plugin like FitText comes to our rescue, allowing us to avoid orphans.

[1] The definitions of responsive design and adaptive design are manyfold. Jeffrey Zeldman argues that restricting the term responsive design to a technological approach may prove too limiting and that the overall goal is device agnosticism, and we should thus include fixed breakpoint designs in our definition of responsive (web) design. Moreover, Aaron Gustafson defines adaptive design as “creating interfaces that adapt to the user’s capabilities (in terms of both form and function)” with responsive design as a subset meaning “fluid grids, fluid images/media & media queries.” In this answer I’ve intentionally limited the scope of discussion to layout, hence the use of responsive layout and adaptive layout. The definitions presented in the question are used throughout the answer, namely that responsive layout equals fluid grids, and adaptive layout equals fixed breakpoints.

User Interface (UI) Consistency Across Devices Vs. Device-Specific UI Conventions

“In designing a product that will span various devices (i.e. Netflix or Pandora), what’s more important: consistency of the brand and UI, or designing to appropriately follow the guidelines of that specific device (i.e. designing a common experience on the iPhone, Android, television, Xbox)?”

There are three important factors you need to consider: your focus (as a business), how familiar your users are with your UI, and how different your UI and functionality are on different platforms.

  1. Focus: There may be branding reasons to keep a consistent UI across your platforms, perhaps especially for lesser-known brands that are still fighting to establish an identity in the minds of their customers. However, users are typically more familiar with the device-specific UI conventions than those of a brand. Jakob Nielsen often states, “Users spend most of their time on other sites,” and while we’re not just talking about websites here, it is much the same principle (on a smartphone, simply replace “sites” with “apps”).
  2. Familiarity: Are most of your users spending hours a day using your service? Have they used it for a long time? Or are the majority of your users infrequent or newly acquired? Let’s say you have a business or productivity service and you know the majority of your users spend lots of time in it all year long. In this case, familiarity across the applications trumps device UI conventions, because the user has invested a significant amount of time learning your unique UI. On the other hand, if users haven’t spend that much time with your services and haven’t built strong cognitive and emotional ties to your designs and features, then device-specific UI conventions will generally result in better usability.
  3. Functionality: This has two aspects: a) Is your service only solving a single problem with a single feature, or is it more advanced? and b) Is there a difference in functionality and features across the various devices? If the features you offer on different platforms vary greatly, then adhere to device UI conventions, since cross-platform consistency will yield little benefit in terms of usability (using the same branding and general aesthetic design won’t help the user if the features are widely different — in fact, they could potentially cause harm as the user will think there’s overlap when in fact there isn’t). On the other hand, if you’re solving a single, simple problem, then diverging from device UI conventions is okay since users will very quickly learn your unique UI and you’ll potentially be able to solve the UI problems specific to your feature more readily than the generic device conventions afford.

In short: sticking to device-specific UI conventions where appropriate is a good, if slightly simplistic, rule of thumb.

Balancing Usability Research With Unique And Creative Concepts

“How should I balance research, user feedback and usability testing with personal experience, instinct and trying to create a creative, unique, compelling experience? Basically, how much should users influence or guide the solution I am designing? It is “user” experience after all.”

The concept of your product, service, app or website is at the core of your user experience. It’s where you differentiate yourself from the competition and where you create true value to the customer. So develop your concept as creatively as possible and make it as original as possible. Then, when it comes to the real-life implementation, read up on user research, study UI conventions and perform usability testing as much as your concept allows.

Usability research and testing are what make your services easier and more seamless to use (which are truly important qualities in a competitive landscape), but they are not the reason people choose to use a service in the first place — they do that to solve a problem or fulfill a need. So first come up with that ingenious new concept, and then draw heavily on user research when implementing the service.

Usability tools are there to test and validate your designs, allowing you to continuously iterate your design based on user behavior and perceptions — an optimization process that should continue throughout the product’s life cycle.

Optimal Positioning Of Form Field Labels

“What’s the best way to position form labels for an input field? Above the field, to the left, to the right? What about inline labels?”

In short: for most input forms found on the web, such as contact forms, account creation and e-commerce, optimal form usability would be to place the label above the form field. Matteo Penzo’s eye tracking test on form label placement from 2006 confirms this.

On mobile devices the placing the label above the form field will ensure maximum width for the user input.
On mobile devices, placing the label above the form field will ensure maximum width for the user input. To the left you see Macy’s mobile checkout, where placing the label next to the form field results in a field so narrow the test subject couldn’t see the typo in his e-mail address. To the right you see an example of the recommended approach with the label above the form field.

Placing the label above the field is even more important if the form will also be accessed on mobile devices in portrait mode, due to the narrow screen. The user might otherwise have to deal with form fields that aren’t long enough to display the entire input, or end up doing a lot of sideways scrolling and panning between label and field. However, the exact opposite may be true of landscape mode, where the miniscule height of the viewport may be eaten up by the touch keyboard, potentially pushing the active field’s label out of sight.

An exception to placing the label above the field is for long forms that have very frequent and repeat usage, where the user needs to be able to quickly identify a few specific fields in a long list. In such cases, having the labels to the left of the form field makes it easier to scan. The same would go for a pre-filled form where the user needs to edit only a specific set of fields (e.g. when editing account profile information).

An example of inline labels, where the label acts as placeholder text in the form field.
An example of inline labels, where the label acts as placeholder text in the form field.

Inline labels, where the label is placed inside the form field as placeholder text, are horrible from a usability perspective. During our e-commerce checkout usability study, we saw numerous test subjects have serious issues with inline labels in Apple’s checkout process. While the approach makes for a simple visual appearance, the form is very difficult to interact with because each field loses its context the second the user starts typing. In the study, this not only made it more difficult for the subjects to fill out the form fields, it also made it very difficult for them to correct validation errors since the labels were missing.

Note that the importance of optimal positioning of the form field labels (and form field usability in general) are of course closely related to how many form fields the user has to fill in, and how often the user will need to complete the form. If it’s a single-field, single-use newsletter sign-up form, then choose whichever approach and design fits best with your overall layout. (Even inline labels would be acceptable in such a case.) But as soon as you have more than a handful of fields — e.g. a checkout process or a sign-up form that requires an address — I’d strongly recommend that you reduce friction as much as possible by following common form field usability guidelines, such as positioning the labels above the form field.

Any Questions?

If you have any questions that you would like me to tackle for a future Usability Q&A column here on Smashing Magazine, please ask them in the comments below!

(cp) (jc)

↑ Back to top

Christian Holst is co-founder of Baymard Institute where he writes bi-weekly articles on web usability and e-commerce optimization. He's also the author of the E-Commerce Checkout Usability and M-Commerce Usability research reports.

  1. 1

    Why are you positioning adaptive and responsive as choices rather than factors of an ideal layout solution? Having a responsive layout and element level adaptive interfaces (interactions, features etc…) seems to address all of the context concerns above.

    23
    • 2

      I think for the most part what you describe is just “responsive” design – the layout changes with every pixel added or subtracted from the width but certain elements only switch on preset breakpoints. Adaptive design as it was initially coined means just a set number of fixed layouts (and elements) to switch between.

      To me the best approach is to be “responsive” for below 768px and have two or three steps of fixed “adaptive” layout when you go above that.

      7
      • 3

        Interesting, maybe a combination of responsive and adaptive is required. As above, we have a the base which is adaptive and then below a certain width it becomes responsive and maybe above a certain width it becomes responsive.

        4
        • 4

          Jonathan,

          Going “responsive” (as in fluid layout) above certain width is not a great idea for most sites. Paragraphs of text get hard to read above certain line length.

          There’s a type of content though for which it’s always good to have more horizontal space and to be able to use it. Grids of images or products work great as responsive layouts from small smartphone screens to the largest desktop displays. You just switch the number of columns at the breakpoints and let the grid fill up all the available horizontal space.

          4
          • 5

            I can’t agree with this more. In websites that are particularly image intensive (think e-commerce) break points above 768px is advantageous as I can structure the site in different ways to display my images and information in specific ways instead of just elements sliding around everywhere and getting really huge on 27″ displays. Once you go down to phablet/phone size you want everything to be nice and readable so everything becomes elastic and scrolls vertically.

            The e-commerce site I’m redesigning gets millions of page views every month so the way everything is displayed on different devices is crucial and a small difference can equate into huge revenue gains or losses at that scale.

            0
      • 6

        For the most part, I agree. I don’t quite understand why people are so offended by the idea of them being presented as choices – as if to imply one solution (the one they prefer) be hawked as the only good approach.

        5
      • 7

        Ivelin, why should you be responsive below 768px and have fixed adaptive breakpoints above that? That approach is completely wrong in my humble opinion.

        First of all, why be responsive below 768px and not 800px ? Just because there’s the ipad with that resolution doesn’t mean you should set it as a breakpoint. You should set your breakpoints based on how your content flows in the page. What if you set your breakpoint at 768px and your content starts looking awful and you can’t read properly starting from 700px or 600px?

        If you chose your breakpoints based on current devices, what will you do with the tone of websites you develop when the next ultimate device comes out? You may say add another breakpoint to each of them, charge clients for the extra work. But sooner or later you will lose them because your quality is bad and you should feel bad … Given the fact that the competition keeps on rising, I think it’s way better offering more expensive services for higher quality. Sooner or later everyone will be able to make a website, if they can’t do it yet, but every fool will be able to spot a difference between a professionally made website and a nephew-made type of website.

        Further more, why not use responsive, fluid grids in the design and have 4 or 5 breakpoints that don’t let content get out of hand. Say you have breakpoints at 350, 600, 900, 1200 and above 1400 and your content is resized based on % and ems no matter the resolution.

        Browsing on an iphone, fine, that the 350 responsive layout is used. Iphone in landscape? great the 600 one is used and scaled by the browser. Using some android with God knows what resolution close to 350, 400, 500? The appropriate layout is selected automatically by the browser.

        11
    • 8

      Honestly, the reality of the community is that most people launching sites are doing so without any adaptive or responsive nature and so the conversation is still a bit focused to devs/designers. I know with Skematik – http://www.skematiktheme.com – we’ve tried to encourage people to roll with native Bootstrap styles and build atop of those. Definitely agree though with Petar.

      0
    • 9

      Petar’s comment was such a comforting vindication of my confused feeling after finishing the article. I suppose there isn’t really a standard specific definition for either term, although many have either made personal competing philosophies regarding the two (which I thought we were a bit done with at this point), and then there is general consensus that they are different elements or ways to describe the front-end development process that most use today.
      I think I’m correct in saying most of us use fluid grids WITH breakpoints, some device specific code, polyfills, and progressive enhancement, responsive images and font-sizes etc, and adaptive elements like a navigation that changes functionality for smaller touch screens..(among other things) and since the ‘responsive/adaptive’ terms aren’t always the philosophy but used as ‘buzzwords’, I vote we start using them only when necessary, most of what’s been said on many blogs and magazines is just messy interpretation, less clear than the original A List Apart article, or Ethan Marcotte’s blog.
      So let’s call it…Web Development and stop beating a dead horse.

      4
  2. 10

    You just put words to what I’ve been thinking. Great post.

    1
  3. 11

    Michael Meininger

    November 8, 2012 2:17 pm

    Hey Christian,

    Good article. What are your thoughts on a stand-alone mobile website with “browser sniffer” technology in place?

    0
  4. 12

    You mentioned in your article that you should include the labels above the fields, but correctly identified a problem use-case where the user may be browsing in landscape-mobile and will have the label pushed out the top of the screen when they start their input.

    I wonder what your thoughts are for solving this problem? It seems like having the labels on the left for landscape-mobile would be problematic because of the eye-tracking benefits you get from above-field labels. Is this a lose-lose scenario where there’s just no good way to do it?

    3
    • 13

      Christian, Baymard Institute

      November 9, 2012 1:48 am

      Hi Nick,

      Great question. We’re currently finalizing a large scale usability study specifically on m-commerce, without the dataset being analyzed to the full yet, everything points in the direction that you (ideally) should change the label position from above the field to the left when the user switch to landscape mode, as the label’s otherwise get pushed complete out of the viewport (on the majority of devices) by the touch keyboard and field itself. This however have a range of implications, besides the technical integration it limits the length of the labels greatly, and any additional descriptions and tooltips appended to the label will need to be re-positioned as well. When we have something more conclusive we’ll be sure to share an in-depth explanation of this from the usability study findings.

      2
      • 14

        Nick has mentioned an appropriate issue. In my opinion,in this loose-loose scenario we need to “Not Bad” among the Bad solutions.

        In mobile landscape view, I believe label is most suitable on left side. Eye-tracking is not a big issue due to smaller width of the device and label remain in context with the respective form field.

        In mobile portrait view, (I am not sure but) label below the form field can also be tried as label get hidden as soon as we touch form field but some of the area below stays visible. An arrow in along with the label may also be used to indicate that label belongs to the field above. Just my 2 cents.

        0
  5. 15

    Great says! Nice article please continue at the same way

    -2
  6. 16

    I just discovered the word Adaptive, and I like it a lot more than Responsive.
    To me, Responsive means “in response to a user action”.

    But in the case of design layout, a user is not really taking an action to resize the browser window, they are using a device which has an optimal window size, and the website is Adapting it’s layout to fit within the constraints of the device’s window / viewport.

    I’m going to start using “Adaptive” as my choice word, and get into serious arguments with anyone using the word “Responsive”.

    2
    • 17

      I’ve seen many definitions of what responsive and adaptive are, and yet never the same definition twice – not uncommon as new areas evolve (definition of ux anyone..?!)

      <>

      Have you considered a broader interpretation of responsive as “in response to a user’s context”?

      I find this one puts me in a more helpful, open mindset – responding only to ‘actions’ could limit the solutions explored.

      0
  7. 18

    I enjoyed reading this article a lot.

    To be honest, I’m not such a fan of the terms adaptive and responsive for describing fixed width and fluid width layouts.
    Why don’t we just settle on “responsive with fixed OR fluid layout” ?
    Adaptive is in my opinion what encompasses far more things (like performance, content or gesture support )

    About the form fields: I’m glad to see that a big player like Apple still has room for improvement in terms of usability.
    Personally I wouldn’t abandon this cart though because it’s kind of trivial, however on a phone I might get seriously annoyed.

    3
  8. 19

    Excellent article.

    Looking at this on my phone, looks like the tags at the top of the page fax the adaptive/responsive layout, though. Nice to know even the pros can slip up.

    -2
  9. 20

    I think your article is redundant and has the wrong message.
    Adaptive and Responsive Web Design are the same thing using different mixes.
    Here maybe brush up on your termininology instead of creating new ones
    http://en.wikipedia.org/wiki/Responsive_web_design
    “A site designed with RWD[1][4] uses CSS3 media queries,[3][5][6] an extension of the @media rule,[7] to adapt the layout to the viewing environment—along with fluid proportion-based grids[8] and flexible images:”

    I started to read this article and got confused. This article should be more about “Fixed Pixels versus Percentage Based Pixels”

    Not an impressive article

    10
  10. 21

    Coincidentally Ben Hagon of Hagon Design (Canada) just sent out this little infographic on the importance of Responsive Site Design.
    http://responsivedesign.hagondesign.com/

    2
    • 22

      Oddly, their site is using JS to handle the resizing instead of @media. Still, the content is valuable. Thanks!

      0
    • 23

      Wow, that infographic is nice, and has some good advice, but their website has some terrible UX, what the hell is going on with that scroller at the top of the page?!

      0
  11. 24

    How can you solve problem with those tiny devices with HD screen (720p or 1080p)? Likely they will become trend in 2013, is responsive design will work as intended on those devices?

    0
    • 25

      Because those devices have two pixel definitions. One is the “actual” pixels on the device screen and the other is the “display” pixels. So on many of those devices 4 actual pixels equals one display pixel.

      0
  12. 26

    My idea is not necessarely related to this subject. I just saw this ‘repeat e-mail address’ on a mobile screen and thought: “Why don’t we make it easier? We should prompt the user when he submits the form ‘Is your e-mail correct?”
    No? PreventDefault, Focus on e-mail field.
    Yes? Let go..

    0
  13. 27

    Nowhere in this article is there a discussion point around minor breakpoints. These will allow to bridge the gap between a responsive and adaptive layout. You can define your 3 resolutions you’re building for with Media Queries and inside each stylesheet, create minor breakpoints to cater for small visual discrepancies in a certain viewport range.

    No, it won’t be 100% fluid as we’re not setting our content containers with percentages, but it will be responding to specified resolutions and adapting the design appropriately.

    Yes, there’ll be more design considerations but the one thing common around these two options is iterative design and development so the project cycle will always be design –> develop –> test –> design –> develop –> test etc….

    0
  14. 28

    I like to think of Responsive Design as a strategy that can be used *within* Adaptive Design. That is, I use my middle tier to detect mobile, and redirect to m.site.com for all mobile, but tablet and desktop users share an experience. Then, using @media, fluid containers, scaling images, and minor breakpoints, I can serve multiple layouts within each site (desktop and mobile) to maximize the screen real estate.

    On a side note, perhaps one distinction between Responsive and Adaptive could be the difference between @media max-width and max-device-width. The former allows you to experience the Responsiveness in real-time on any device where you can change the viewport size (desktop browser), where the latter won’t take affect unless you’re viewing the site on a device that reports a max width that matches your media query (less responsive, more adaptive).

    0
  15. 29

    Animation in a particular view is a part of the design that is not seem to be addressed well in responsive design. The “pop” of artwork flying into view, or the humor of a little cheseburger flying around the perimiter of a big screen would get lost on a smartphone, yet is feasable on a 200+ dpi tablet. The breakpoints between smartphones, tablets and big screens is clear, and fluid designs is best. I tend to vote with folks like Jakob Nielsen that mobile sites should be completely different to be effective, and am impressed by the amazing thoughts of artisans here. I am working for an artist till the end of the year who wants the best of the best, owns an iPad II, and wants animation of all sorts. It might be Adobe Edge (CS6 stuff) or deep into SVG, not sure yet.

    0
  16. 30

    Great Article. Forwarded!!!
    Friends,I Found A Great Mockup For Responsive Layouts
    Here Is The Responsive Layout Mockups Links
    http://graphicriver.net/item/25-ultimate-web-responsive-mockup-pack/3102112?ref=graphicon

    -5
  17. 31

    Thanks for tackling the topic of label placement in forms.

    I’m delighted to see that you come out strongly against the horrible, horrible idea of using placeholder text as labels inside the boxes. I’ve always found that this creates all sorts of problems for users – not at all surprised that you have seen the same in your tests.

    I’m disappointed that you quote Matteo Penzo’s 2006 study on label placement. It was a useful study in 2006! But that’s 6 years ago, and there has been plenty of other work since then that has pointed out many limitations of the study. For example, I quoted more recent research in my 2010 article: http://www.uxmatters.com/mt/archives/2010/10/label-placement-in-austrian-forms-with-some-lessons-for-english-forms.php

    1
    • 32

      Interesting. I am 2 participants into a 5 person mobile user testing study. The website I’m testing uses html5 style placeholders with no labels and participants have been fine so far.

      0
  18. 33

    With regards to the placement of field labels, I would also just add that one major downside of “above” placement is that it doubles the vertical length of your form. For forms with a lot of content, this can make “beside” placement a much better choice.

    There are other considerations too, like translation into different languages etc, all of which I covered in my article on alignment here: http://formulate.com.au/articles/alignment/

    Cheers,
    Jessica

    1
    • 34

      Christian, Baymard Institute

      November 26, 2012 1:51 am

      Hi Jessica,

      There are certainly other use cases (paper forms, response forms, very long forms, repeat usage forms, etc.) where above alignment aren’t optimal – all which you cover very well in the article you link to. Thanks for bringing it up. But most web forms, especially e-commerce, a one or two word label isn’t enough. You also need field descriptions, and input formatting examples: http://baymard.com/blog/checkout-form-field-descriptions neither will fit very well to the left of the field. Furthermore, the left alignment require the labels to be short and roughly the same length – figure 10 and 11 in your articles showcase this dilemma well – both often leading to oversimplified labels.

      0
  19. 35

    I’ll be honest I am astonished that what I had always practiced, and cited as “responsive design” is actually “adaptive design”, which is a name I like a lot more, mainly because it is more lexical, with tid-bits of responsive thrown in.

    The article does make me worry however that somewhere out there someone actually has a website that looks the same and responds (which would mean one layout right?) for everything up to a HD screen (obviously mobile-first is a growing movement…). But is it not somehow more correct to use states.

    Anything else is surely a failure to recognize that a mobile device will often be running on a battery, within a bandwidth requirement, a processing and memory requirement. How many of us have actually got a low-end smart-phone as well as the latest shiny apple iFruit?

    To be fair I also think that the definition of “responsive design” that you give is drilling right down into the issue and being a bit pedantic, but I am quite pedantic, so I can forgive…

    The strange thing for me with many of the often polarized debates on “the correct way to design” (which in fairness is not what you are advocating, as far as I have understood), is that yes, everyone does have their own take, but there are already rules and guidelines in graphic design to govern this. A particular pet peeve is people having columns without justified text… Anyway

    Thanks for a good read and inspiring a good think about responsive!

    0
  20. 36

    Reg. placement of form field labels – positioning on top of the fields…it sometimes gets confusing if a field label is meant for the field below it or above it especially when there a long vertical list of fields in the form with less vertical spacing between the fields

    0
  21. 37

    I have a question regarding not just the placement of form fields, but of the form itself. Have there been any tests done with responsive design regarding this? Is a responsive form always at the bottom of the page and does that convert as well as desktop, or is there a form on desktop/tablet, and a button on smartphones with a call to action to go to another page to fill out the form?

    Thanks!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top