Long forms: scroll or tab?

As some of you will know, I’m pretty much a diehard forms obsessive and there’s nothing I like more than a question about forms – especially if I have some experience or data to support my answer. So I thought I’d devote this month’s article to one that comes up quite often, but was neatly expressed by Cindy Lu of HFE Consulting.

She was working recently on a long form, and asked: “If the form is two pages long, should we present them in one screen that requires vertical scrolling or organise them into tabs or pages? What about the forms that are four pages long?’

So here are my rules of thumb for answering this question.

One form = one page

What we’re really aiming for is one form = one page. If that isn’t feasible, then one topic = one page. It’s best if we can get a coherent, related group of questions together.

Scroll up to two screens

So what to do when the form or topic exceeds a screenful? I’ve seen forms working well when they scroll a bit. One screenful is fine, and I’ve seen up to two further screens work acceptably. After that, we seem to get a ‘lost in the page’ effect.

I also take into account whether the user is likely to want to print the form. There are several reasons:

  • to keep a record
  • to review the answers
  • to help collect answers if the answers have to be gathered from other people or by consulting other documents.

If so, then it’s really quite helpful to have about two screensful per page as this usually fits neatly onto ordinary letter/A4 paper.

Scroll or tab?

If you are splitting the form into pages, should you use tabs to display the pages?

Tabs are problematic, because it isn’t all that clear whether changes made to one tab should be applied when moving to another tab. And there’s always a risk of overlooking the tab navigation altogether, with confusing results (‘where’s the rest of the form?’).

So I’ve found that designs based on whole screens are more frequently successful than designs that rely on tabbed panes. But it’s certainly possible to create acceptable tabbed designs – provided that there is a maximum of one row of tabs.

One column or two columns?

Cindy also asked: one column or two columns? She pointed out that for ease of reading, we could present the fields into one column. The user will fill out the form from top to bottom. Or, to take advantage of the screen space, like windows applications, we could group the fields and place them into two columns. We can reduce the scrolling. Is there a chance that the user may miss some fields?

My view: with two columns, there is a chance that the user may miss some fields. The problem arises because using two columns creates an ambiguous reading order. We start with the box in the top left corner. Now where to go? Across horizontally or down vertically?

One column works better, usually

I’ve seen it work acceptably on paper when there is a very strong visual grouping that makes it quite clear that columns go together rather than rows, or vice versa. But note that I said ‘acceptably’ rather than ‘well’. This was a compromise between overall visual length of the form and accepting that some users would go wrong.

On screen, I’d be worried about potential accessibility issues in the reading order – as well as the visual issues. Using a tab sequence doesn’t necessarily sort it out. People’s eyes will move to wherever they expect the next field to be, and they don’t sit back to wait for the flashing cursor to tell them where to look. Also, screen real estate is a lot more flexible than paper so it’s usually better to use it generously.

Exception: intensive data entry

BUT – and here’s the big exception – if these forms are being filled in repetitively and/or constantly referred to, then it works better to crush as much as possible onto the screen – then make sure you allow plenty of time for training/familiarisation.

This article first appeared in Usability News