Thursday, April 19, 2007

SnTT: Improving The User Experience With Wizards

I seem to get a lot of my blog post inspiration from questions I get asked by other developers. Someone asked me the other day about a dialog-based wizard in one of my applications. Specifically, they wanted to know how I displayed the dialog box without any buttons (OK, Cancel, etc.). I told them that this was a parameter that can be specified in the call to the dialog box and that it was an option introduced back in R5! As you can imagine, they were quite surprised. :-) It's certainly a good idea to take a look at the documentation once in a while. I've always thought that the Notes documentation (at least for development) was quite good. In fact, I tend to browse it from time to time just to see if there's something I've missed.

Anyway, I was going to use this opportunity to talk about designing a wizard with a programmatic tabbed table, but a quick search shows that some very smart people have already talked about this. So, rather than re-hash what Chris and Bill already detailed so well, I thought I'd just take a minute to explain the reason why I use a wizard-based approach in many applications.

I know it's hard to believe sometimes, but your users don't really care about the work of beauty that is your backend code. They're not interested in how it works, that you're using the latest ajax technique or that you've been able to optimize the database to fit 20% more data. Nope...they care about one thing when using your easy it is to get in, get their work done and get out. I see my ultimate goal as a designer to make the UI of my applications so transparent that users "just get it". You want to try to get the interface out of the user's way so they can just perform the task at hand and get on with what actually makes the company money.

Especially in Lotus Notes, this is oftentimes easier said than done. Many interface elements are unintuitive (I'm talking about pre-Notes 8, of course), menus offer a confusing array of choices, the context menus are too long :-), etc. Whenever I am faced with a design that is going to require the user to either a) have some advanced knowledge of the Notes client interface or b) require several steps that would invariably mean that I would have to write documentation, I immediately turn my thoughts to building a wizard.

Let's take a very common example: importing data into Notes from Excel or some kind of file. We do this all the time. I decided a long time ago that never again do I want to try to explain the steps of importing data "the hard way" to a user. You know what I'm talking about.

1) Make sure you know where your spreadsheet is on your hard drive.
2) Go to the File menu and choose 'Import...'. No, the File menu. See it up there in the top left corner of your screen? No, below that little icon...Yep...that's it.
3) in that dialog box, select 'Lotus 1-2-3' as the file type. Wait, you did save your spreadsheet in 1-2-3 format, right?

We've all been there...

Enter the wizard. Wizards are a great device for walking a user through a multi-step process. In the case of importing data, I put the burden of work on myself as the developer rather than the user. In my mind, the user should be able to just say "Here's my file; now go do the work!". Yes, this entails more effort for the developer and I'll say yet again that I believe 100% that this extra effort is worth it. I understand we live in a RAD environment, but that doesn't excuse us from making the user experience the best it can be.

There's a million and one ways to do something like this, so I won't be displaying any code. I would like to show you some screens to illustrate what I'm talking about though.

In one of my applications, this is the first screen the user sees when they select the option to perform the monthly processing task.

Here, they are prompted to begin the import. Because of timing issues with the ERP system, they need to do this step manually, after they receive notification that the import file is available. Behind the scenes, my code is checking if the file is really there, verifying that it is valid, performing the actual import, etc.

Once the import is complete, I want the user to make sure that the data looks OK. It could be that the technical processes all worked correctly, but perhaps the data is bad for some reason. This step allows the user to apply their specific business knowledge to make sure it is safe to continue.

In the final step, the user kicks off the agent that does all the heavy lifting. Although there are many things going on here, the user's job is easy from a standpoint of interacting with the application. "Click three buttons and I'm good to go."


Going back to the application I mentioned at the very beginning of this post, here are some screens from a dialog-based wizard.

Notice that removing the buttons from the dialog makes it look nice and clean and certainly "non-Notes like". (Hint...using simple photos in place of clipart or plain pages can help make a design look more polished and professional. Bonus points are given if the photo helps convey the meaning of the current context.).

In this particular application, it was necessary to allow the user to import e-mail addresses from their contacts and their mail file into the database. Again, we made the multiple steps involved to do this seem really easy to the user, which makes them really happy. Users perform this task infrequently, so an additional benefit with this app is that by having the wizard available, the user doesn't have to remember how they did the import the last time or (even worse) have to dig through their mail file to find the instructions!

Wrapping up, the purpose of this post, as with many of my rantings, is to try to encourage you to keep the user experience in mind as you build your applications. Off-loading the hard work to the technology is what makes us valuable and allows our users to be more productive and do value-added work. In the end, this is a win-win situation for us all.


Patrick Kwinten said...

Hej Chris,

At the last developer conference of The View in Vienna 2006 I believe it was in one of Bill Buchans presentations that he told about programmatic use of tables in wizard alike functions.

When I got in contact in Bill later via email he said that he could not find a sample db to send me and that their would be samples on the internet.

Unfortunately I haven't been able to find them (if someone knows, please send an url or anything to me).

So therefor my next question: great, interesting tip, but if I want to set up my own wizard, where to start? Some sample db would greatly help!

Thanks in advance!

KR // Patrick

dogu said...

Chris, your comment about what users care about is well said. Some years ago, I stole, err borrowed, two bits of text that describe my design philosophy:

A good building, must be functional, it must be firm, and it must be delightful. Roman architect Vitruvius.

Wisdom from "Visual Basic 4 for Windows for Dummies - IDG Press".....
First of all, nobody really wants to use your program. Most people would rather be at the beach, watching TV, or making out. However, people do want the results that your program can produce. If they could get these same results by other means with less work, they would. But because they can't, they're willing to use your program.
This means that people really want your program to read their minds and then magically do whatever it is they need accomplished. Because that's not possible, the best you can hope for is to make your program as easy to use as possible. If a completely incompetent moron (your boss) can use your program, most other people will be able to use it as well.

When I stick to these ideas, things go well. When I get full of myself, it gets ugly.

Great post.


Steve said...

Great article as usual. I've built tons of these import routines over the years and never thought of using a wizard for my customer. Usually I just use a view action. I can see where the wizard approach is definitely more friendly.

I had a question, though, about your screen shots. They may have been cleaned up for the blog, but I didn't see where you handle bad data in Step 2. I see the Data verified button, but what do you do if the data is bad or needs tweaking? Since it looks like you're using an embedded view, do you let the user do an in-line edit, do you give them some other tool, or do you let them scrap it and reimport? Just curious how you present that to the user.

On a totally different note, I attended Nathan and your presentation at Lotusphere, as well as the Birds of a Feather session, but I haven't seen you all comment much on error handling and/or data validation. Not the error handling in code per se, but the visual feedback you provide to users. Do you simply use message boxes? custom dialogs? something on the form? If you are doing something cool, I would like to suggest that as future article.

Again, I really value the stuff you're sharing. Keep up the good work.

Chris Blatnick said...

@Patrick...Yes, I can put a sample database together. I'm pretty booked up right now, so please stand by. Shout if I Thanks!

Chris Blatnick said... both quotes. Thanks for sharing!

Chris Blatnick said...

@Steve...thanks for the comments! Indeed, I was wondering if someone would call me on the handling of bad data. In this example, if the data is bad, the user knows that they have to stop and go back to the ERP system. This has never happened (knock on wood), but we discussed the issue during the design phase and decided that if something goes wrong, it's best just to close out and start over after the ERP data has been cleaned up.

I've got an article in the idea queue for handling errors, so please stand by for that. When it's published, I'd love to hear your comments. Thanks!

Gerry said...

Great article. I've never seen a Notes App look so user friendly. I believe I will definitely create wizards alot more (when applicable) from now on. Thanks for sharing.