It has happened so many times already. I come across with a shockingly deplorable excuse of an user interface and want to take a screen shot of it. So I open the Start menu, glance the list of recently used programs and select the Microsoft Office Picture Manager from the list to start editing the screen shot... only to realize moment later that I have opened PowerPoint instead. Problem is that the icons of both PowerPoint and Picture Manager are very close to each other when compared for color and style. Both have sort of reddish icon with pictorial elements in them, while all other Office programs icons have very distinct colors and styles. Only when you look closer you can see that icons have different color (orangeish red vs. red) and different themes (slide vs. drawing), while having similar elements (like circles) in similar positions. And the fact that the names of the both programs start identically ("Microsoft Office P...") doesn't really help either. So when you are designing an icon for program or function, please make sure that every icon has a distinct visual message from other icons and are easily recognizable. And remember that when designing icons "less is more".
Showing posts with label user interface. Show all posts
Showing posts with label user interface. Show all posts
Where is english?
Recently I encountered this language choosing dialog and at first it seemed quite puzzling because for a while I thought there were no selection for English. Only when I stopped glancing those flags and read the texts I found English was the first of the selections, which makes sense, but why do they use flag of Canada to mark English language? Of course English is used in Canada, but usually English as a language is marked with either UK or US flags or their combination. And if they thought UK and US flags were too predictable and easy for the users, then why they chose Canada and not Australia, New Zealand or Nauru? Maybe the designer was from Canada?
Labels:
usability,
user interface
Reporting errors in error reporting
When we look at the form itself, there are some additional problems. What time should I input into the "Timestamp" field? Is it the time now or the time of the error occurred? Do I put date, time or both? In what format do I input the time? In 24 hour or 12 hour format (AM/PM)? In what timezone? Can I put the time according to my timezone or do I have to try to find somewhere what timezone system uses and convert the time to that? If I have to put date too is ISO 8601 standard time (YYYY-MM-DD) ok or should I use Unix time (seconds since new year of 1970)? Does any of this matter when reporting the error?
The user faces another classical user interface problem when trying to "Describe what you were doing when you received this bX-code". The field name is long but field itself is the same size as every other field, i.e. too short for writing a long description what the user was doing when receiving this code. User interface input field sizes should be based on the amount of input the user wants to make into that particular field. E.g. field for postal code can (and usually should) be relatively short but field for street address should be much longer because street addresses are usually much longer than postal codes. Fortunately for the users writing a short story about what were they doing when error happened, these fields allow more input than their length would suggest. Or maybe the form just cuts the description after first 21 characters and rest disappears into oblivion, who knows. And when we are at it, I want to give a free advice for all those developers who force me to select my home state in their web forms: there is life also outside the States and it would be really nice if you would recognize that if you want me to buy something from you.
Then user has to "Select the browser you were using" so that shouldn't be a... wait a minute, it says "select" even though the user interface element used here is not a drop-down list but an input field. Tsk-tsk. Of course actually having a drop-down list would make things much more easier since now the users have to worry if just generic browser name is enough or should they add also the version number.
Labels:
error message,
user interface
Return of the Captain Obvious
"Catastrophic failure" - An example of an error message that gets an immediate nomination to categories "useless error messages" and "return of the Captain Obvious". What is the purpose of an error message? To tell the user: A) what happened, B) why it happened, C) how the user can safely recover from this error situation and D) how to prevent such errors from happening in the future. So thanks for telling me that a catastrophic failure happened, I wouldn't had guessed it when everything stopped working...
Labels:
error message,
usability,
user interface
What am I doing?
"Send Message Error - Sending of message failed" Another example of error message that first sounds very easy to understand and actually provides more helpful information than your average "there is an error" - error message. This time the error message provides more details about reason of this error (unable to open the temporary file) and gives an advice what to do (check your 'Temporary Directory' settings). So what could possibly be wrong about it? Well again the problem lies in the context where this error message appeared. In this case user was importing some mail to Thunderbird when this error message appeared, which becomes quite apparent considering the clues like "Import Wizard", "Importing..." and "The following items are currently being imported...". So why is this error message talking about sending a message when user is actually importing messages? Is the error message just confusing the user by using different terminology (importing vs. sending) or is it just stock error message that is used instead of non-existing import error message? Is the helpful information in the error message just a red herring that will send users to change their temporary file settings in vain?
Labels:
error message,
usability,
user interface
Different worlds, different terminology
"Error: Your community has been deleted" Doesn't this error message sound like a very straightforward and easy to understand? What could possibly be wrong about it? Well, it is easier to understand the problem about this error message that has caused some users to scratch their heads wondering what is going on when you consider the context where this message was displayed. Was it some community based information system? Some kind of Facebook application or group? No, it was an information system for booking travels online. From your average users point of view booking a travel has very little to do with communities or being member of some community. So what exactly is this "your community" that has been deleted and why should its deletion be a problem when all you want to do is to book a trip? That being the case, what exactly is this "community" that the error message is talking about? Nobody but the designers of this system knows and they surely are not telling.
Labels:
designer,
error message,
user,
user interface
Usability Spot - it is all about usability
Welcome to Usability Spot - a blog discussing all things related to usability and ease (or more often than not - difficulty) of use. Topics can be usability related research papers, latest news about novel user interfaces, insightful blog articles or dreadful user interfaces - it is all about usability.
Labels:
usability,
user interface
Subscribe to:
Posts (Atom)




