Forgive Them...For They Know Not What They Do...With Your AppIf you've been following along with the home game, then you are aware that there are many excellent UI patterns that you can use to improve the user experience you deliver to your users in your applications. Today, I wanted to explore another simple yet powerful pattern: "Forgiving Formats". This pattern is perfect for those applications in which speed to data entry is key (or at least desirable in most circumstances). I know in many of the business applications I have encountered over the years, we tend to develop nice, complex forms to capture all of the data the customer says they absolutely need. When you come back and look at the database later, however, you often find that only a few key fields are filled out (just the required ones if you're using validation!). The Forgiving Format pattern is all about letting users enter those key bits of data quickly, without having to worry overly much about the way they are entering the content. This pattern puts the onus on you as the developer to do the heavy lifting, not the end user. Of course, this is one of the tenants of interface first design. It allows you to simplify the UI and make the problem really about the behind-the-scenes code.
A great example of the Forgiving Format pattern is Google Maps. When searching for an address, you can use a variety of inputs. For example, when searching for a location in my town, I can put in:
This flexibility allows me to focus on the job at hand, not on the exact way I have to format the address so that Google understands it. This lets me get my work done faster, so obviously it makes me a happy user.
You can apply this same idea to your applications. I find it can be useful both for allowing quick data entry for Notes documents as well as for use as a search mechanism. The underlying idea is simple. As the developer, you have to account for the various input types the user may enter and then code for those instances. In my Movie Review sample database, the main input is obviously movie information. While the form allows you to capture more data, there are only a few fields that are key to building a good database of movie knowledge. These include the movie title, the rating, the genre and the running time. I created a Quick Movie Entry option in the database to show this in action. First, let's take a look at how I implemented this.
I created a caption in the frame so that the user could free up screen real estate if they didn't want to use this option. It gets it out of the way if the user will be doing something other than data entry. However, if they want to quickly add a bunch of movies, they can expand the caption area and then will see an input line for the movie information. Of course you could break the input into a bunch of separate fields to capture the user input, but a single field is easier and more elegant.
I included a brief explanation of what the user should enter with this control. This particular pattern works best when you have information that is targeted to a specific objective and when the input is something that you can prepare for. Leaving it completely open ended would be incredibly hard to program for and would likely result in failure. In this case, I'm expecting those four particular bits of data and I want the user to enter them in that order, as specified by the help text. When you choose to implement this functionality in your own application, you will have to weigh how flexible you want to be with the input field and possible combinations of entries vs. the complexity of the evaluating code.
In the Movie Review example, the user can enter the title, rating, genre and running time and then hit the "Go" button. If the code successfully recognizes the entry, a new document is created in the database and the user is informed via a popup message (using the fade in/fade out technique). If the input can't be recognized, the user sees an error message.
As far as the backend code goes, it can be fairly simple or very complex, depending again on how flexible you want to make this functionality for the end user. In this example, there are two fields that I'm actually mapping to already established categories. The rating should obviously be a valid entry (G, PG, PG-13, R and NC-17) and the genre has values such as Science Fiction, Drama, Comedy, etc. To evaluate these, I used a Select Case statement. This allows for the "forgiving" part of this pattern.
In the case of the rating, one user might enter a NC-17 movie as NC17 while another might use X and another might use XXX. They could also use varying values of upper and lower case (e.g. Nc17, nc-17, xxx). For each of these different possibilities, a Select Case statement makes it nice and easy to evaluate the input. I did the same thing with the genres. For a Disney movie, users might enter options like cartoon, animated, animation, etc.
Below is the sample code behind the button. Feel free to use this as a guide, but remember there is no robust error handling in the example.
provided by Julian Robichaux at nsftools.com.
When you break it down, I think that this a very simple UI pattern to implement in your applications. As always, it comes down to trying to simplify the user's task. While this pattern is not applicable to all situations, I can think of a good number of Notes applications I use frequently that could benefit from the Forgiving Format pattern. Does one of yours? Give it a try and let me know how it goes.