Showing posts with label WorstUIEver. Show all posts
Showing posts with label WorstUIEver. Show all posts

Wednesday, March 4, 2009

Worst UI Ever - Another Error Message

Its been a while since I last posted a Worst UI Ever entry. It seemed like most of my posts were about error messages and here is another one for the list.


This was an error message I received when activation a gift card. The form itself could not be much simpler, but the error message left a lot to be desired. What lead me to the error message was another seemingly simple set of instructions. In order to fully understand the situation, here is the quick back story. Stay with me, I'll be quick. As you have read on my blog I recently bought an IPhone. When I did so, my wife and I both switched to AT&T. When we got our phones we got gift cards in the mail as rebates for some accessories we each purchased. So we each got a gift card in the mail today.

The instructions said that you needed to go to this website and enter the card number and you will need to use your phone number ending in 8... yes that's right, the phone number ending in 8. Now, I'm no statistician but it seems fairly likely that you may have two phone numbers in a family that both end in the same digit... as was our case.

Given the situation, one of my phone numbers was correct, the other was wrong so I was presented with this form with a 1 in 2 chance of "failing". My first flip of the coin was incorrect, resulting in the error message. The first problem with this process is the failure of the system to understand users beyond the data associated with the card. It is true that the card in question was associated with a specific phone number ending in 8, but there is more to my and my account with AT&T than just that. If that level of consideration could not be built into the system, then at least the system that prints the letter that is mailed with the card should give you more than the last digit of the phone number. Using the last two digits would dramatically reduce the liklihood of getting this error.
The second, more obivious problem was that the error message was obviously written by a programmer. The fact that there is nothing on the screen labeled as a PassCode is more than a little confusing. Here is a rule for anyone involved with delivering a software product:

"Don't let programmers write text that is presented to the user."


Chances are, they don't want that responsibility anyway.

Friday, August 1, 2008

Worst UI Ever: Too much information

Have you ever heard someone say that more information than you need couldn't hurt? In some cases that is true. However, most of the time, when it comes to communicating effectively too much information can definitely "hurt" by overwhelming the reader and ultimately confusing them. This example comes from the the US Army website and is intended to show how many pushups one must do in order to pass basic combat training. Here is the screenshot...

As you can see this grid has quite a few numbers in it... 750 cells of data. There are only 20 numbers that are actually useful to support the goal of: I want to know how many pushups I have to do to pass. The rest of the numbers are all either failing amounts or more than you need. Granted, there may be a secondary goal such as I want to know what my grade would be if I did 100 pushups. However, a grid of 750 numbers is not the best way to do that either.

Something like this would more effectively meet the goals of the user trying to see how many pushups he needs to do to pass each test.


If you find yourself saying "I'm not sure what data the user needs so lets show all of it" then you probably haven't thought enough about who your users are and why they are using your site or application. You must resist dumping the data on screen like an export from your database. It will only overwhelm the reader.

It is no different than if you ask someone on the street the time and he proceeds to list off the time in every possible timezone. That is useful data to someone but not me and not right now.

Sunday, April 13, 2008

Worst UI Ever - Progressive Disclosure

So here is a little example of what not to do. Before I go any further, let just say that Progressive Disclosure itself is not bad. In fact it is a very useful tool in many situations where you need so show more options as a result of some previous option being selected. It is just this use of it that doesn't work.

I am in the market for a minivan so I head over to the Toyota site to see what it would cost for the one I am looking for. The site is looks very nice, however I ran into this little problem. The dropdown shown below has a clearly labeled link called "Build Your Sienna" as shown below.


When clicking it, the problem is obvious


I actually had expected to be taken to the "Build Your Sienna" screen rather than have this mysterious little form pop up. In fact, for a second or two I didn't even notice it. When I did notice it, I wasn't sure what I was supposed to do. So I just clicked "Build Your Sienna" again. While my mouse button was held down, the words "Zip code" were displayed in the form field. When I released the button, it went away again.

Since I didn't think my zip code was relevant, I just clicked on "Go" and was met with this:


Apparently, a zip code is required in order for me to build my vehicle.

First of all, the if the zip code field was going to be there it should be labeled initially. This could just be a bug due to me using Firefox. Perhaps the site wasn't tested enough.

In my opinion though, if a zip code is a required part of building my vehicle then it should be part of the vehicle building process rather than this unlabeled popup. The reason for the zip code is probably due to changing costs based on geographical location. They may not want to say that on the site, but they could have said something like "Your zip code is used to find dealers near you that might have the vehicle you build in stock" This would do two things, give the user a reason why the zip code is needed and also benefit the customer since there is a good chance that a potential buyer might want to actually go test drive the vehicle at a local dealership.

While it might seem cool to add the little form using Progressive Disclosure, this is not an appropriate place for it. "How" we put stuff on screen is only part of the equation. The "Why" and "What" are usually far more important.

Wednesday, March 26, 2008

