Tuesday, December 08, 2009

Forgive Them...For They Know Not What They Do...With Your App

If 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:

Aurora, OH
Aurora, Ohio

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.

Sub Click(Source As Button)

Dim workspace As New NotesUIWorkspace
Dim session As New NotesSession
Dim db As NotesDatabase
Dim uidoc As NotesUIDocument
Dim movieDoc As NotesDocument
Dim entryDoc As NotesDocument
Dim movieEntry As Variant

Set db = session.CurrentDatabase
Set uidoc = workspace.CurrentDocument
Set entryDoc = uidoc.Document

On Error Goto ShowError

movieEntry = entryDoc.MovieEntry

'Here's where you are going to do the meat of your work.
'You need to determine just how much logic you want to put
'in place to decode what the user has entered. I've given a
'couple of simple examples below.

Set movieDoc = db.CreateDocument
movieDoc.Form = "Movie Review"

'Let's deal with the title first
Dim movieTitle As String
movieTitle = Strconv(movieEntry(0), 3)

Select Case movieEntry(1)
Case "G", "g":
movieRated = "G"
Case "PG", "pg":
movieRated = "PG"
Case "PG13", "PG-13", "pg13", "pg-13":
movieRated = "PG13"
Case "R", "r":
movieRated = "R"
Case "NC17", "NC-17", "X", "XXX", "nc17", "nc-17", "x", "xxx":
movieRated = "NC17"
Case Else
movieRated = ""
End Select

Select Case movieEntry(2)
Case "Science Fiction", "scifi", "sci-fi", "SciFi", "Sci-Fi", "Sci-fi", "Scifi":
Category = "Science Fiction"
Case "Action", "action", "Adventure", "adventure":
Category = "Action"
Case "Comedy", "comedy", "funny", "Funny", "humor", "Humor":
Category = "Comedy"
Case "cartoon", "cartoon", "animation", "Animation", "animated", "Animated":
Category = "Animation"
'etc, etc....
Case Else
Category = ""
End Select

'Here you'd actually perform the task (such as creating the
'new document if everything validated correctly. It should
'if you are careful with your forgiving format.
If movieTitle <> "" And movieRated <> "" And Category <> "" Then
Dim newMovie As NotesDocument
Set newMovie = db.CreateDocument
newMovie.Form = "Movie Review"
newMovie.MovieTitle = movieTitle
newMovie.Category = Category
newMovie.MovieRated = movieRated
newMovie.MovieTime = movieEntry(3)
Call newMovie.Save(True, False)

'Display cool fade-in success message here
'Display cool fade-in error message here
End If
Exit Sub

End Sub

This LotusScript was converted to HTML using the ls2html routine,
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.


Chuck Schilling said...

Julian, love the example you provided. I would suggest one improvement, however. I'd change the statement:
Select Case movieEntry(1)

Select Case UCase(movieEntry(1))

That way you won't have to enter "R":"r" in the individual case statements - "R" would satisfy both conditions.

TexasSwede said...

I would expand on Chuck's suggestion. To make the number of options for the Select Case statement as few as possible, and to avoid bugs through typos (you actually have "cartoons" twice with lower case C instead of one upper and one lower case), I would create a small function that strip out space and hyphens from the value, as well as convert to say uppercase.

Select Case CleanUp(movieEntry(2))

Function CleanUp(value as string) as string
Dim ReplaceArray(1)
Dim WithArray(1)

ReplaceArray(0)=" "

CleanUp = Ucase(Replace(value,ReplaceArray,WithArray))
End Function

Something like that. Now you can ignore case and any spaces and hyphens. :-)

Chris Blatnick said...

Great points, guys and these are the kind of things you should do in production code. I try to keep these samples very basic to convey the concepts. You should also make sure to add error handling to all code. I just *know* everyone is doing that, right? ;-)

Thanks for the comments!

Vladimir Kocjancic said...

The only thing that bothers me is that this code only works if user enters data in a certain sequence.

I think that this is where beauty and usability of Google Maps is really shown. Even if you type "Ohio Aurora" it will still be able to locate it.

Brandt Fundak said...

Of course, the reason that Google maps can handle Ohio Aurora is that they are probably using regular expressions to evaluate the entered string. To my knowledge, you can't use regex in LotusScript.

I suppose you could use Java to do the regex and then use javascript and then use xmlhttprequest to get the data from whatever web page you are generating the data from. But I don't know if this technique would work in the fat notes client.

Chris Blatnick said...

@Vladimir - I agree that it would be great to just allow the user to enter the values in any order. Indeed, this is the hardest part of implementing this pattern...determining how far you want to take the complexity of the underlying code. As @Brandt mentions, you would probably have to resort to regular expressions or some very sophisticated algorithms in order to evaluate the input. In a case like this example, I think striking a balance by informing the user they need to at least enter information in a certain order makes the most sense. It would still afford them the capability to enter data faster than creating a new document in the UI each time. That said, I would love to see an implementation where someone takes this farther. Any volunteers? :-)

Anonymous said...

Lotusscript, and @Formula, both have the Like operator. You can use this for pattern matching