We all talk about usability: How to focus on how the system fits the user and not the user fitting he system.
What Memi is talking about is Understandability. It’s not that the user has to be able to use the system, he has to understand it. Memi makes a point in saying that no technical terms should enter the user’s domain.

The point mentioned was using the error message “The date format is incorrect. Enter valid format: dd/mm/yyyy”.
I’m sure that I’m not telling you anything new here, but there are at least three ways out of this without a scratch:

  1. You separate the field to three fields and write day, month and year for each. Maybe even combo boxes.
  2. You create a field that is a formatted text box (adding slashes automatically, etc).
  3. You put a big-ass explanation of what is ‘dd/mm/yyyy’ somewhere close to the field (or somewhere in the manual).

None of the said solutions are easy to implement or look nice (unless you’re a UI whiz).

Memi calls it “The newbie syndrome” but I know way too many experienced developers who don’t really care much for usability, never mind the understandability, of their work.
In my opinion, thinking in terms of usability starts from the lowest ranks, the developers, and not the designers.


4 thoughts on “Understandability

  1. It’s amazing to hear users ask what dd/mm/yyyy stands for.

    I had someone who was trying to enter a date on some site, and it asked for dd-mm-yyyy and she entered it as dd/mm/yyyy and the site kept refusing. Those are things you should think of when creating your UI (and validation logic), don’t make it so hard on the user :p

    (I always pick the three combo boxes option, it’s the easiest to implement for my brain, and i’ve still have to meet the first user who fails to select a date from dropdown boxes ;))

  2. IMO, understandability is a subset of usability (and not vice versa! I met users who knew how to use the application, but did not understand fully what it can do, but I’m yet to see a user who understands an appllication he can’t use).
    In your proposed solutions to this problem you didn’t mention the solution I find most elegant and usable: open mini-calendar from which the user can select easily the year, month and day of the desired day. This is the solution we implemented in our frameworks (for .NET, ASP and Java) and it proves itself.
    In my said review, I proposed your 1 or 3 solutions. The developers of this project couldn’t stand something as complicated as self-formatting textbox.

    I fully agree that the problem exists with many experienced developers. However, with newbies this problem comes "out of the box". It is not a result of bad programming education, but a result of a young programmer instincts, therefore I call it a "syndrome". For experienced developers, I would change the word to "failure".

  3. Maybe the application could try to figure out what the user meant. If they typed in dd-mm-yyyy, and the app expected mm-dd-yyyy, the user could be prompted, "did you mean x?" Now, this doesn’t work everytime since 04-05-2004 could be one of two acceptable values. In this case, the app should at least show the user what it thought you typed (APR 05, 2004) next to the textbox. Yes, it does waste some space. But, the user sees that they really meant MAY 04, 2004 and can see what they need to do to fix it.

    I really don’t like the combobox solution for a web app. I hate having to scroll to find the 27th of any month, let alone 1997 in a year list that starts at 1901. Let me type in the date in whatever format I choose. The server has more than enough ability to try and decypher it. Or, ask me to verify a potential mistake.

  4. Martin, this is one of the ways I rather not take.
    Not only is it a complicated business trying to figure out what the user wrote, but you have to try and also correct him.
    In WinForms applications, this might be acceptable, if you feel like the need is strong and you would never want to let the user have some sort of richer UI for inputting (for lack of ability to use it, damage to overall application appearance, etc.).
    In web applications, this would mean that the logic was either on the client side or the server side. Writing it on the client side would be hard work (unless you can handle JavaScript like the best of them) and would make the client heavier. Writing it on the server side is would mean that the user would usually have to post the form at least twice, giving that they might not be aware or just not care that there are proper formatting rules.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s