Worst UI Ever: Error Messages Part 3

As a user, I always find these terribly frustrating. As a Interaction Designer, I find these somewhat funny. Here is a tandem set of error messages from Microsoft Excel that were really frustrating at the time.

First off, my Excel document had a Word document embedded in it. I had double clicked the icon to launch Word. When I tried to close Excel with Word still open I received this error message.


Now, assuming that the error had something to do with the open Word document, you have to wonder why the error message didn't say something like "You cannot close this spreadsheet while the embedded document is open". Obviously at some point in the development, someone decided that "Reference is not valid" was going to be an appropriate message to show Bob Smith the accountant tracking inventory. Even as a developer, I have no idea what that could mean. But, since the only choice is "OK", I guessed that I should click it. After that, nothing seemed to happen, so I decided to try quiting Excel entirely. And then...

Ummm..... huh? What do you mean you can't quit Excel? Am I not in control of my own computer. I said quit and and you should quit. Again, somewhere in the development process someone decided that it would be ok to be in a state in which the application cannot stop. Like a bus with no brakes, all we can do is honk the horn and tell people we can't stop.

I assumed that the problem has to do with this Word document. So I just hit "OK" (By the way... things DO NOT feel ok at this point). I close Word and then try to quit word again and get...




... hmmm... So now things are not looking good. So I do what everyone would do and open up Task Manager, click on the Process tab, find excel and click End Process. So, if I could "quit" Excel, why did Excel say it couldn't?

This is a case where these messages were probably not expected to occur, but even if there is an unlikely chance of it, a small amount of time could have been spent to at least give some idea of why the program was in this state. A few minutes more, and the message could have explained how to recover, albeit a round about way. Almost anything would have been better than these messages.

Before all the Mac followers start proclaiming that this is why Microsoft is evil, let me just remind you of this:

Watch out... its gonna blow!

In Apple's defense though, most of the time they at least did a better job of telling you how to get past your problem.


However, the bomb icon is a bit disturbing and there is really no point in saying "unimplemented trap".

The bottom line is that if you are going to say something to the user about an error condition, make sure it is in a language they can understand. "Referenence Error" and "Unimplemented Trap" might as well be in Greek to most people.

Tuesday, January 8, 2008

Worst UI Ever? Error Messages Part 2

I can't take credit for finding this one but it is a great example of how not to treat the user. I won't bother to repeat all my thoughts here but you can read them in the comments of the original blog.

However, I will take a moment to summarize what should be a global philosophy for anyone creating software. Here it is:

"Software is a tool to be used by humans to accomplish something. It is NOT a tool used by computers to accomplish something."

When you step back and think about it, it seems obvious. I buy and use software because I need to accomplish something (editing photos, paying bills, communicating with friends) in a way that is easier than the way I used to do it. The last thing I want is to feel like I am driven by what the software wants from me.

If a person said, "write your phone number down for me" and I wrote 555.555.5555, (555) 5555555 or 555 555-5555 then they would have no problem understanding that. If they said to me that when they think of phone numbers, they think of the format (555) 555-5555 and then asked me to write it in that format I would laugh and not expect to actually have to do it. I don't think it is asking too much of the software developer to implement that kind of logic. Some human-like logic is hard to implement obviously but some isn't. An when it is done, it can have a huge impact on the opinion a user will have of your software.

Thursday, December 6, 2007

Worst UI Ever? - Links

First of all, let me say that I love Ebay. How else would I be able to sell my extra Hannah Montana tickets? However, occassionally I find myself asking "huh?" Take this list of links for example:


What do you think the difference between Seller's Guide, Seller Central and Seller Tools is? I clicked on each of them looking for information about the Buy it Now option. I couldn't find any information on any of the resulting pages easily. Eventually I found my way back to the Seller's Guide, which is apparently the code name for Seller's Help, and found it by searching. The first time I was on the Seller's Guide page, I completely overlooked the search box since I had just done a search on the previous screen in the main search box which apparently only searches items. When searching for Buy it Now, I received, as you might expect, over 2000 products.


Here's the problem. The links all sound like the same thing based on their names. They could be slightly improved by adding tooltips assuming it is possible to articulate the difference in 3 to 10 words. To add to the problem, even after visiting those pages, I am still not sure what the difference between Seller Central and Seller Tools is.


The bottom line is that when you decide to add one more link to a menu, it is important to make sure it makes sense in the context off all the other links. All by themselves, each would make perfect sense, but when put together the problem becomes apparent.

Monday, November 12, 2007

Worst UI Ever? - Date Entry

Those of you who have read my other "Worst UI Ever" posts may recognize that this one comes from the same application as my last post on the topic. I don't mean to pick on this one application. Its just that I use it so frequently that I notice these problems.




