In web applications, forms are a nightmare for the user, the project manager, and the developer. They are counterintuitive and error prone, they require a lot of work for submission, validation, and redisplay when the validation fails, and because of that they require a lot of specifications and tests.

(download)

Click here to download:

Forms_Are_Evil_1_Filter_Forms.zip (434 KB)

Let's consider the forms commonly used to filter lists of results in backend administrations. The first screenshot shows a filter form used to filter a list of users. These forms are very handy to quickly reduce the number of items displayed in a list, but if you look closely they have several drawbacks:

• They require a lot of manipulation. To fill in a text input, you must click inside the control, leave your mouse, type some text, and use the mouse again to jump to the next control or submit button. Dropdown lists are not much better: you must click once to open them, you must sometimes scroll in the list to find the item you want, and click on it to close the dropdown list. Option buttons are sometimes hard to click on - the label is not always clickable. And "rich" widgets (date pickers, rich text editors) often lack the final polish that makes a control truly usable. Filling in a form may look easy to you, but heavy users often drop form controls in favor of keyboard shortcuts, and unexperienced web users don't use them because they are scared.
• "Open" fields (i.e. text inputs and textareas) are intimidating and prone to error. I know many people who dislike the keyboard a lot and make a lot of typing mistakes. Those people fly away as soon as they see a text field, because every time they use them, the forms displays again with an error message. Filter forms often display more than one text field - in fact, they provide one text field for every column you can search. Wildcards always use a different syntax ( `%` or `*` ?), they are sometimes implied and sometimes not, and logical keywords are most of the time unsupported but you never know. To sum up, each text field should come with a manual.
• You must submit the whole form to see the results. So if you do progressive search, you must fill in one field, then submit, wait for the page to refresh, then fill in another one, then submit and wait again for the page to redisplay. If the server is slow, or if the filter form needs a scroll or a click to be revealed, that's painful. And the opposite strategy, to fill in every form fields and submit them all at once, often results with an empty list, and you must empty the fields one by one and submit the form again and again until you get what you want.
• Form controls take a lot of visual real estate in the screen, and when you add in groups, separators, help messages, and error messages, the form displays so many visual elements that designers hide them by default. Users must click on a button to display the filter form, which adds another click to the list of actions required to use a filter form. 
  

There is one drastic solution to overcome these drawbacks: don't use a form to filter a list. In fact, most of the time, you don't need to. Look at Apple's Mail client for instance (the second screenshot attached to this post). You can browse your emails by date, folder, account, you can search in the message sender, title, content, cc, and yet there is not "form" filter so to speak.

So how can you replace your current filter form with alternative controls?

• Start by grouping all the open text fields into a single one. It's not up to the user to choose in which "column" of your structured data a search should occur. It's up to the application. Apple's Mail client offers a single search field, and text typed in this field is searched in every text part of the (email) content. That search may return more results than several text fields restricted to a single content part, but most of the time the first result is the one the user looks for, so you don't mind returning more.
• Remove the submit button and show results-as-you-type. This "spotlight"-like behavior has the advantage of removing one control (the submit button) and letting the user know when he has given enough information to find what he wants. It also allows the user to experiment with the search interface (testing AND / OR keywords for instance) without leaving the search field. Since a single search filed takes little space, you can put it always at the same place in every page without risking to clutter the screen. How about the top right of the window, where users usually look for it? Of course, you will have to do some Ajax to implement that, but good libraries doing this are everywhere.
• Transform dropdown lists into lists of links. Think about the list of folders in the right side of mail client. It is much more convenient to use than a dropdown, because one click immediately refreshes the list to show only the items in that folder. You don't need to open the dropdown, choose the item, and validate the form. Also, the list of links can convey more information - like the number of results you can expect to see if you click on the link. All your dropdown lists should be grouped in a "filters" panel, and represented more or less as folders.
• Some filter form controls may not easily be converted either to a single text field, or to a list of links. Take a date filter for instance. Traditionally, filter forms offer two date widgets to allow you to enter a time interval. Well, this can also be designed as a list of links. Take the most common time interval queries and make a list of them:

• This week
• This month
• Last month
• Before last month

Granted, you won't have the same accuracy as with two date widgets, but it will be overall much simpler to use. Think of this date widget "linkification" as the way Apple do interfaces, as compared top the way Microsoft do interfaces; Apple's way offers less control, but answers 80% of the needs immediately. If the user ever needs to find something by date and if the proposed filters are not enough, changing the list ordering or actually parsing it will lead her to the result anyway.

If some filter controls can't be easily turned into a list, maybe there is an alternative way. Think about a list of comments in a blog application for instance. A good filter for this list would be the post that the comment refers to. The problem is that, as the number of posts increases, displaying a link for each post will take much of the vertical space and force other filters down the 'scroll limit'. There is an alternative solution: don't offer to filter on one post in the comments list, but offer to link to the list of comments related to a post from the page showing the details of a post. The filter is indirect, but it works.

All in all, you should be able to remove filter forms altogether in most cases. For the administration interface of the sfBlogs application, I tried to follow these principles. There is only one search field to rule them all, and all the other filters are designed as list of links - check the last screenshot for glimpse of the UI.