Online forms are one of the most tricky areas of website development to get right, especially with so many things that can go wrong. The changing nature of how people access online content also has had an impact on a technology that was developed years before people expected to be able to with a phone what they normally would only do with a computer. It's a technology which has undergone very little evolution.
The design of web forms should be a stand-alone profession. Site designers should be engaging the services of full time professional web form designers to help them in their task. But this is not seen as economical enough, and so most of the time the site designer is also responsible for the design of any forms used on the site.
But designing forms is a highly specialized skill. It requires understanding how people interact with information and understanding the best ways to collect and present information. Where general web design is mainly centered around presenting information and images in attractive but practical ways, form design demands that we focus our attention on the nature of the information and then decide the best way to structure it on the page so that it will work as intended. Aesthetics are a less important consideration in this case, but still should not be forgotten.
In this article we'll take a look at the art of web form design, and see if we can find a way to make our web forms smarter both in terms of how they look and how they function.
The tools of web form building
The standard tools we've been given by browser developers and W3C to put our web forms together are not exactly ideal, and before applying CSS to them, they're actually rather hideous. This is what they look like:
There is also another standard input control called select, but you should avoid using this unless saving space is a serious concern. There are better ways to handle the task performed by the select control, as we'll discuss later. Textarea controls should also be avoided when possible because they are so problematic and antiquarian.
In addition to these standard input items, there are also special new ones created for HTML5. Except when a document is being prepared strictly for internal use and where the browser environment is known, only components that work in both Firefox and Chrome should be used. It's good if a component also works in other browsers, but it shouldn't only work in other browsers. Here are the HTML5 components as they appear in Firefox:
And their slightly different appearance in Chrome:
Now, obviously it is really important to be aware that your HTML5 inputs will look and function differently between Chrome and Firefox, but they'll still work. The standard input controls also look a little nicer in Chrome than in Firefox. Notice that Chrome imposes the North American date standard, which users may not appreciate. Also the Chrome version of the date control makes it unsuitable for display, and should only be used for input. The addition of a date-picker is the main improvement in Chrome, but we can probably expect to see this in future versions of Firefox.
Because Firefox is open source, you can actually make your own personal version of Firefox render the inputs the same way Chrome does by downloading the open source Chromium browser source code on which Chrome is based, and porting the relevant section of code to the Firefox source code (but then you'll have to do that every time you upgrade Firefox to a new version).
The main point is, however, that even with Chrome's enhancements, the default appearance of input controls is small and unattractive. There are a few other controls available, but because they don't work in both Chrome and Firefox, they should not be used on sites intended for the public.
Bootstrap's (almost adequate) answer
Bootstrap applies styling to the standard controls that enhances their appearance to some extent. But due to Bootstrap's mobile-centric design philosophy, it does cause some undesirable effects on forms that are not intended to be displayed as a single column, and makes short input fields look funny when they span an entire column by default. The world may have gone mobile, but forms were not invented with mobile users in mind.
Bootstrap expands controls to fill the horizontal width of their container, meaning all controls will have the same width whether you like it or not (unless you manually over-ride this behavior), and allows you to dress up some control types with additional bling. Bootstrap's solution is elegant and overcomes some of the problems of controls having different appearances in different browsers, but it only works with the standard controls. The HTML5 controls aren't implemented in current versions of Bootstrap, so you'll have to style those on your own.
Bootstrap also lets you combine controls together. Sometimes this is good and sometimes not so good. Combining a text input with a button and a checkbox may look good, but it could confuse the user as to how they should interact with such an unfamiliar control.
What Bootstrap does provide is two of my favorite form building devices, the panel and the well. These are very useful for grouping form data to give a visual indication of which data is related to which other data, and also for segregating data.
Smart Form Building 101
Now we are ready to think about how forms can be constructed in smarter ways. To do this, we need to be thinking well past the defaults. We need to be aware of the desktop-bound roots of form controls, and also the need for mobile compatibility. And we need to care about things like usability and validation (if the form will be used for data collection).
That last point is a good one, because while form controls are used for collecting input, they are also used for displaying stored data. The average web user is (and should be) more interested in getting information from you than giving information to you.
Data collection is easy. People will fill in anything you stick in front of them, even if it's a mess. But when it comes to data display, they're more fussy. Consequently here we will focus more on the use of forms to display data than to collect it, since display requires more care and more “smartness.”
1. Do we need a form?
Before we build a form, we should check that we actually need one. If the data can be adequately and unconfusingly represented as a table, a table will usually be more efficient and practical.
A form is necessary if:
- We are collecting input from the user
- We have a lot of data to display
- The data needs to be clearly segmented
- The user is likely to be accessing the data from a mobile device
If any of the above items is not true, then it's not necessary to use a form, and a table will suffice. The challenge we face with mobile compatibility is that neither tables nor forms are really suited to a mobile display. The fact that smartphone designers gave their users the option of using a browser in portrait orientation and that most users prefer to hold their phones that way causes most of the mobile compatibility problems site designers have to cope with.
Regardless, forms are more adaptable to a mobile display than tables are. So if you really must ensure that all the data can be easily viewed on a mobile display, then forms are a better choice than tables… sometimes!
2. Design the desktop layout
It's true that in general you're supposed to design a mobile layout first, but when it comes to forms, that's not the best way, because we need to know how data is going to be grouped, and we can only do that if we can see all the fields at once, which is something that can't be done on a mobile unless you're displaying so little data that we needn't bother with designing the form.
The fastest way to mock up a form design is with InkScape. In this example, we'll build a system for managing HR records. Here is the mock up for the desktop prototype:
The outside rectangle represents the entire space of a 1024 x 768 px display. On any desktop browser, we don't have access to that many pixels unless the user is in full screen mode (which is rarely the case). So our
design is 900 x 600px, which should fit in the available area of most desktop screens.
When the available area is less than 900px wide, our 2 x 450px columns will break and appear as one continuous 450px column. This solves the problem of mobile compatibility, at least until Google demands we make all our sites able to fit on a wrist-watch screen.
You will notice that most of the display is just composed of ordinary input boxes, which may seem boring, but in reality is nearly always the best way to do it. Also notice the use of a fixed width font. This helps to keep uniformity in form design.
Our columns will actually be slightly more than 450px, more like 600px each, but if we did want to force the column width to be about 450px we just reduce our column size from 6 to 5. But a 600px column should fit on a mobile screen in portrait mode without wrapping, anyway.
We'll test our layout with this code:
And we can see that everything is looking good (because temporarily we added borders to show us).
The Linux screen ruler widget is obviously not part of the web page, but it's there to show us that our columns won't break badly on a smaller display. Let's what happens at different common screen widths:
3. Creating custom input sizes and label position
If we just leave everything in default, without adding any custom CSS, this is what will happen when we add our first row of input controls:
This happens because the label for each input defaults to the left of the input, and because we haven't set a custom width for the input controls. We can fix both problems with CSS.
Now we just set the display property of label elements to “block”, set the fields of First and Last to class “in40w”, and field MI to class “in10w”, and everything should look much nicer.
As you can see, it does look better, but the layout is no longer correct. Now the boxes are stacked. So how we fix that is by doing away with the idea of using the label element at all, because we don't really need that. We'll just apply our in40w and in10w classes, plus make a new class called inLeftOf.
Which, once applied, fixes the problem we saw earlier, like this:
But this is not leaving enough room for the SSN field. That's because our left column is larger than expected, so 40% is actually more space than we need for these fields, so we can actually cut them down to in30w, and the middle field is bigger than it needs to be, so we can make that in5w. Here's what happens:
So now there's more than enough room to add the SSN field, which completes the first line of our input form. After smoothing out all these details, building the rest of the left column should be very easy. We can get rid of the temporary border now, and also apply the correct background to the column. Here's the top half of the panel, before we get to special areas of the form:
A few things have happened by this stage. The first was the easy part of setting the background color for the column (rgb(235,235,246)), and although you can't see it here, the text color for all the inputs has been set to #427DB4, and the font-weight was set to bold so as to reduce eye-strain. The text was set to automatically transform to uppercase using the CSS text-transform property, so as to speed up data entry and reduce errors.
The more complex matter of aligning the controls and making sure they'd keep a decent alignment on any display type required more thought. You already saw the technique used for the first line of inputs and their labels. This technique will work when there doesn't need to be any additional spacing between inputs, but if we do need to add space, then it's better to use another technique.
This other technique involves creating a nested row of columns inside our main column, which will help to keep the controls properly spaced. The number of columns and their sizes changes depending on the requirements of each set of controls. Remember everything is responsive, so when a column is resized, everything inside the column will try to resize to match the change. This is good news for visually impaired users, as they can zoom up the magnification on their display and everything will be lined up correctly as for any other user.
Moving on to the more complex part of the left column, the original concept outlined in the mock-up called for a structure that would have been difficult to implement. Fortunately I realized the data on the entitlements panel could be doubled up if standard checkboxes were used, and this solved the layout complexity problem nicely:
The lighter panels around the special sections are just ordinary Bootstrap wells. For entering religion data, it is necessary to choose from a set list of predefined official religions (including “other”). Developing the right side columns was even easier, and just used the same techniques from the first set of controls on the left column, organizing the controls in a table format, but without using a table.
For this project to be a success, it had to provide perfect responsiveness on all official display sizes. Let's see how the result turned out. First with the full resolution version:
That is close enough to the prototype that we can be satisfied with it. In fact, it's even an improvement. Now let's see the responsive layout at each of the different sections of the page:
Bootstrap and HTML5 have made form development faster and easier than every before, but many developers undermine this progress by making forms too complicated (using the special HTML5 form elements just because they are there to to be used instead of because they are needed for the project), and by creating entirely one-dimensional forms that don't even attempt to take advantage of responsive design. With just a little care and extra work, any data can be made to look more presentable on any size of screen.
You may get a few minor glitches on the smallest screen size in portrait layout on the smallest screen size (in the case of this project, the Middle Initial field on the first row is a bit smaller than would be ideal), but mobile users generally accept that this is the trade-off they have to make for not holding their phones properly.
Do it right, and your data forms can look like this:
Instead of, uh, this:
header image courtesy of
Comments 0 Responses