Fog Creek Software
Discussion Board




Interface : widzard vs. menus

Hi,

Our customers are not very computer-savy, and are often lost with the menu-based interfaces that hackers are so comfortable with.

I was thinking of building an application without menus at all, and rely on wizards, starting with a main dialog with icons that would ask users what they wish to do (eg. manage a user database, compute payroll, etc.)

Any good opinion and/or good articles on the subjet?

Thx
Fred.

Frederic Faure
Thursday, April 10, 2003

Your keyword is "inductive user interfaces." Use your favorite search engine. It is an interesting topic.

Big B
Thursday, April 10, 2003

We fairly regularly receive posts form you complaining about the users of your father's software.

Either something the companies you work for all have dysfunctional HR departments, or there is something wrong with the interface to your software. No prizes for guessing which explanation I lean to!

You will no doubt have read Joel's book, but I would suggest you now take time out to read Alan Coopers "The Lunatatics are running the asylum" as well as the books Joel recommends on his site.

You could do much worse than investing in a copy of Microsoft Press "Developing User Interfaces for Microsoft Windows" by Everett McKay. It is a little pedestrian but it has the right sources and covers the ground thoroughly.

One of the most important things you need to decide is if your program is an application or a utility. An application is someting like Microsoft Word, or Internet Explorer that will be used on a regular basis. Here you can presume that people will be prepared to take a little time to learn things, and you should make sure that the interface is not too obtrusive. If you have a utility, such as a disk defragmenter, then you can presume it will be rarely used, so the default actions must be clear, and the user interface can be clunkier.

Now a wizard is something you want when a user is approaching a task for the first or second time. This may be becasue the program is a utility that they will rarely use, and thus not have the time to become acquainted with its innards, or it may be because your program is an application but the particular feature is one that will be used rarely 9for example the ability to print a booklet in a word processing program).

You can use wizards as a help to newbies using common features in an application BUT BE VERY WARY. As Cooper pioints out most UI's are written for beginners because they are the people the marketing people deal with, or experts because they are the people who get through the tech support filter to reach the developers, but the pattern is in fact a Bell Curve, with 90% of the users being intermediate users. Beginners don't stay beginners for long, and most people only develop the level of expertise in a tool that is necessary to do their job.

A general rule is never to have a wizard as the only way of doing something. Apart from the much greater work involved in effectively designing a wizard there is the fact that they rapidly become incredibly irritating.

Another rule you are presumably following is do what everybody else does. Follow ALL of the Windows recommendations and don't play around with colors or toolbars or anything; apart from the fact it is highly unlikely you know better than the guys at Redmond, you are placing unecessary strain on the user if he has to learn something new.

And look around the most popular sites on the web to see what people can find out themselves. People know to click a command button, know that something grayed out is not for typing in but something in white nearly always is, that if it is underlined it is a hyperlink, that a combo box offers them a choice, that the search button is on the left and the enter button is on the right, and so on.

Stephen Jones
Thursday, April 10, 2003

Your initiial switchboard idea is fine, but I would be wary of continuing the wizard idea much past the initial screen. If it's "compute payroll" put them straight through to a data entry form where they can add the necessary info and then have the desired info update automatically.

It is merely irritiating to have to go through fice screens asking you to type in info separately when five controls on the one form allow the same.

Incidentally do a search on the forum for Albert Kallal, and get the link to his site. You'll see some excellent examples of user interface design there.

Stephen Jones
Thursday, April 10, 2003

I've just deployed a fairly fat Purchase Order webform for some of the least computer-savvy people in teh world. We were specifically requested to provide a single form for data entry - the application we replaced was somewhat "wizard" style and they hated it. They just want a form with fields they can tab through and fill in.

Period.

I would say the original "keep your web pages one screen long so the user doesn't have to scroll" has finally been turned on its head - "keep your web pages long so all the data is on a single page. The user just wants to fill in one form and click a button"

And I believe this applies to Client apps as well as web apps.

Philo

