Wizard UI Dysfunction

Wizard_02aThe first time I ever saw a Wizard dialog used in a software product, I thought it was a pretty good idea.  If memory serves, this was right around the introduction of Windows 95, and Paula Abdul was still a singer.  Software designers were still coming to grips with the graphical user interface, and let's face it - the toolbox wasn't too extensive at this point.  You could build any interface you wanted as long as it was gray and consisted of text boxes, radio buttons and check boxes.

Users were also still learning Windows, so as forms grew in size and complexity, their eyes began to glaze over.  The wizard appeared in this barren land, and it offered hope.  Bite-sized chunks of user interface, punctuated by "Next" buttons (perhaps inspired by the rash of "to be continued..." TV episodes that also seemed popular at this time).  The best wizards also featured colorful graphics to decorate the panels - all very slick.

Wizards, of course, became a victim of their own success.  They multiplied until they reached critical mass.  Wizards were everywhere -- especially, it seemed, where they weren't really needed.

Time and technology, of course, continued to march inevitably forward.  Our tools improved.  Our toolboxes grew new UI widgets.  Al Gore invented the Internet

Slowly, designers moved on to embrace these new tools and take up the banner of Usability.  Alan Cooper taught us about affordances.  Wizards were so Windows 95.


Appropriate Wizard Use

So has the Wizard been forevermore wiped from our pallet?

No - in fact, there are still places where a Wizard UI makes sense.  They're still quite common for setup or configuration changes where you may want to go back to where you started if you screw up along the way.  They're also used for editing business objects where a "valid" state requires a lot of data entry, and you don't permit "invalid" data to be saved.  I'll talk more about this case later.

  What factors tell you you've got a candidate for a Wizards?

  • Complex operations.  Your app needs to collect a lot of information.  Maybe the data from one field affects the options available for another field.
  • Transactional operations.  There are distinct sections or steps in an operation, but they all should occur together in order for the operation to be considered complete.
  • Ordered operations.  It matters which things are entered first, second, and so on - again, perhaps because the answers on page one affect options on page three.  Generally, wizards let you go backward to edit prior answers, but they won't let you skip forward.

