Often when I am writing software I design the user interface first, or at least separately, from the rest of the code. Jeff Atwood describes UI First software development on his blog:
Of course, UI is hard, far harder than coding for developers. It’s tempting to skip the tough part and do what comes naturally — start banging away in a code window with no real thought given to how the user will interact with the features you’re building.
Remember, to the end user, the interface is the application. Doesn’t it make sense to think about that before firing up the compiler?
I found this particularly interesting and timely in light of the topic being the brunt of a recent April fool’s day joke on The Daily WTF. When I read that post, I actually found it surprising that programmers would think it satirical to consider designing the user interface first. Of course, the rest of the post gets a bit more crazy but I won’t touch that part.
Jeff talks more about the benefits of paper prototyping:
Paper prototypes are usually pitched in terms of doing low-fi usability studies, and rightly so. But I find a paper prototype tremendously helpful even if I’m the only one that ever sees it. I need to create an image in my mind of what I’m building, as it will be seen by the world, before I start pouring the concrete to make it real.
Figuring out the GUI definitely helps you get into the guts of what you need to accomplish in the end, and so it is definitely a helpful task. I think there is another tremendous benefit that to this however: developing a nice user interface.
Okay, so this seems like a less than earth-shattering revelation. Many programmers totally miss the mark on this though. Consider the traditional approach: write a command-line app or hardcode everything in, get the code working, and then write a GUI on top of it to expose to the end user. By doing this, you automatically box yourself into writing a GUI based on your underlying API or database layout.
I think there is a big benefit to taking a step back, totally forgetting about all the underlying API stuff you did, and think up a design for the best possible UI that you can for the problem you’re trying to solve. Pretend you’ll be the one using it every day for the rest of your life.
What you come up with may be totally incompatible with your API; that is okay. In fact, it may even point out fundamental flaws with the way you’ve done things (hence the benefit of the initial paper prototype..). It may work exactly with your code. It may require a translation layer of sorts, to convert what the underlying code is doing to how things are represented in the UI. It may also require compromises in the UI to be able to write a translation layer. All of these are good outcomes though because the end result is you generally have a much nicer UI than you would get if you just stick a pretty face on the raw API.
To use a simple example, consider the Google MyMaps interface. Underneath, the database is storing locations using their latitude and longitude, and assigning a name to them. The ultimate simple interface to this would be:
Of course, what Google actually did makes much more sense – even though it involves a whole lot of code that translates mouse clicks on the screen into map pixel offsets, and then those into latitude/longitude:
In a lot of situations, the success of your software can come down to how nice and/or easy to use the GUI is, regardless of how powerful it is underneath (I’m sure you can think up many examples of this .. perhaps in say, the operating system world). Whether or not you actually design the UI first is inconsequential – ultimately you need to design the UI for the end users, not for the API.
Next thing I did was verify it was in fact the power button at fault. Pressing it manually did the same as the plastic button above (which just pushed down on this) – which is to say, nothing. Using a probe to manually connect the pins instantly turned it on every time, and there was nothing visibly wrong with the solder connections, confirming it really was the switch that was defective.
I looked around for a similar button to use, or something I could jam in that would work, but didn’t really have anything suitable. I decided instead to re-purpose the mute button (hopefully he will at least change the power settings to put it in suspend, rather than turn off.. I probably should have suggested that in retrospect). It had a ribbon cable connecting it to the motherboard, and shared a common ground with the power button, so I just had to route it over to the power button. After finding the correct wire with an ohm meter, I pulled it out from the ribbon.
Finally, some soldering and that’s it. The mute button now functions as power, and the old power button does nothing. I haven’t yet heard how many times he’s accidentally turned off the system..
