Some years ago we started a small web agency called Bearded. In 2010 responsive web design completely changed how we work. Ethan Marcotte's simple yet groundbreaking approach pointed the way towards a web that embraces the constantly expanding world of mobile devices, ensures content parity, and takes progressive enhancement to its next logical step.
Responsive web design directly responded to the problems many of us had already felt in web design: it had become too brittle, too precious and too pixel-specific. The web wants to be fluid, and it needed a fluid solution. And that's what we got.
Now it's 2015: about five years after RWD started being practiced commercially. We've made a whole bunch of responsive sites during that period. And you know what? It's still hard. Making the mental shift from a fixed-width world to a flexible one requires us to rethink many design patterns and user interface conventions.
Not surprisingly, the hardest parts of RWD are things that have always been kind of a pain: tables and forms. Let's have a look at why they are even more fun in a responsive environment.
The first rule of tables? Don't use tables! But seriously, let's think about this for a second. I like to think of tables as kind of a pre-standards-conscious proto-HTML. Tables, by their nature, attempt to do visual layout with HTML. Their rows and columns and endless table data cells break the cardinal rule of the post-web standards project world: the separation of style and content.
So before you start adding table tags to your markup, stop and ask yourself: is this tabular data? Tabular data derives its meaning from the comparison of similar facets of an information set. In other words, if the value in the information comes from comparing data across columns and rows. If this is the case, you may need a table.
Things that are not tables
If the data has significant value unto itself, maybe it doesn't need to be a table. Or at any rate, not always. Some other options to keep your content out of tables? Headings and paragraphs, or bulleted lists where each item begins with a bold inline heading.
Things that appear to be tables
A good example of something that may initially look like a table, but is not actually tabular data? A calendar! A calendar seems tabular because the columns share a common set of designations: Monday, Tuesday, Wednesday, and so on. It is a convenience that we can identify all the Wednesdays at once. This is why people use calendars.
However, the data you put on calendars (say a bunch of Broadway musical performances) is not intrinsically tabular. Comparing one day's shows to another's does not necessarily improve users' understanding of the performances on individual days. A calendar is one way to display date-organised data, but there are others too.
So what does a calendar look like on a small screen? We're asking the wrong question. The right question is: what does a list of events look like on a small screen?
This is how we arrived at marking up our days and events using <divs> and <articles> rather than tables on the Children's Museum of Pittsburgh website. It's much easier (and more semantically appropriate) to make a bunch of articles and divs look like a table, than to make a table look like a list.
Things that must be tables
As much as I hate to admit it, some information is tabular. When designing the fundraising event registration process for the Leukemia Lymphoma Society, we used tables for event selection. Quickly scanning and sorting this list by location and date in order to choose the particular event you want to register for seems like a good use case for tables. But how to make them responsive?
Our investigations into responsive tables started with Chris Coyier's excellent April 2011 responsive data tables roundup. For several projects in the past few years we'd consult this article and inevitably, Chris' first approach was the winner.
On wide screens, you get tables. On smaller screens, you get each entry with all of the header labels restated for context. You lose the comparative feature of tables on small screens, but you do get the essential information in an easily readable way. In other words, we treat the tabular layout as a progressive enhancement. This is our favourite UI pattern for responsive data tables, and it seems like our friends at Filament Group agree with us. In August 2013 the Filaments released Tablesaw on GitHub, which includes this pattern as one of its three options. Tablesaw is the starting point for the LLS example, and I highly recommend using it as a jumping-off point for creating your own responsive data tables.
So if Tablesaw works so well, why wouldn't you just use that all the time and forget about it? Though some major interface or display tables (like the event picker example, or maybe a SaaS pricing matrix) make sense as custom HTML, what about when a site content manager wants to toss a table onto a page using their CMS?
If site managers are entering tables in the CMS using a WYSIWYG editor, there are some issues to surmount. First of all, Tablesaw does its magic by looking at the <thead> and using what it finds there to label the information further down in the <td>s on smaller viewport widths. If the site manager isn't entering <thead> information properly, things won't work.
It's also important to note that Tablesaw only acts on tables with the right classes applied to them. You now need to decide if all tables are Tablesaw tables, or if that's an option in the CMS controlled by the site manager, then apply those rules in your CMS so it outputs the right markup.
Additionally, there are some display issues to consider. Repeating the column headers in every cell tends to add a fair bit of height to the table. It's not a very efficient way to display the data. A non-tabular approach using headings, lists and paragraphs could be an easier read on mobile, depending on the content.
This is why my first approach to tables is still 'don't use tables'. Tablesaw should be your safety net, not your go-to tool. But believe me, you'll be glad it's there when you need it.
It's likely tables have been a thorn in your side on projects before. But their persnickety nature is nothing compared to our other good high-maintenance HTML friend: forms.
Because forms are so browser and device-specific in terms of how they react to styling, they can be a real challenge to work with. To paraphrase Luke Wroblewski, forms drive one of the most essential aspects of the web: the ability to generate revenue. Yet filling out a form is the last thing anyone wants to do on a website. Thus, forms make for a fun set of design problems. Let's have a look, shall we?
When it comes to laying out forms, there are a few recurring patterns we use. For consistently short pairs of inputs, we use a pattern that we call two-up. It's pretty straightforward. No matter the size of the viewport, these inputs appear side-by-side. For inputs that need a little more space, but can be next to each other when they have enough room, we use the pattern two-up wider. There are rarely situations where three-up – three side-by-side inputs – always works. So by default, we have that work on the wider principle.
One special case for three-up is postal code, city and state. Because of the nature of these fields, custom unequal widths better serve their purpose. Their styling works on the same principals as before, but with a bit more customisation for the unequal widths we want to achieve with postal code, city and state combos.
You might have also noticed that we're starting the cluster with the postal code field. Both Luke Wroblewski and Brad Frost have shared a great approach where the postal code comes first, allowing us to autofill state and city, which is much more efficient for users.
No matter how good our forms are, sometimes users will have a tough time filling them out. This is where good validation comes into play. For input validations, we like to consider two components: messages inside the input and messages outside the input.
Inside the input
The thing to consider with messages inside the input is space. You can't, for instance, prompt a user with password requirements inside an input. But there is likely enough room for 'invalid' – and there is definitely enough room for a happy green checkmark when they get it right.
One of my favourite parts of Work & Co's Virgin America responsive redesign is how it deals with form validation. It's good at communicating a helpful validation message succinctly (e.g. 'bad email').
With responsive and small screens, brevity is important. The most brief response possible? Icons! And we designers do love our icons. The only problem is that most icons aren't universally understood. For success with a form field, that green checkmark is probably fine. But how should we indicate failure? A red 'X'? But 'X' in an interface means close or collapse. The word 'invalid' is OK, but a whole lot longer than most icons.
If the tone and personality allows it, a frowny face seems relatively clear. But many brands aren't as playful as Virgin America. In our work at Bearded we've settled on an appropriation of the 'do not enter' sign. Its similarity to iOS's 'remove item' icon isn't ideal, but it's the best solution we've come up with so far.
One thing about responsive design and progressive enhancement, though: we can implement an icon where space is at a premium, and expand to an inline validation message like 'invalid' or 'bad email' when we can afford the extra width.
Outside the input
When we need to display feedback to a user beyond what we can cram inside an input (or when elements like selects are involved), it's time to start using messages outside the input.
In those circumstances, you can use both kinds of validation. For example, you can add an inline 'invalid' message, then below the input tell users the longer story. In this space, you even have the luxury of providing links to enable users to perform alternative actions (e.g. 'Sorry this email address is already used with an account. Try signing in').
Regardless of your approach, form interactions are a subtle art. I would encourage you to run usability testing on your prototypes as you go. Spending a week trying things out with five users can give you a wealth of information about how things are (or are not) working, before you go live.
One of our favourite input use cases? Date selection. Why? Because it's so hard to do well! Let's say users need to select a date to make an appointment in the near future. Some things to consider:
- Users must be able to input the date in a format the database on the other side will be happy with
- Users need to know which day of the week a date is as they consider their schedule
Sounds like a calendar picker is the way to go. But calendars on small viewport are the worst, right? Luckily pickadate.js does a good job of handling this problem. With a few UI customisations, your calendar picker is good to go.
That's great for near-future date selection. But what about selections in the distant past – for instance, birth date? You'd have to click your way back decades using the previous month button. How odious!
Thankfully, for this sort of interaction day of the week is irrelevant, so the only real challenge is formatting. So what to do? You could try to explain to users what to do using hint text. Except that, well, no one reads hint text.
OK, so we can force formatting choices with three select inputs – one each for month, day and year. That day select input with its 31 options is no picnic – but it's a dream compared to the year select going back to 1915.
Fear not, for natural date entry is a problem that's been solved. Date.js allows users to enter dates however they want. Slashes, dots, or hyphens; abbreviated or spelled out. What's more, it confirms the output with you using a handy validation message, and tells you day of the week, for kicks.
So ... dates? Feels good man. But let's roll back to selects for a second.
Even for form inputs, selects are kind of a bugbear. Styling those son of a guns consistently across browsers is nigh on impossible. Chris Coyier has put together a great write-up of the common pitfalls and limitations. At Bearded, our standard approach to selects is to match up their height to other inputs, but otherwise pretty much leave them alone.
It's worth noting that the Filament Group has made a heroic attempt at cross-browser select styling, available on GitHub. However, although I love the idea of gaining styling control over these little troublemakers, my personal feeling is that this kind of approach is a bit on the brittle side.
The worst situation for selects? When they get long! The fine folks at Harvest were nice enough to release some of their custom select approaches to help you with this, in the form of jQuery plugin Chosen. One of these approaches provides a searchable select that helps users reduce the number of options in front of them. And thanks to Nathaniel Flick, they've been responsivised.
Chosen has some super-fun features, but it can, like any select-replacement approach, lead you down some rabbit holes. Be careful not to make things more complicated than you have to.
Recently we worked on a project for a healthcare provider in which users needed to select from complex groupings of information. There was a list of doctors, their names, the doctor's area of specialisation, their office location, and the date they last saw the patient.
Complex information like this will not fit into a standard select element, so we tried something else. The solution we came up with is something we called the prioritised selector. In it, we show the user the first few options, prioritised by some specific criteria (most recently visited, for example), as well as the option to view more.
When a user selects the 'view more' option, we open a full-screen modal interface that lets the user select from the full list. Though it adds an extra click when a user needs to access doctors they haven't seen in a while, this ultimately seemed like the best approach for the use cases we were accounting for.
Let's face it: these things are messy
Tables and forms are complex by nature. No matter how much we work on them, they might never be easy. And as the environment we deploy them into grows ever more complex, so will the design problems they represent.
But isn't that the fun of web design? As we solve the problems that are there to be solved (and thus the threat of boredom and complacency rears its ugly head), the web always seems ready to mix it up again, keeping us on our toes. And thank goodness for that.
Matt Griffin is a founder at Bearded. Patrick Fulton is a developer, also at Bearded. This article was originally published in issue 272 of net magazine.
Liked this? Read these!