Generally, at least one of two of these should be true before you use a wizard.  The wizard features some UI elements and characteristics that uniquely satisfy these needs:

  • Segmented UI.  Complexity is managed by separating a big ol' hunk of data entry into bite-sized panels.
  • Contextual "Next", "Back", "Cancel", and "Finish" buttons.  These buttons appear only where they make sense ("Finish" won't appear until all required information is gathered, for instance). 
  • "Cancel" and "Finish" make the wizard transactional.  The whole wizard either succeeds, leaving you in a "good" state, or it rolls back to where you were prior to starting the wizard.  There's no such thing as bailing out in the middle with half your data set up.


Wizard Misuse

So, where do wizards not work?

The biggest problem I've seen with wizards are using them as a general data entry strategy.  I'm trying to unravel a UI right now that had been designed to feature very prominent use of wizards.  Add and edit screens, for instance, were designed as multi-page wizards -- and this was done for all of the objects in the system.

How does this violate the usability principles above?  In most of these cases, there's a lot of data to enter, but the relationships really aren't very complex.  There's no order; in fact, the wizard allows the user to skip to whatever step she wants.  News flash: this isn't a wizard anymore; it's a funny-looking tab control.

To make matters worse, this UI is on web application, which forces the web app to incur a ton of extra overhead to accommodate the transactional expectation of the wizard.  In one case, the UI even calls for a nested wizard, where you start one wizard from the middle of another one.

This would be awkward in a Windows app, where you've got real modal dialogs, and the rest of the rich UI tools needed to make this work technically.

In a web app, though, you've got the competing expectations that when you move from page to page, your work is saved; yet, when you hit "cancel" on the last wizard step, you're supposed to roll back your changes.  What a nightmare!


Wizards for "Must-be-valid" objects

Earlier, I pointed out that one of the places where wizards are commonly used was to make sure that a complex object has been properly entered and validated before saving it.

If this is really a legitimate requirement, then a wizard control might be a good choice for you.  I believe in most cases, however, you're really doing your users a disservice by "protecting" them this way.

I've seen these dialogs really frustrate users who get 3/4 through setting something up, only to find that they're missing a piece of information.  They then have to abandon their work to go figure out how to get past that hurdle.  In most cases, the system is much more usable if it allows the user to save whatever they've typed, and simply tracks the fact that this object isn't valid in its current state.  Let the user come back and fix the broken bits later.


What are your wizard nightmares?

M8 Hosting: Tech Support Deficient

I've been implementing SugarCRM in a hosted environment, and in contrast to my earlier post about great open-source customer service, this is a case where customer service is dragging down a product that would otherwise be quite good.

In fairness, I'll start with the good news.  Setup happened really quickly, with SugarCRM already loaded and running.  Mail worked, and I was able to set up ZuckerReports, which I'd been worried about, since I'd had trouble with that on a local test system.  Speed seems great, too.  There's no indication that the servers are taxed, no matter what time of day I check.

So what more could I want?

The problem is subtle, but really nagging.  The permission and ownership settings are all fouled up.

I'll try to describe the problem without dwelling too deeply into Unix / Linux tech-speak.  Linux files are owned by a combination of a user and a group, expressed as "user:group".  Permissions for these files are expressed in terms of who can do what, depending on whether you're (1) the owner of the file, (2) a member of the group that owns the file, or (3) anybody else.

Processes run as users in Linux, so I can log in to a Linux machine had have a set of permissions as "me", but when I do something via a web page hosted on that machine or an ftp session with that machine, I'm working through the web or ftp service, and I'm subject to the permissions granted to that service's user.  This is one of the ways Linux keeps itself secure (you may be able to compromise one account, but you wont be able run amok).

So here's where the trouble starts.

First problem: The web server is a different user than the user we are when we log in via ftp.  Different groups, too.  So when I ftp something up to the web site, it gets saved into the web file area, but the directories and files belong to "me", not the web server.  This isn't a problem unless it's a directory or file that SugarCRM wants to be able to change itself, and there are a surprisingly large number of those.

SugarCRM exacerbates the problem by (frequently) politely swallowing error messages, so what you see is a system that's happily puttering along while things frustratingly fail to save / update.

Next problem: Some SugarCRM customizations need to modify files on the server.  SugarCRM has a (generally) really nice feature called the "Studio" that lets you accomplish many customizations via meta-data and custom files right on the SugarCRM server, in near-real-time.  This makes short work of simple jobs like adding a field to a screen or customizing lists or drop down values.

When you make these changes, however, the web server has to be able to save them, and in some cases, this requires the web server to add one or more directories in order to maintain its structure.  Sadly, this also isn't working on our host.

I can frequently tell when I'm dealing with one of these problems, because they're goofy (something that should obviously be working just as obviously isn't) and because the exact same thing works on my test system.

Here are the two most recent cases where this setup has bitten me:

  • I needed to modify the Leads listview to include another column. Normally, this is a five-minute fix in SugarCRM's studio, so I went in and customized the listview to include the extra field.  I saved the view and went to test it, and no change had taken place. I went back into the Studio and found that my changes had reverted.  I did the same customizations on a local test system, and they worked just fine. I noted the most recently-modified files and saw that custommodulesLeadsmetadatalistviewdefs.php had been changed.  Back to M8 - I used file explorer to look at the directory structure on the production server, and found there was no "metadata" folder beneath "Leads". When Studio tried to create that directory so it could store the newly-customized file, the web server process had been unable to make the directory. If the directory had been created, I don't know if the web server would have been able to create a new file there, but I wouldn't be surprised if that failed, too.  I was able to get the changes to show up only by manually creating the folder and then uploading the file I modified on my test system.
  • I tried installing Ken Brill's advanced search module.  Now, I know that Ken knows how to package modules, and this one went in without a hitch on two separate test systems, but when I installed on the production system, I got an error complaining about permissions.  The workaround in this case was to CHMOD 777 for a couple of big chunks of the directory tree, and then set permissions back to "normal" after installation.

Now, I've begged and pleaded with M8 to get shell access so I could chown these files and directories properly, and they finally granted this to me, but my login didn't have permission to chown to the proper user and group so the web server would be happy again, so I'm still stuck!

This is driving me nuts, and I can't seem to get M8 to understand the problem.

Has anyone else experienced this with M8 or other providers? I'm afraid if this doesn't get resolved soon, I'm going to have to look for a new home for this site.  Needless to say, if anyone knows a good SugarCRM host, I'd be interested in that, as well.

Scott Adams for President

I subscribe to Scott Adams' blog feed, and his posts are usually amusing to some degree or another.  What may surprise you, though, is how often there's a nugget or two in one of his blog posts that can actually make you stop and think.  Today's post, for instance, was intriguing in much the same way that an unidentified odor is intriguing.  Like the odor, I'll be thinking about this for a while.

Scott thinks he can solve all of our problems.  I think he might be right.  (sniff...)

Here's the plan: Scott turns our national problems into a reality show.  Panels compete to solve the problems, judges zilch the William Hung solutions, and we vote on the rest.

Crazy?  Crazy like a fox, if you ask me.

Software people should be able to appreciate the opacity problem with today's legislative system.  Wayyyy too much stuff is happening in smoke-filled rooms to have any hope of a good outcome.  Like open-source software, I think there's goodness to be had in opening the legislative process.  Let's go ahead and look into the sausage factory.  And no, I'm not talking about CNBC.

It's pretty easy to lash out against something like this on the principle that it just can't possibly be right.  You might not be able to put your finger on the problem right away, but it just can't be right.  After all, the panels aren't elected, the judges aren't elected, and how would you police voter fraud?

But here's where the stink wafts into the room again.

Despite these flaws, I think I'd trust this system more than I'd trust Congressmen making backroom deals with lobbyists, while political contributions are rewarded with pork barrel spending and all sorts of palms are getting greased, none of which belong to me.

At this point, you might be oddly excited that Adams has found a better form of government, or you might be despondent over the fact that our government is so deeply fractured that a whacked idea like this can even elicit a moment's consideration.

Me?  I've got to go find a can of Lysol or something.  This smell is making me nuts.