EE Times EDN DataSheets.com Design News EBN Test & Measurement World Embedded.com TechOnline Planet Analog
Events ▼
UBM Electronics

Contact Us • Subscribe to Newsletters

MurphysLaw

's profile
image
Design & Development Engineering
Niall Murphy is a contributing editor on Embedded.com. He wrote the column Murphy's Law, about graphic user interface design, for Embedded Systems Programming magazine (most of which are posted here www.panelsoft.com/murphyslaw/index.htm and here www.eetimes.com/electronics-blogs/4210709/Murphy-s-Law. As a software engineer, Niall writes about the practice of writing software, particularly user interface software design and usability. He is the author of book Front Panel and runs an independent consultancy. For more information about him, go to www.panelsoft.com .

MurphysLaw

's contributions
Articles
Comments
Discussions

    • Niall looks at the changes in user-interface technology over the past few years and makes a few predictions about application upgrade and cloud connectivity.

    • Niall Murphy writes about how to design sane and user-friendly GUIs in embedded systems. The column appeared in Embedded Systems Programming magazine.

    • GUI testing traditionally meant finding the most appropriate access point to inject test cases. The challenge, however, is in making the GUI tests repeatable. Here's a homegrown framework that allows test input to be managed, replacing manual test cases.

    • User interface design is not always an either/or decision.

    • It's hard enough to design a user interface for a standalone product. But when you have two devices that must work in concert, the level of difficulty multiplies.

    • Designing user interfaces means striking a tricky balance between being helpful, being too helpful, or getting in the way. Here are some examples to guide you through these treacherous waters.

    • The main point of this article is to show how safety is a system-wide property that must be addressed at the requirements level to ensure that you design the right system. The design of the user interactions is an area where safety improvements can be achieved, often at little cost, but with widespread benefits.

    • Every program uses RAM, but the ways in which that memory is divided out among the needy parts of the system varies widely. This paper surveys the options available. The mechanisms include statically allocating all memory, using one or more stacks, and using one or more heaps. In particular this paper will examine how the heap is implemented, and how that implementation an be modified to suit the needs of an embedded system.

    • A leak is always a bug in the application. A small leak may be acceptable in a desktop application that will exit at some point, since an exiting process returns all memory to the operating system. But in a long running embedded system, it is often necessary to guarantee that absolutely no leaks exist-a non-trivial challenge. In this paper, I am going to discuss puddle hunting and leak location.

    • This paper presents ten common and annoying mistakes designers make when the users needs are not considered carefully enough during the design of embedded products. Fixing these problems is often straightforward if spotted in time, so watch out for them in your own designs.

    • The DVD designers seem to have a high level of disregard for what customers actually want. Here is a snip from one of my usability articles (full piece available at http://www.embedded.com/columns/technicalinsights/172900676. DVDs and DVD players provide an interface that shows contemptuous disregard for users' time. These devices sometimes force the user to watch an unwanted movie trailer or copyright notice. While the legal eagles might suggest that the copyright notice is important, I've never read a book that wouldn't allow me to turn the page until I had read the copyright page for ten seconds, and I certainly would not appreciate it if I had to look at it every time I picked up the book. Treating these fairly dubious legal or advertising requirements as more important than your user's time will always insult your user, so think carefully before forcing these "features" onto your customers. As a parent I often want to turn on a film for the kids and then return to cooking dinner. However, the interface forces me to wade through a frustrating ordeal when I simply want to press Play and have no further interaction with the device. Ironically, old-fashioned video tapes did allow me to press Play once, and required no further interaction. When the DVD menu is selected it takes several seconds to appear to allow some action sequence to set the scene. I'm sure that the designers thought this would be visually impressive, but it reduces the user's control and forces the timing priorities of the device onto the user. While the fast forward button will sometimes allow you to skip these sequences, only a minority of users will discover that feature. The lesson here is to always assume that the user is busy and that extra time waiting for the device to allow the user to continue is rarely appreciated no matter how important or impressive the information presented during the delay. A case could be made that if I have set aside two hours to watch a movie then an extra ten seconds waiting for a menu to appear is not a significant cost in time. That argument misses the whole point about who is in control and who is setting the pace. It doesn't matter how much or little time is lost or gained. The important thing is that the user feels that he is the one setting the pace, and that he is the one in control. regards, Niall Murphy