Here's a screen shot of what happens when you try to submit an expense report with dates entered in the "wrong" format. Why's "wrong" in quotes? The real questions is "wrong to who?" From a system perspective, a developer would likely thing that all dates should be entered in a particular format. Sounds familiar? The reality is though, that the "right" format for date entry is the one that the user things is correct. If I, for example, live in the US then I might be used to something like 11/12/2007. However in another part of the world I might use 12/11/2007. So how should any system handle this since both of those could be interpreted as valid dates, albeit incorrect ones. If the system doesn't know what format the user wants to use then it is ambiguous.

Just Getting Picky
So what is a designer or developer to do? Enter the "Date Picker" control. This little gem has been the solution to this problem for quite a while. So no more problems with date formats because now you don't enter one at all, you simply "pick" one. If you are reading some sarcasm in the tone of this, you are not imagining it.

The date picker control is a handy little calendar that pops up when you try to enter a date into an input. The calendar, usually defaults to the current month. It has to default to something, so why not? The problem is that thought really needs to be put into the use of these things. Imagine for a moment that you are entering your birthdate and the calendar defaults to this month. Unless you were "born yesterday" this will probably cause a lot of extra navigation to enter the date that is really on the tip of your tounge, or fingers. If only you could just type it in.

Does it ever make sense to use a date picker? Of course. For example, in a scheduling application where people might be interested in setting up a meeting for next thursday, it might be nice to allow the user to choose that date rather than enter it. The difference is in how the user thinks of the particular date in mind. If the user thinks "I was born on February 1, 1970" then that is different than a user thinking "Two weeks from this past monday". This difference in mental model, should drive a difference in the UI.

So we have dispensed with the date picker for the application in question. Luckily, the application actually allows date entry as well as date picking. However, in the screenshot, the date entry is what caused my "error". The problem is really that the application doesn't do a good job of accepting the format I intended to enter. It also doesn't even do a good job of telling me what format it expects. If you look in the screenshot, it is displayed as a TIP. Now to me, a tip would be something helpful but not crucial to me using the application. It turns out that the format really was crucial given that my mistake lead to 4 separate error messages indicating that the format was incorrect, without once suggesting the format it expected.

The one thing this application does do well is when it gives you the suggested format, it shows you today's date. I have seen many applications which do something like this "(MM/DD/YYYY)" This format is very familiar to developers but would all your typical users understand this. I have even seen some that say "DD-MON-YYYY". Clearly the MON means moth, but why should users have to decode that. Showing "05-Nov-2007" (It was November 5th when I captured the screen) is much better since the context of the date is at least in the user's frame of mind. Most people at least know what month and year they are currently in.

The Bottom Line

  • If at all possible let the user enter the date in the format they want
  • If you can't, give the user a clear indication of the expected format using the current date as the example
  • Use date pickers for dates that user's don't know by date such as "next tuesday"
  • Don't tell the user they made an error if the software can't figure out what they meant. It is never a good idea to tell the user that what they enterd as "11/05/2007" is an "invalid" date when it obviously is.

Monday, September 10, 2007

Worst UI Ever? - Error Messages

Here is another one for the Worst UI Ever series. This is from an application for a a very big software company's time tracking application. These kinds of things are part of the reason I developed Klok. You get this message when you select a project for your timesheet, but don't enter all any timefor that line item. To me, this doesn't even seem like an error. The system can easily ignore line items that have no hours.

At first glance, the message has to be one of the most confusing I have ever read. Click to enlarge it.

"You have entered time information without associating any time with that information. Enter time for this information, or remove it"...ummm....huh?

If you read it a couple of times, it makes sense. But you have to make an assumption about what "information" means. The user shouldn't have to assume or guess anything. If that this is an error that the system can't handle, would it have been impossible to say "You have not entered any time for Project X. Enter your hours or remove Project X from your timesheet". They even could have made "remove Project X" a link making it simpler for the user.

I find these types of issues all over the place. Usually they are due to laziness of the designers/developers or lack of commitment to the end user by companies in general. To a product owner this might not seem like a big deal. However, imagine a user getting this error the first time they use your software. What kind of first impression is that?

The number one thing to remember is that software is supposed to help people do what they need to do. It isn't meant to help computers do what they need to do.

Friday, August 31, 2007

Worst UI Ever? - Validation errors

Here's a little comic relief for you. First of all let me say, I didn't make this up. This is a screenshot from the website of a big, well-established company's website. I won't reveal the name of the site in order to protect the innocent.

This started out as a typical registration form. The label (Name, Address, etc) was inside the input box which conserved space . When you focus on the field, the label disappears so you can enter your value. However it didn't specify which fields were required. So, since I don't like registering, I just tabbed through all the fields without filling out anything. This is what it showed.

Nice. Now I know that all the fields are required... Now what goes in each field again? The worst part, refreshing the screen doesn't bring the labels back. Nor does submitting it. Now in the site's creators defense, after a little refreshing and clicking in and out of the fields, I was able to get it to show the labels again. But would most users?

Do your users a favor and don't do this.