I’ve decided to read a number of books over the Christmas period, one of the areas that interests me is user interface design, especially for embedded systems, there are some really, really bad user interfaces out there, and also some good examples of user interfaces. Some of the best UI’s are those that don’t require you to learn anything, or go delving around inside a user guide – for example, I have a Portable Media Center, the UI is extremely simple to use (actually, I don’t even remember whether the device came with a manual, but I’m sure there was one).

More consumer devices (and devices that are consumer facing) are shipping with an embedded operating system, think about set top boxes, gaming machines, cell phones, ATM’s, Travel Kiosks (at airports, train stations etc…). In many cases the user interface is designed by the engineering team, therefore designed from the code-base up rather than the user down – the user interface makes total sense to the development team, and even the testers (because they are so close to the development process they know how the UI is going to work). But what about the end user? – User Interface, even the name implies that the interface should be designed for the user. The user process should be designed and tested first, once the flow of the application has been locked (and user tested) then the coding process can get started – in fact, when I was developing applicaitons for CPM/80 I would always start with the UI (much to my development managers annoyance), once I had the UI up and running I could then concentrate on putting the code ‘behind’ the UI – this is somewhat similar to Visual Studio application development using managed languages like C# or VB – you start with the UI, then ‘code behind’ the controls – this makes it really easy to prototype your application, get sign-off from the customer, and then code the application.

Which reminds me… when I was at college we were programming Pascal and Assembler on the college mainframe, our programming language lecturer was strict on getting flow charts, code listings (with comments), and the output from sample runs of the application. At that time I couldn’t be bothered to draw out the flow charts, so would always code up the application at the end of the days lecture, run the program to prove that I got the results I was expecting, get the listing, then work on the flow chart – Hey! – at least everything matched, right ?

I’m sure you have some favorite UI Goofs you would like to share, so go ahead and drop a comment.

– Mike