{"id":4760,"date":"2017-03-07T12:24:14","date_gmt":"2017-03-07T19:24:14","guid":{"rendered":"http:\/\/www.taterboy.com\/blog\/2017\/03\/create-responsive-forms-and-tables\/"},"modified":"2017-03-07T12:24:14","modified_gmt":"2017-03-07T19:24:14","slug":"create-responsive-forms-and-tables","status":"publish","type":"post","link":"https:\/\/www.taterboy.com\/blog\/2017\/03\/create-responsive-forms-and-tables\/","title":{"rendered":"Create responsive forms and tables"},"content":{"rendered":"

A proof-of-concept molecular modeling study that analyzes the efficiency of amine solutions in capturing carbon dioxide is the first step toward the design of cheaper, mind<\/a> more efficient amine chemicals for capturing carbon dioxide — and reducing harmful CO2 emissions — in industrial installations.<\/p>\n

<\/p>\n

Don’t miss the Bearded team at<\/em> Generate New York<\/em><\/a> on 27 and 28 April. Not only will they run a workshop on ‘responsive web design for non-unicorns’, more about<\/a> founder Matt Griffin will also talk about what it means to be a web designer in 2017 and show additional footage that didn’t make it into his documentary, rx<\/a> What Comes Next Is The Future.<\/em><\/p>\n

Get your ticket this Thursday 9 March, sick<\/a> in our 24-hour flash sale and save 50%!<\/strong><\/em><\/a><\/p>\n

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.<\/p>\n

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.<\/p>\n

We’ve made a whole bunch of responsive sites since 201. 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.<\/p>\n

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.<\/p>\n

Tables<\/h3>\n

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.<\/p>\n

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.<\/p>\n

Things that are not tables<\/h3>\n

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.<\/p>\n

<\/p>\n

\n

<\/p>

The Bearded team will give a workshop on how to improve team collaboration on responsive design projects at Generate New York<\/figcaption><\/figure>\n

<\/a><\/p>\n

Things that appear to be tables<\/h3>\n

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.<\/p>\n

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.<\/p>\n

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?<\/p>\n

\n

\"This<\/p>

This complex select UI allows users quick access to prioritised options (left), with modal access to additional options (right)<\/figcaption><\/figure>\n

This is how we arrived at marking up our days and events using <\/strong> and <\/strong> rather than tables on the Children’s Museum of Pittsburgh<\/a> 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.<\/p>\n

Things that must be tables<\/h3>\n

As much as I hate to admit it, some information is tabular. When designing the fundraising event registration process for the Leukemia Lymphoma Society<\/a>, 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?<\/p>\n

\n

\"For<\/p>

For our work on the Leukemia Lymphoma Society websites, we tried a number of approaches for form validation<\/figcaption><\/figure>\n

Our investigations into responsive tables started with Chris Coyier’s excellent April 2011 responsive data tables roundup<\/a>. For several projects in the past few years we’d consult this article and inevitably, Coyier’s first approach<\/a> was the winner.<\/p>\n

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.\u00a0<\/p>\n

Tablesaw<\/strong><\/p>\n

In August 2013 the Filaments released Tablesaw<\/a> 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.<\/p>\n

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<\/a>) make sense as custom HTML, what about when a site content manager wants to toss a table onto a page using their CMS?<\/p>\n

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 <\/p>\n<\/strong> and using what it finds there to label the information further down in the <\/p>\n<\/strong>s on smaller viewport widths. If the site manager isn’t entering <\/p>\n<\/strong> information properly, things won’t work.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Next page: discover how to master user-friendly forms…<\/strong><\/p>\n

Forms<\/h3>\n

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.<\/p>\n

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?<\/p>\n

Layout<\/h3>\n

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.\u00a0<\/p>\n

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 \u2013 three side-by-side inputs \u2013 always works. So by default, we have that work on the wider principle.<\/p>\n

\n

\"At<\/p>

At Bearded, we use certain responsive layout patterns over and over again for form inputs<\/figcaption><\/figure>\n

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.<\/p>\n

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<\/a> where the postal code comes first, allowing us to autofill state and city, which is much more efficient for users.<\/p>\n

Validation<\/h3>\n

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.<\/p>\n

Inside the input<\/h3>\n

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’ \u2013 and there is definitely enough room for a happy green checkmark when they get it right.<\/p>\n

One of my favourite parts of Work & Co’s Virgin America responsive redesign<\/a> is how it deals with form validation. It’s good at communicating a helpful validation message succinctly (e.g. ‘bad email’).<\/p>\n

\n

\"Virgin<\/p>

Virgin America\u2019s website offers helpful and succinct form validation messages with\u00a0great personality<\/figcaption><\/figure>\n

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.\u00a0<\/p>\n

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.\u00a0<\/p>\n

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.<\/p>\n

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.<\/p>\n

Outside the input<\/h3>\n

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.<\/p>\n

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’).<\/p>\n

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.<\/p>\n

Dates<\/h3>\n

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:<\/p>\n