Embedded Systems UI

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

Comments (5)

  1. Dan McCarty says:

    "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)."

    The lack of a manual doesn’t necessarily imply that the user interface is good. Product documentation across the board is at an all-time low. Even on-line manuals suck these days. HTMLHelp is far inferior to the WinHelp it replaced. As a reader of manuals, I think that that’s a shame.

    Anyway, I suppose that I’m slightly off-topic. I do have a great picture of a terrible UI. Is there anywhere for me to post it?

  2. Mike says:

    I totally agree that a lack of manual doesn’t imply that a device has a great UI, I was suggesting that the UI on the PMC was good enough to use without needing a manual.

    I also like to use books as reference, in fact, when I started at Microsoft I had the Windows SDK documentation in four books, that was excellent (I still have them somewhere). The one good thing about having documentation online is that I’m using multimon for my desktop PC, so I can have the documentation open on one screen, the development tool open on another, and my application running on the third screen…

    – Mike

  3. Roberto Bernardo says:

    I totally disagree with you. I think that the user interface should be totally independant (or at least, as independant as possible) from the application core.

    Here comes my explanation: when you design your UI you have to meet the "user" needs; when you develop you app’s core you have to fulfill the specifications. The relationship between two worlds must be very well defined (with very well known interfaces) so each part has its own independence.

    From my point of view, the user interface is so related to the user; that maybe you should change it completely, for example, when selling your product in another country.

    This is the idea, two goals:

    – make the app user friendly

    – fulfill the specifications without depending on how the user interface is going to give you the data

    Best regards,

    – Rober

  4. Guido says:

    What books are you going to read on Embedded UIs?

  5. Mike says:

    One of the books I’m reading at the moment is called "The Humane Interface" – http://www.amazon.com/exec/obidos/tg/detail/-/0201379376/102-9966251-9214500?v=glance

    One thing to bear in mind is that building a user interface for an embedded system shouldn’t be any different to building a user interface for a desktop PC – the same principles exist. And, in many cases embedded systems may be using a desktop (and I include Linux, MS-DOS, Windows 95/98/NT/XP/XPE/CE in the list) operating system with a stand alone application which is displayed to the user.

    – Mike

Skip to main content