Stupid is as stupid does.

June 7, 2008

The Fuse Test

The length of the fuse on a software package is the amount of time in seconds or minutes between the start of software installation, and the point at which the end user utters their first expletive.

Ever had one of those days when you need to install a software package, and within minutes of the download, your blood is boiling so much that you want to hurl your monitor out of the window?

If you have, chances are the software you are using has failed the Fuse Test, and chances are good that you will end up throwing the software out in disgust and trying something else.

So, software developers: how do you avoid lighting the fuse and giving your end users a heart attack? Read and learn.

The villain of the piece today is a software package called Spark, that allows you to chat against a Jabber server. They truly aren't the worst example of a failure of the fuse test, they are simply the people most recent to have failed it.

Let us start with installation. Download the version for MacOSX, which downloads as a standard DMG file, a disk image format common with MacOSX software installation. So far, pretty standard stuff. Mount the image, and copy the Spark package across to the Applications folder. Plain sailing so far. Run the application, and you get an opening login screen, and here is where the problems start.

You are asked to provide a username, a password, and a server. Username and password are not a problem, but the server? Here there are options. Do they want the name of the server only? If so, How do I express the port number (which in this case is not standard), or the fact that the server might be an SSL server? Do I represent the server as a servername and port separated by a colon? Or do I express the server as a URL? No idea, but there is a potential solution to this: the "accounts" button.

Accounts gives me the same options: username / password / server. There is no option to specify the port, and no option to turn enable or disable SSL, so the most logical solution is to try the URL form, and I try xmpp://server:61222. Once filled in, I click on "create account", and a "busy" status bar appears to show the software is thinking about something.

Hang on a second. Why is the software thinking about something? Have I typed something in incorrectly? Let me click the cancel button and try again. Oops, no cancel button, just a button that says "close" which closes the window and loses everything I have entered.

@$*(!

At this point, the software fails the fuse test.

Of course the software developer is probably picking holes in the above story already. "It says 'Create account', and that means it is trying to create the account on the server!". Are you sure? Does it not perhaps mean to create an account entry within the client? After all, the button I pressed to get to this dialog was called "Accounts", and that implies more than one.

The reason this makes no sense is the precedent established by other similar software packages. Apple's iChat application contains a button called "Accounts", which leads you to a process where you express the username, the password, and the server for each chat account you plan to connect to.

If your software works differently to other packages out there, make this fact very clear to your end users.

Of course the software developer is not obligated to implement the same features as found in other applications. However the developer is obliged to make it very clear exactly what the end user is expected to do, and this is achieved using explanatory text within the dialog boxes. In the case of Spark, there is no explanatory text at all apart from a vague "create a new chat account". Does this mean create a new chat account on the server you tried to connect to, or does it mean create a new chat account within the list of accounts on the client?

Throw your end users a bone: Use plain text to explain to the user what they should be expected to do.

While I type this, Spark is still "busy" trying to "create account". By this point you would have expected a timeout of some kind, or some kind of clue that what you attempted was not successful. No such luck. So I click on "close" and try an alternative approach.

Going back to the main login screen, I try and enter the username, password, and XMPP URL of the server, and I click "login". Instantaneously, I receive the message "invalid username or password". That is an immediate clue that something further is broken - neither the net connection, nor the XMPP server, nor the LDAP server that backs everything, is that fast. This is evidence of further breakage:

Handle your exceptions!

Confirmation of the breakage comes about when you change the name of the server from an XMPP URL to just the name and port of the server, separated by a colon. Once this change is made, Spark successfully logs into the server. What this means is that when the name of the server is incorrect, as the servername would be if an URL was provided instead of a DNS name, the message "Invalid username or password" is shown, instead of the real error, "Servername does not exist".

This shows that the developer has interpreted any and all connection errors as the single catchall and highly inaccurate message "Invalid username or password".

No doubt at this point the software developer has pointed out that old chestnut: RTFM, or Read The Manual. It is off to the website to check out the "documentation" section, and see in more detail just what Spark can or cannot do. As of this writing that means here, where the end user is offered the option to read the "Readme and License" or the "Changelog". No manual. Ok, let's try the README file. It boils down to the sentence "Further information can be found on the Spark website", which is a bizarre claim, I am on the Spark website already!

As a designer of software myself, it is only fair that I tell the people who wrote Spark as to the various usability problems that I as an end user have encountered in the software. After all, it could be that they simply don't know of the problems their end users face. So I register with their JIRA installation, only to discover I as an end user cannot add new issues to their issue tracking system.

At this point the package is doomed. If the simple task of logging in is too much for the package to handle, I have no faith that the actual chat is likely to work without the wasting of time and additional elevated blood pressure.

Move Spark to Trash.

Problem solved.

Developers: if you want to avoid having your pride and joy unceremoniously dumped into the trash, then be considerate towards your end users. Your end users are the reason your software exists: be kind to them, and they will be kind to you by using and buying support for your software.