Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The Gaui (Rhymes with Maui) Test Heuristic

March 24th, 2008 · 3 Comments

One of the exercises in the Exploratory Testing in Practice course Mike and I just delivered was creating heuristics. One of the students, who goes by freak3dot online, came up with the Gaui heuristic and was kind enough to write up an explanation for TechDarkSide.com. Here is Freak3dot’s explanation:

A user interface so bad it hurts – GAUI

It all started when I had an opportunity to look at a new system that was in testing at my company. I notice quickly that I hated the User Interface but I didn’t know why. I had to find my oracle. Although at the time, I didn’t know that they had a nice buzzword. This
prompted me to begin to research what makes a good User Interface.

I don’t know what websites I visited that day, but I learned that what was bothering me was the system did not match up with my User Expectations. More importantly, those user expectations came from using common commercial software made by the big manufactures.

When software does not match up to their expectations, it frustrates users. Think of software you are frustrated with and then see if this might be why.

From that point on, I began looking more at the User Interface of the software I tested. I didn’t realize it was a heuristic either. It was just something I wanted to see in the software I tested. Later when I learned about heuristics and was asked to define one that I use, GAUI was born and I gave it a cool name. GAUI is Generally Accepted User Interface. I have to admit, for some brief moment, the GAAP thing from accounting may have popped into my head to contribute to the name.

When learning a new concept in programming, I couldn’t do it without some examples. So, here are some examples of GAUI in practice:

  • The icons at the top of word processors. There is a consistency in the icons on word processors. ABC check is spell check. Dots and lines is bulleted lists. So, your first example is the expectation you have about the icons on the tool bar. Do the buttons do what you expect when you click them?
  • The next thing is the menus. Are the items you are looking for under the appropriate menus? This is probably more of a problem than most things. Can you find the options or preferences in most of your programs? It always seems to be under a different menu for me.
  • In the particular web-page I was testing:

  • It had a pop-up div for editing a line of the search results. Why wasn’t this div overlayed on the line of the search result to create an in line editing effect?
  • When the pop-up divs were shown, the page did not scroll and you didn’t see the whole thing when it popped up.
  • The decimal points on the numbers of the results were not lined up. (This is probably the only thing they actually did fix.)
  • The biggest thing was the pages were cluttered, with and entry section at the top, a search section in the middle, and a results section at the bottom. What I might consider a better User Interface would have been to only show the search to begin with. Then show the results after the search. If they need to add an entry, a pop-up div (maybe like in-line editing) could be used.
  • In conclusion, we have a set of User Expectations when we use an application. That is my GAUI.

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Exploratory Testing

    3 responses so far ↓

    Leave a Comment