Observations of a Closet Lunatic

Ok, it’s time for a very geek post about a particular aspect of web-usability: Form Submission Summary.

Now it’s time to get into why it exists…

I was asked at work to come up with a way to have the information that a user fills into a form show up as a summary in the most user-friendly way possible… without actually submitting the form. Most forms on the web are pretty straightforward with how they handle summaries. You hit submit and you are taken to the next page for the summary. That’s not a bad way of doing it, but it’s not the best way.

See, the best way (at least in my professional opinion) is to have the summary show up on the same page as the form; allowing the user to look it over and (if necessary) make changes to the information. The programmatic problem with the typical submission form is that to change the information, the user will do one of two things…

1. Click a button that says something to the effect of “update information” or “change answers”. The web programmer has added functionality on that button to keep the answers that the user has already filled out and re-populate them into the form when the user gets there to update their information. The only problem with this method is that users, inevitably, with do the second thing…
2. Click their browser’s back button. They will. I swear they will. I’m a usability specialist and I do it. The problem with the browser’s back button is that it does not maintain the information that the user filled in. Now, depending on the length of the form, this is going to either be inconvinient for a user… or their going to shout vile obscenities at the website like Ralphie’s dad yells at the Bumpuses hound dogs. BUMPUSSESSSSS!!!

So… how do we get around this issue? Well, like I said, let’s keep the summary on the page you are on. But this also causes some issues:

1. If the form is long, do you put the summary on the bottom of the page, having it show up when the user clicks the “get summary” button? (By the way, if it’s getting a summary, the “submit” button should say “Get Summary”… I always say “make it say what it does because people are stupid”. I know. I’m a person). That might work, but then where does it go? Under the “get summary” button? Above it? Will a user miss that it’s there?
2. If the form is short, does the summary go above the form? Does the user know that they didn’t actually submit the form this way?

The answer I came up with kind of shoots both of these down by using the “people are stupid” method. People are stupid. Users are stupid. I’m lumped in here, everyone. I’m not name calling. We’re stupid. So, as a UI designer, I’m always thinking about my own stupidity as well as yours. In this case the “people are stupid” method says: “when people might be confused, show them only what they really need to see, and give them only buttons that they really might use or need to use“.

So, I kind of devised a knockoff of Lightbox or Thickbox or Prototype Window. This basically puts the summary window above the form in a overlay. Why a knockoff and not just use one of those? Well… I tried them. Lightbox didin’t seem to allow me to pass variables to the window, nor did Thickbox. And Prototype Window… well, let’s just say that maybe I’m stupid and couldn’t understand the documentation one bit. Maybe it would work, but I don’t know. At any rate, I set out on a mission to build my own CSS/Prototype overlayed form summary. In doing so, it’s much more streamlined than if I’d used those other, more code-bloated solutions.

Here’s what it needed to do:

1. Show a summary of everything the user had filled out
2. Transparently Overlay on top of the form, so the form was “dimmed out” in the background
3. Force the form fields to be inaccessible while the summary window is shown
4. Have the summary window be fixed so that there would be no scrolling of the background form while the summary is shown
5. Allow the user to close the summary window without losing any information
6. Allow the user to submit the form from the summary window.
7. Have it work in Firefox, Safari, Opera, IE6 (The evil browser), and IE7 (The evil browser’s slightly less evil younger brother)

It’s a bit trickier to do this than I expected. I ran into some issues:

1. IE6 hates Alpha-transparency pngs. I used a little expression hack in my css (it likely doesn’t validate, but it works) to fix this.
2. IE6 is really annoying when it comes to select elements in forms. Any select element would show on top of the summary window. I did some research and found that to fix a glitch you need to create a glitch, basically. This is why, when you see the code, there is a blank iframe set to an IE6 specific CSS hack for transparency. It’s dumb, it’s extraneous code, but it does work in IE6.
3. In doing this, it also fixed another problem. IE6 would allow users to continue filling out the main form even though there was an overlay div above it. Of course, it was the only browser being a pain. Putting in that iframe made the form below it inaccessible. Bonus.
4. The overlay can’t be relative to the body element in IE6 or IE7, or it will get cut off if the form goes beyond the viewport. Annoying. There needs to be a container div (in the example’s case, it’s a div with the ID of “Wrapper”).
5. To get the summary to overlay over the page in the middle (or close to it) of the current viewport, the div that houses the overlay needs to be set to position:fixed in the CSS. THis means that if I press “Enter while in the middle of the form, the overlay shows up in the middle (or close to it) of my screen, rather than the middle of the page or viewport height). Guess who doesn’t do position:fixed. That’s right, our old friend IE6. I had to use a proprietary “expression” declaration in the CSS for IE6 to cause it to act “fixed”. The problem with the fix is that it causes the browser to have the jitters (the div jumps a little) when the body is scrolled… but we don’t want the body to be scrollable anyway (at least not while the summary window is showing). Using a little tactic from the Prototype API, I have the body of the page set to “overflow:hidden” when the “get summary” button is clicked. That way, there is no body scrolling.
6. On the subject of pressing the “Enter” key, I actually had to grab some Javascript to get that to work, since the form isn’t actually submitting, but rather showing a summary on the fly. This is also why there is a onSubmit="return false;" declaration on the main form.
7. I’m not really a very good programmer (I’m a front end guy), so I have hidden fields that capture the data that the user provides in the summary window. I’m sure that a good programmer could do this using session variables.
8. A programmer that I work with suggested adding a “processing” bar just in case the database call takes too long. It’s a good usability idea. The way I set it up is to have the “Get Summary” button disappear when clicked and it is replaced by the “processing bar” (which is literally just the word ‘processing‘ with an animated gif that indicates something is happening behind the scenes). You’ll likely not notice this in the example because the script runs too fast for it.
9. Oddly, IE7’s alpha transparency on the overlay’s background PNG was much darker than all other browsers. I have no idea as to why. The typical Alpha on the PNG is set to %75, while the alpha for IE7’s png (which is called in the CSS for just IE7) is set to %1. That way the transparency is the same (or too close to tell) in all of the tested browsers.

I’m using Prototype’s “Ajax” call to process the data into a second page that populates the summary window. The result, I believe, is a simple and user-friendly (and hopefully idiot proof) form summary. But really, this application can have a other uses… perhaps having a user review a comment on your blog before committing to it? Who knows?

The only thing that I really wish I could get to work with this is the script.aculo.us Appear and Fade effects. Every time I tried them, they didn’t actually fade in or out. They just appeared or disappeared… so I scrapped them. They’re not necessary anyway.

Hopefully this solution will prove useful to somebody else someday. I know it worked for me.

Here are those links again:

1. The Demo for the Summary Window can be found here.
2. The source code and images (there’s only 2 images) can be found here (35kb zip file).

This entry was posted on Monday, May 5th, 2008 at 3:33 pm and is filed under Usability . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.