MurphysLaw

image
Design&Development Engineering

Biography has not been added

MurphysLaw

's contributions
Articles
Comments
    • 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.

    • 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.

    • Does the GUI you're designing scold and scoff at those idiot users or does it politely guide the gentle users to a civilized, pleasant interaction with technology? The author offers some tips that may keep your customers from kicking your invention and keep 'em coming back for more.

    • Software engineers should not fall into the trap of assuming the general population is as comfortable with modes as the typical engineer is.

    • The text our applications display to the user has a huge effect on usability and so deserves your close scrutiny during development.

    • Are your ears burning? It could be a user cursing you and your system. Here are some tips for building user-friendly systems.

    • The engineers who implement user interfaces aren't always the best ones to design it. Good UI design is a specialty unto itself, with its own rules and guidelines. This month our resident UI specialist describes how to design user interfaces that are actually useable.

    • From the puerile to the predatory, hacking has invaded embedded systems. Can we make the world safe for our devices?

    • Variables often pick up the wrong value during initializations, producing hard-to-find bugs. Here are tips for getting the numbers right.

    • A version control system is indispensable for large development teams, and even on small projects it offers advantages.

    • Take a break from slaving at your computer and read. Here are some books that just might reinspire your engineering mind.

    • How do we reduce the amount of cabling in cars as we install more complex embedded systems? A bus architecture is the answer.

    • If your embedded system doesn't need networking and storage, porting Linux to your hardware may not be worth the effort.

    • Distributed systems require protocols for communication between devices. CAN and SPI are two of the most common.

    • Should you integrate a GUI into an existing design by adding a second processor or upgrading the existing one? Here are some options.

    • Adding shades of color and the illusion of illumination can bring a displayed object to life. Here's how to achieve the desired effect.

    • Embedded GUIs are growing more elaborate day by day. Developers now have to contend with such arcana as a color palette.

    • Niall delves deeper into the benefits of prototyping a user interface on a PC. He shares pointers on graphics, gotchas, and event scheduling.

    • A wealth of resources are available to simulate desktop interfaces. Niall shares a low-cost way to leverage them for embedded systems.

    • Proper skills training takes more than a set of slides and a multiple choice test. Companies that don't provide it are cheating themselves.

    • Niall's harsh words about ISO 9000 stirred up proponents and opponents alike. This month, he throws more fuel on the fire.

    • The best way to detect memory leaks is to use a smarter memory allocator. That turns out to be easier than you might think.

    • Can quality be generalized across multiple industries? ISO 9000 and its promoters claim it can. Here's a look at the ubiquitous standard.

    • Good software engineers don't always make good interface designers. Sometimes they trust the user too much.

    • Short text messages, like those becoming a common feature of cell phones, may be the wave of the future. Embedded command and control may never be the same.

    • Ever stared blankly at a panel of buttons and dials, wondering what controls which function? Apparently, so has Niall, and he's tired of it. This month, a laundry list of user interface design failures.

    • Niall makes the case for, but cautions about the drawbacks of, object-oriented programming. While it increases productivity, your software may end up being less robust.

    • User interfaces are always less usable when they're served up via HTTP. But there are ways of improving the user's experience.

    • Data formats change over time. To make upgrades easier, track these changes with version numbers.

    • Niall laments the inconvenience of forgetful devices and explores a variety of ways to store data more permanently.

    • Niall continues to assert the usefulness of assertions, but this month, he shows you how to make your own.

    • Not speaking Japanese is just one of the obstacles between you and a successful translation.

    • Most of us don't speak very many human languages. But sometimes the software we write needs to.

    • When it comes to safety-critical applications, software is not always your biggest worry. Sometimes it's the user.

    • The key to preventing software catastrophe, says new columnist Niall Murphy, is out-thinking an imaginary malicious programmer.

    • The placement of knobs, buttons, and switches is as essential to the making of a good product as the firmware. This article illustrates the delicate relationship between the two.

    • To keep a watchdog timer from resetting your system, you've got to kick it regularly. But that's not all there is to watchdog science. We will examine the use and testing of a watchdog, as well as the integration of a watchdog into a multitasking environment.

    • Interesting article, but I am also curious about the decision process when choosing Android for an embedded application. Like one of the posters to your previous blog on the topic, it seems to me that unless you want to let third parties run applications on your platform - which you point out is tricky anyway - then I am not sure I see the advantage. If you just want user interface objects, it would be easier to use Qt or similar. Maybe if you want the user to be able to easily manipulate the file system for storage, but most embedded systems desperately want to hide that from the user. Or maybe if the user needs to manipulate pictures or music, then maybe Android is a better starting point. Or maybe I am missing some other advantage of having an application framework in an embedded environment.

    • I watched the demo, and my first thought was that this tool could easily be adopted to on-line code reviews. The initial wave would be the source, and then comments could be added at any point in the source. If I change a bit of code to show how I think it should be done. The playback feature would allow another reader to see what the code was before I made my change. They showed a lot of plug-ins (did they call them gadgets?) One of these could allow a way to link the message to the real file in a code editor (or maybe link to a source code control repository) so the author could hop back and forth between the wave and the source, with possibly a way of selecting a piece of the text in the wave and with one click "make this into a comment in the code" I think something like this will convert engineers faster than embedded video and ability to play games inside the wave. But man, it is still a cool demo.

    • 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