Posts Tagged ‘mechanical’

Three Most Painful GUI Challenges

Monday, January 19th, 2009

I have been thinking recently about which parts of GUI design are truly the most difficult. The programming side of it has gotten easier over the years. Faster processors mean that the programmer does not have to spend endless hours making his bitmap-rendering algorithm a little faster on the draw. Graphics libraries are widely ported, so most programmers do not have to spend too long pouring over the data sheets. These libraries make constructing the higher level screens fairly straightforward, unless you are looking for something unique.

So the hard stuff is not writing the software to put something on the screen, but actually deciding what it is that you want to put there. In this piece I will identify three of the areas which I feel are the most challenging – unfortunately I do not have any answers to challenges, but at least if you also feel the pain in these sensitive areas, you will know that you are not alone.

The first pain that I feel in this area is the pain of backward compatibility. In most projects, the product being developed has some precedent in the market. The products already out there have names for the concepts you are dealing with, and the users have a certain mental model of how they believe products in this category behave. This may be a blessing if you can simply copy those concepts that are already established, but it leads to endless internal debates on naming if you want to come up with something new, either because the new device does not exactly match what was in the field, or because a better name or mental model is now available. Driving a change to a better mental mode or naming system has to be weighed against causing current users to learn something new when they purchase your product.

There are far better keyboard layouts than the QWERTY style, but none has caught on because so many people would have to learn a new keyboard – and people are far too busy to learn something new, unless the payback is many, many multiples of the time spent learning.

The question ‘Do we make it the same as the products out there, or try to achieve something better?’ is often the hardest one to answer when establishing user interface requirements.

The next tricky bit is the mechanical design. I know it is a GUI and, in theory, you can draw whatever is allowed by the resolution and color palette of the screen and graphics controller, but the GUI is hugly influenced by the small set of buttons and/or knobs that are placed around it. In every project I work on I end up frustrated that we left out some hard buttons, or left in some hard buttons for features that would have more suited to soft graphical buttons. Early prototyping should resolve these issues, but somehow the prototyping is never extensive enough, or early enough, or the requirements just change too much after the mechanical design has been set in stone (or in plastic tooling).

See my latest ESD article: ‘Mechanical vs. digital: a GUI isn’t always the answer’ available at http://www.embedded.com/design/212700448 for more discussion on the pros and cons of mechanical design in a GUI environment.

After those two issues have left my head throbbing, the final ache comes from featuritis. No matter how large the ‘Keep it Simple’ sign hanging in the team’s coffee area, there are always too many Yes men and not enough No men, and the product always has everything and the kitchen sink thrown at it. Almost every project I work on would benefit hugely from having someone take an axe to the feature set and get rid of the features that will never be used by 90% of users. Out with the feature that was included because some competitor has it, but no one ever uses it. Out with the feature that is some team member’ pet project, but no on else can see any use in it.

As diligent engineers we all want to say ‘Yes we can do that – it will only take a few hours’, but we really need to say consider whether we should. Deciding whether a new feature will provide real value to the customer or is just a case of showing off what the technology can do is often a difficult call. Sometimes you have to rely on the marketing guys to know their market well. Sometimes you have to get out of the office and find real users in the wild.