Philo
Thursday, April 10, 2003

Thx everyone. I guess wizards aren't such a great idea after all, at least once users are more familiar with a software and are thus able to just cut to the chase.

And to answer Stephen's post : Yes, a lot of the users we deal have very limited computer abilities. But they're gov't employees... and that's a problem we have to deal with, hence my question about how to make usage as obvious as possible.

Frederic Faure
Thursday, April 10, 2003

Stop. Read This:

http://www.amazon.com/exec/obidos/ASIN/0764526413/103-0432924-1833411

(Cooper's latest.)
Start.

fool for python
Thursday, April 10, 2003

I believe that in the States government employees have to be able to sign their name, have completed a couple of years of elementary school and even in many cases be able to read and write.

As such they have all the necessary skills to use well-made and not-so-well made computer software.

The main problem in government is not that the users can't be fired, but that the managers that ordered the dysfunctiional software in the first place can't.

Stephen Jones
Thursday, April 10, 2003

My first ever commercial piece of software was to write an Estimating program which replaced a manuscript length form that was duplicated (yes with a hand cranked duplicator).

The form was used to record and calculate the estimates and as a helpful guide it had the calculations in between all of the boxes for the figures, for fixed overheads, margin etc.

Because this was the first computer system ever through the door in the company they felt it important that the program look as familiar as possible.

So, I created a scrolling form (on a character screen), which was exactly the same as their paper form, including using the asterisks to draw the border and with all the mechanical aids to get them from one end of the page to the other.

It did exactly what the piece of paper did in as close an approximation as possible.  After it had been in use a couple of days I got a call from them asking if it could just be all on one screen.  And of course it could and so I did it, it was not a great surprise.

In a way that piece of paper (and my approximation) was both a wizard (it guided the user if needed), and a single scrolling form.  Once they realised that it was pointless to have all the other gunk as the form calculated everything for them anyway, they decided that a single form was the best way to get it done.

For that reason I think Philo's end-end users (rather than their middle managers), will get extremely fed up with the problems of a scrolling form and prefer a concise set of forms instead.

Someone once said to me that a web page isn't a portrait oriented interface but a landscape one.  This is both true and almost always ignored.

Simon Lucy
Thursday, April 10, 2003

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=510

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=6949

Wizards can be done right... For example Amazon.com's checkout system. It's good because it lets you know where you are and how far you have to go.

On the other hand, once you've been through it once you can turn on one click ordering.

Every time I open up Nero Burning Rom it takes me through a wizard... annoying! Can't I just twiddle the variables myself without paging through screens?

www.marktaw.com
Thursday, April 10, 2003

A fabulous discussion

The fact that the wizard keeps changing the interface is an excellent, and often unconsidered point.

Nearly everybody knows how to fill in a form - how else would they have got the job in the first place. The problems I suspect come from badly designed forms.

Stephen Jones
Thursday, April 10, 2003

Apples and oranges.  Wizard is for forced sequential ordering of screen navigation.  Menus are for arbitrary, non-linear navigation.

Bella
Thursday, April 10, 2003

Just because someone is forced to enter information in a particular order doesn't mean the application must accept it in that order.

Often people use wizards to dumb down the process and group related items together, making the process easier for the less-than-savvy user.

www.marktaw.com
Thursday, April 10, 2003

This issue certainly can open a can worms.

I can’t really say don’t use some type of wizards, or get rid of menus. Extremes on either end of this probably is not the solution.

I find that a menu bar should be included, and it should follow the standard layout of a widows program.

A few months ago I was looking for some video editing software. I downloaded several packages (un-lead, Adobe etc…can’t remember the packages names). Anyway, the nicest and MOST powerful of the bunch was the Adobe package. (it also had the most price of the lot also).

There was several things that made the Adobe video editing package stand out, and easy to use, despite it being the most feature rich, and complex by a good margin.

First, and foremost the menu bar was standard, and it was much like word, Excel, etc. You could guess that file->new was to start a new video project. Thus, when trying to learn to new package, you tend to rely on the “mental image” or picture that we all have in software. Joel talks about this in his book. Brains look for patters. While many of your users will NOT have used Word, Excel etc, a large number will have. Further, the REVERSE should also be true. In other words, people who use your software should also expect the rest of the world to operate the same once they get the hang of your package.

You should feel like a big mother duck, and all your users are cute little chicks following behind you in a nice row in the pond. One day your cute little chicks will grow up to fly away, and use other software packages.

I was much more able to do things quickly in the adobe package, despite it having less cute menus and wizard forms that the other packages had. It has a rather large menu bar with many sub-menus. However, you can blast through that menu, and quickly discover  all kind of things.

It is much like when a dog in the park accidentally gets off its leash and runs around like crazy. Those dogs run so fast, that they know where every fire hydrant in the park is in less then five minutes. Hence, if you hide everything behind a bunch of forms with buttons, you can actually increase the time to lean what is in the package. I consider my self very much like the dog running in the park, and I want to look at things real fast. So, you might want to take into account what kind of users you have. Those fast fast dogs with real big noises (like me) want menus, and we want to run real fast.

I hate those smart menus in office, and I turn them off. I want to see the whole menu. However, I do like that the smart cascading menus in the windows UI to navigate (big difference between navigating to find a application, and navigation IN SIDE an application to discover functionality). You need an ability to get a quick layout of the land, and that means menus.

Thus, Removing, or hiding this “familiar” menu approach from your users is a bad idea.

I remember years ago how many computers vendors (Packard bell and AST come to mind) tried to re-create their own windows interface. This was really common in the windows 3.1 era. Sure these cartoon like interfaces made it easier for the user. But ONLY the initial user. And, it only made things easier for about the first hour. After that, those color full desktops got in the way. Further, if you moved to another pc without the special cartoon desktop, then again things were not the same. This means that all efforts and TIME to learn that custom UI don’t transfer to a new pc. You in effect wind up wasting users time (they don’t know it yet!). Those users now have to learn something that is NOT transferable to other systems. You still thus need to provide the “normal way”.

You also have to distinguish between being cool, and functionality. Last week I was using Greetings WorksShop from Microsoft to make a birthday card. This is a example of a very cute and cartoon like user interface. Here is a screen shot when the application opens:

http://www.attcanada.net/~kallal.msn/test/gw1.jpg

Now, that screen is certainly cute. And it is not a standard user interface. However, we could be very mean here. However, it really is not so bad. Lets create a nice birthday card for Joel’s birthday. We select the “cards”, and after a few questions, the screen now looks like:

http://www.attcanada.net/~kallal.msn/test/gw2.jpg

In this case again, there is actually some what of a menu bar. The save icons, the print icon, the standard font and left/right justification icons are all there. In other words, even in a child like cute dumbbell down UI, the standard windows hints and interface options are used.  So, while there are TONS of wizards, these menus go a long way to actually making this package useable by accomplished computer users also.

That is my real point here. Don’t remove, or throw out the concepts and ideas of standard interfaces. Menus help, and make your software easy to use. You can be cute like above, you can have tons of wizards, but you should still follow the same general UI that most software has. The above is a excellent example of that.

So, in the following screen shot I have some buttons on a form for ease of use. However, all of the same functionality  is duplicated (plus a lot more) in the standard menu bar.

http://www.attcanada.net/~kallal.msn/Rides/Rides1.jpg

I liked having a main form with buttons, and they are one click as opposed to file->new etc.

Having said all of the above, I don’t think the original poster is suggesting, or even hinting to remove menus. However, I thought is good idea to give a real good run down on this whole concept.

Now, the real question here is this issue of breaking up steps into a wizard, or some series of screen steps. Now, we can take our gloves off, and jump into the ring.

Should one break down some common tasks into a series of steps? Yes, I absolute  do believe that this makes a lot of sense. Breaking some process down into a series of forms or steps can really help the user.

The trick then is WHEN TO break things into a serious of steps?

The answer is simple:

  You break things into a series of steps when trying to Complete a task!

For example, eventually after a certain amount of steps, users in my tour package need to select the type of hotel room. I also need the user to select a bus to ride on (there can often be several buses (the software normally does select a bus for the user, but often a choice can, and needs to be made). I also need the user to select any kind of additional options such as cancellation insurance, and stuff like non skiers rates. I also need the user to “over ride” some things like the number of people in a room. Quad occupancy usually means 4 people, but some ski resort hotels will allow a cot. Thus, I need all of these options to be asked, and further after the booking is made, all of these options must be easy to modify.

So, I could just fire off the booking, and then let the user “discover” all the above large number of options that do exist somewhere in the maze of menus.

(for example, here is just one menu of options):

http://www.attcanada.net/~kallal.msn/Rides/menubook.gif

However, all those options would have to be selected one after another. The user would have to “know” where those options are. In addition, the set of options applies to each of the 4 people in that booking. That can turn out to be a LARGE amount of work for the user. Thus, this is a classic problem for wizard.

So, you don’t use wizards because you want to use a wizard. A wizard ACCOMPLISHES some TASK!  Good software is task orientated. Build in your rich feature set of options. Those large number of options WILL BE in the menu system. Next, you then use the “flow” of the program to naturally present those options to the user. So, the real secret is to prompt a user for the right options at the right time. And, that means you group the “wizard” questions by task.

Simply placing all of the above tour options (questions)  from the menu into one large confusing wizard type screen would not work. The problem is that this would not make the learning of the package any easier. So, while I did not create a wizard, I did break down the above process into 3 separate screens.  Thus, forcing a “flow” on your users can result in ease of use, and, also not really increase the number of steps for a user.  In fact, in my case, the amount of work is reduced since each booking really needs all those questions answered by the user anyway. Booking 6 people into a room each with a complex set of options is NO more work then booking one person. It is slick, and it is fast.

If you did not sit down and identify the “tasks” that a user has to do, then you are wasting your time to try and break out options from a menu into a wizard. If your software cannot accomplish the required tasks now, then no amount of wizards can save your application. If your software can accomplish all the tasks at hand, then it certainly  is a candidate to now start incorporating wizards.

TASK ARE THE GOLDEN keys here.

Hence, after a room is selected, I then prompt the user with the next set of options (what bus, and additional tour pricing options). I debated this issue a lot. In other words, I introduced a 2nd form on purpose into this process (there are actually 3 screens used). This requires a extra mouse click (the ok button) into this process. If you don’t think that an extra mouse click is a legitimate debate for your UI, then you are missing a big point here. Most certainly adding a extra mouse click to any process SHOULD NOT be taken lightly. This kind of stuff should be a take the gloves off smack me in the face type debate.

There was also the issue of sales and training that came into play. By popping up an additional screen, the persons using the software now MUST make SOME effort to select those additional options for a tour (but they need to do that anyway!!). Thus, the users now DO NOT need to be trained to learn, and know to ask those options. It becomes self evident, and thus the software is easy to use.

This is very much like how McDonalds teaches their staff to ask if you want French fries. Apparently, that simple question is worth millions to Macdonald’s. I specificity added this feature for the customer due to this concern. Again, the main key here was the TASK AT HAND. You don’t just prompt for cancellation insurance, but you sure do when making a booking (those type of options are NOT hard coded into this application by the way)..

Thus, I duplicate the flow, and questions that a operator needs to ask during a tour booking (again, the “task” at hand).

It would be crazy to suggest that breaking 10 questions into 10 screens. That would help nothing here. That would also drive the users to a room with padded walls.

Thus, one must resist this typical programming urge that the user needs to be asked a bunch of questions.

On a very simple level, we are talking about the same kind of thing as ms-word’s two print icons. One prints to directly to the default printer, and NO questions are asked. The other fires up the print dialog box allowing to select a different printer. Hence, do you REALLY need to ask what printer to print to?

Now, if the user DOES NEED to know that a printer can be changed, then presenting the dialog always with a printer option thus eliminates user training. (it will become obvious that printers can be changed). This is the key to reducing training, and it is why breaking up menus into a series of steps can also reduce training.

In addition, the other trick is to break the steps in a fashion that does not cost too much user interface time. If you need to ask the user 10 questions, then breaking that into two screens only makes sense if the first 4 questions are related, and then the next 6.

Remember, you only ask questions that are part of the current task.

At the end of the day, if your application is laid out well, then using the software should NOT be the problem. The problem is ALWAYS the users domain knowledge of their task at hand.

Also, you can’t always put all knowledge into your applications. Some tours only allow people over 18 years old. To start prompting users to ask for age is simply too annoying. You have to at a certain point rely on trained operators. You have to give your users some credit.

Hence, often some software usability problems are NOT the software at all! That so called “domain” knowledge stuff like age requirements etc needs training. That kind of training has nothing to do with the software problem side of things. One should not fool one self that software can eliminate all domain knowledge…but good software really does and can reduce the domain knowledge required to do a task. Just take a look at QuickBooks.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Friday, April 11, 2003

Agreed.  Wizards don't have to look like tabbed dialogs.  In whatever way you design it if its a process, a series of tasks then the balance is between making the user jump through hoops and giving them the feeling, or the reality of being in control.

Forms, processes should be context sensitive, if someone is half way through a process and they find there's a piece of information missing then they need to be able to duck out and get it, without throwing away their work to date.

On the whole I hate menus, they drag my attention away from the work at hand they are rarely semantically grouped once out of the MS File,Edit, Window, Help model.  The borders between those that are contextual menu options and those that are global or module is fuzzy and ill defined.

Menu systems, remember, began as a real menu You had a series of lists to navigate, each one like a restaurant menu.    Drop down menus were supposed to be better because the whole deal was directly available.

But it depends largely on user's being able to remember where those options are.  The 'display only what you regularly use' option in Office, and the shell is a beginning attempt to make that easier but its too much of a blunderbuss. 

For contextual work I prefer context menus and tear-offs but then they either clutter the space or you have to perform the restaurant menu navigation trick on a context menu.  Again you have to know what you want to do and what its called.

Life is too short for most of us to customise all the menu options we get into using, developers tend to use many more applications than a regular user of software who will actively use one, two or at most four applications to get done what they need to do.

I've done some work on gesture menus, circular context menus (right click circle through a set of context menus), toolbars and the rest in the journey to discover a memorable interface that adapts to the user's experience and use of an application.

It is not easy.

Hieroglyphs, or toobars depend upon them being sufficiently suggestive to not need textual cues but again that depends on familiarity and too many groups or too many buttons and you are as lost as when using drop down menus.

I'm now convinced that its applications that are too complicated rather than the user interfaces, or rather that we are too quick to add features on top of a structure which already fulfills a user's expectations.

But then that goes into the broken model of consumerism and the need to churn money out of a product which is  essentially rust proof.

Simon Lucy
Saturday, April 12, 2003

My opinion on the original question is that you should provide a full user interface using menus etc.

Wizards exist for two reasons :-

1) To explain operations that people only do very occasionally. Such as an initial setup of a program where asking questions can help the user understand what they need to do.

2) To simplify a complex operation where you'd need to change lots of settings, but the computer can figure them out for you based on some questions. For example where you have dozens of access permissions you might have a wizard which asks if you want high/medium/low security and it sets everything for you.

Apart from those two uses I hate wizards, they just get in the way.

John Burton
Monday, April 14, 2003

A great example of a wizard-style application is TurboTax. It asks you dozens of questions about your income and expenses and deductions, and then it does all of the math for you to fill out the actual paperwork. It's great software, and I can't imagine how they would organize it any other way.

(Applications that conform more to a wizard-style approach are the exception, though, rather than the rule.)

Benji Smith
Monday, April 14, 2003

*  Recent Topics

*  Fog Creek Home