Modeling Non-computer Gadgets with a Computer

Take a look Figure 2.1. This is an example of a gadget modeled on the computer. The idea behind this gadget is to control the device it represents.

Figure 2.1: What do you think of this?

Not too bad, is it? Or is it bad?

The world of software has a huge division line right up the middle. On one side of the line is off-the-shelf software that targets masses of people. Off-the-shelf software has the one-size-fits-all mindset, where everybody can benefit from the same software. Most of the software people use, such as the Microsoft products, is off-the-shelf.

On the other side is software that is custom-built for a particular need. This is software used in-house by businesses, usually large corporations or manufacturing plants. Most of us rarely ever see the enormous volume of software out there that was custom-built. The fact that you’re reading this book implies that you work in the software field, and if so, chances are high that you’re working on such a project. Why? Because that’s where most of the programming jobs are. Only a small percentage of the programmers work on off-the-shelf software.

I once worked on a software package that did real-time data acquisition for the wireless telecom industry. I also worked on a software package that helped salespeople look up current prices for long-distance phone service. (Most of my work has been in the telecom field, quite by accident.) Neither of these two software packages was ever for sale. They were both done in-house, one for use by employees at the same company and the other for use by only certain other companies. Other similar packages might be created for hire by a software shop, but they are still done in-house.

These custom-built software packages sometimes have a good amount of visual modeling in them, where the computer screens show a visual rendering of what looks like some gadget, either directly or as an abstraction. For example, I once worked for a company that created large circuit breakers for factories; we had a program that drew out schematic symbols representing the circuit breakers, all within a bird’s-eye map of the factory right on the computer screen.

One example of this visual modeling that’s not custom-built is the calculator program that ships with many operating systems. The one for Windows is rather ubiquitous. (Did you know that this particular calculator program on Windows has an option that transforms it from a basic calculator into a scientific calculator? Just choose View Scientific.)

So my question for you to ponder is this: How useable and how easy to learn is a program that essentially draws a device on the screen? Certainly you can’t generalize and say all such programs are great, or all such programs stink, but I can at least draw out some guidelines for you to use when you’re considering building such a software package. Among these guidelines will be some ideas whether to even attempt such a thing: Should you really draw out a gadget on the screen, or is there some better way to do this?

The fundamental issue at hand here is metaphor versus idiom. The calculator drawing on the screen is sort of like a metaphor, although really it’s not a metaphor at all: It really is a calculator, not just a metaphor for one. (The file folder representing a directory on a hard drive is a metaphor.) Yet at the same time it does a wonderful job of drawing on some well-established idioms. Most beginners automatically know how to use the calculator program if they are familiar with the mouse and are familiar with using a real calculator device.

Therefore, when creating a program that draws a device on the screen, you want to make sure you don’t lose the simplicity of your idioms. In the sections that follow I show you how you can do this, regardless of whether your model will draw a picture of the device or not. As a preview, here are the problems with the program I created for Figure 2.1. (I’ll assume that this program is a virtual representation of four actual devices that the computer is hooked up to.)

• It’s not immediately clear from the interface whether you can only reboot and monitor the devices or if you actually control the devices by attempting to turn the knob images.

• Are those LEDs or buttons on the left of the devices? I think they’re LEDs but it’s not totally clear.

• If you can turn the knobs, using a drawing of a knob as I did would be rather difficult with a mouse. (A slider control is better, or at least a control that looks like a knob but that you move left and right and is, in fact, a slider.)

Really now. Are we actually benefiting by seeing a picture of the device?

Now here are some good things about the program:

• Apparently when you click on a device, you immediately see information about the device to the left. You don’t have to open a dialog box that stops the program just to see information.

• Although the program shows four devices, only one, which has a dark border around it, is displaying its properties to the left.

• The program has two levels of abstraction: One is for interacting with the program itself, and one is for interacting with the devices. I explain this in greater detail in the following sections.

My general feeling? Although there are three good points, my feeling is this program is pretty bad. Read on.

Defining the Scope of the Virtual Device

One of the problems people run into when they model a device is that they fail to lay out some of the purposes of the program they’re building. Here are some questions to ask yourself:

• If you have the device, why model it on the computer? (This is a good question especially if the computer weighs more than the device!)

• Are the users of your model familiar with the actual device?

• Are you simulating the device for training and educational purposes, meaning that the virtual device isn’t going to cause injury, damage, and death if used wrongly? (You may laugh, but I’m serious. Think of a flight simulator!)

• Does the actual device control something or does it perhaps read data from somewhere? If either of these is the case, then: Is the computer version going to simply control the device or will it behave as the device, alleviating the need for the actual device? (In most cases, the computer version controls the device, although in the case of the little calculator program the computer version actually acts as the device.)

Another way to look at these final two points is this: Is your software simply a management system?

A management system monitors the devices, making sure they are running and there aren’t any problems. But the management system doesn’t actually acquire any data that the devices use. For example, a telecommunications network would have several devices that handle the phone call routing. In the middle would be a management computer that monitors the devices and makes sure they are functioning. If any devices aren’t functioning, the management computer might notify some other devices of the problem so the other devices can pick up the additional load. But the management computer doesn’t receive any data about the phone calls and the work the devices are actually doing. Why? Because it doesn’t care about that information.

My experience is that people creating software such as this all too often skip these fundamental questions. Answer these questions up front and you will be a step ahead of the crowd.

Here’s another question: Will the computer be communicating directly with the devices or through various bridge devices?

Figure 2.2 shows an example of a setup where a central computer is controlling several devices. The computer sits in the middle managing the network of devices, and the devices all radiate outward from the central management computer.

Figure 2.2: The central computer controls several devices.

Figure 2.3 shows an alternate approach. In this case the central computer is still managing the devices, but only through bridges that are themselves management devices. The central computer interacts only with the bridge devices, which provide filtered information back to the central computer. This is common in telecom and electrical power management systems.

Figure 2.3: The central computer controls the devices through two bridges.

When you model a real-world device, you want to make sure that both you and the people requiring and using the software are in agreement on what the function of the software will be and what the answers to these questions are. Putting it this simply might seem trivial, but believe me, your users might be expecting something different from what they described! You want to build something they can use. Remember, our goal here is to build highly useable software.

Building the Virtual Interface

The virtual device on the computer will ultimately have two levels of interaction: One is where the user interacts with the device on the computer screen. The other is the usual Windows ways of interacting with the software itself. I call these two levels of interaction the device level and the software level, respectively.

But if you’re not sure what I mean by this, here’s a good example. If you develop for the Palm operating system, you have probably seen the Palm Emulator. This is a piece of software that runs on a Windows computer that looks like a Palm device and runs Palm software. It’s an emulator complete with an interpreter that reads and executes the Motorola assembly code in the Palm software. The idea is that when you’re writing software for the Palm, you can run it on your PC and test it and debug it without having to keep transferring the software to the device itself. (I do some Palm software development, and this tool is a lifesaver.)

The Palm emulator is a pretty good example of how to draw the interface while remaining true to both the device itself and the idioms of the Windows operating system. Take a look at Figure 2.4. This figure shows the Palm Emulator running a Sony Device skin. The picture looks almost shockingly like the real device, right down to the correct color for the metal. And the emulator functions like the device, too: If you click the little image that looks like a house, the screen switches to the list of applications in icon form, just like the real device. And if you click an icon on the screen, just like in the real device, the program the icon represents will run.

Figure 2.4: The Palm Emulator looks just like the device but still adheres to the Windows idioms.

But the program also follows the Windows standards. A device without a mouse (as is the case with this device) doesn’t provide for a right-click (you just tap the screen with a stylus). That means the developers of the emulator were free to make use of this “leftover” user interaction, the right-click. When you right-click anywhere on the emulator, you see the pop-up menu shown in Figure 2.4.

The device, as you can see, has the two levels of interaction I described:

• Interaction with the emulated device through an interface that mimics the device’s interface. This is the device level of interaction. On this level you are using the virtual device.

• Configuration of the device through the Windows interface; in this case, in the form of a pop-up menu. This is the software level of interaction, where you’re controlling the software representing the device.

Look at the pop-up menu and you can see some familiar Windows functions: New, Open, Close, Save, Save As, and About. You also have some interaction that’s particular to this software: Save Bound Emulator, Save Screen, and so on. The Install Application Database is particularly interesting; the submenu shows a list of applications you’ve recently installed, along with an Other… item that lets you choose a program to install.

Now why would the installation be on the Windows level and not the device level of interaction? Don’t you install software on the actual device by using the device? Yes, but not by clicking icons and interacting with the device in the way you interact with its programs. Instead, you run the Palm HotSync Manager software on the PC, which transfers software to the device. That’s not part of the device’s usual interface. Thus, the makers of the emulator needed a way to install software on the emulator, too. And so they simply included a menu item, which displays a simple File Open menu.

Yes, they could have been difficult and included a HotSync Emulator, which transfers software to the emulator in the same way the HotSync Manager transfers software to the actual device. But come on, that would have been a bit cumbersome. A simple File Open box was all that was needed.

RULE

Remember as you are modeling your devices to be aware of the two levels of interaction.

This will be the case even if you’re not drawing the device on the screen as the Palm Emulator does. For example, later on when I talk about class design, I’m going to discuss a phone dialer program. This is a program that uses your modem to dial a telephone number for you, and then you pick up the actual phone and speak. The phone dialer program has two levels of interaction: On one level, you interact with the phone. You tell it to dial, even if you don’t see a silly picture of a telephone. (And yes, if it is a picture, how much you want to bet it will be an antique phone?) But you can probably do things that are outside of the device; I would hope that you can save your phone number list. That’s on the software level of interaction.

Take a look at the calculator program, as another example. This also has two levels: You can push the buttons (or just type the numbers) and do math calculations, thereby interacting with the calculator. Or you can click the View menu and toggle between standard and scientific view, where the calculator will transform from a circa-’70s piece of junk to a more modern scientific calculator. (I only wish the little junky calculator in the attic had a button that would transform it into a modern calculator!) This transformation is on the software level of interaction.

But what if the calculator program didn’t have a transformation between types of calculators? Then you will probably have a minimal software level of interaction, but that’s okay. You’ll still probably want a Help menu, and certainly a File menu with an Exit item (or at least some way to exit the software).

RULE

When designing the two levels of interaction, if you have minimal features on the software level of interaction, try to think what might be missing. Adding to this level will greatly enhance the functionality of your product, making for a more sophisticated, professional product.

The phone dialer lets you actually save phone numbers; the Palm Emulator lets you save sessions. Without these features, the software would have considerably less usability.

In the next section I talk about the specific issue of sessions and how you will probably at least want this basic functionality in your software level of interaction. Then after that short discussion, I talk about another feature, that of Undo.

Saving and Loading Sessions

While I can’t tell you exactly how the notion of a session would apply to your specific software product, I can give you examples of how to do it. Does your software need sessions? In other words, do your users need to be able to save the current state of the virtual device and reload it later? Most likely.

The calculator program doesn’t allow for sessions, but I can think of a simple way that would make the program just a little bit more useable. While a Save/Save As mechanism would be a bit too much for the calculator program (and add a level of confusion), the program could benefit from simply saving its current state and restoring it when it starts back up.

From a programming perspective, this would be incredibly easy. You can save the current state either to a text file or, if you’re on Windows, to the Registry. Here’s some of the data that the program might save:

• The current value that’s showing on the display

• Whether the calculator is presently in standard or scientific mode

• If in scientific mode, whether the calculator is presently in Hex, Dec, Oct, or Bin mode

• If in scientific mode, whether the calculator is presently in Degrees or Radians

• The value that’s currently stored in memory

The calculator program also has some statistical features that I’ve never tried. I’m not kidding. But these might be worth saving as well!

RULE

Think about how you might save states in your software and how your users could benefit from such a state-saving mechanism.

SUGGESTION

Also, consider whether you want to simply save the state (as I described for the calculator program enhancement) or to include a full Save/Open mechanism. (The Palm Emulator has a Save/Open mechanism.)

Undoing the Work

Another feature you might include in your model is an undo capability. Now this might not always be practical; for example, the Palm Emulator wouldn’t benefit much from an Undo feature (not to mention that it would be incredibly hard to implement). Or, if your program is used in a production plant and something gets soldered, welded, dismantled, or altogether modified, then, well, an undo just might not be feasible.

But an undo mechanism would certainly be nice for most systems. Consider, for example, a program that lets a sound engineer control an audio device on stage for a rock band. Imagine if the engineer made several changes to the various sound settings and said, “Oh wait! I liked it better before these changes!” There you go, this is a perfect opportunity for an undo.

Now please, if you’re going to go through the trouble of including an undo system, please don’t just make it one level of undo. If at all possible, please make a multilevel undo system, where the user can undo and undo and undo again, gradually stepping back in time. (And that means, of course, you’ll also want a redo feature in case the user goes back too far in the undo.)

RULE

Including an undo system adds a nice touch to the software level of interaction, and the majority of software out there can benefit from an undo system.

An undo system is normally in the software level of interaction, unless the device itself supports an undo. (Most hardware devices don’t.)

Since an undo mechanism applies to more than just a model of a device, I talk about how to implement an undo system in Chapter 8, “Under the Hood.”

Deciding about the Virtual Interface

In the case of the calculator program, somebody sat down and drew up an interface that looks just like a calculator. That’s fine, and it works pretty well: The user can type numbers on the keyboard or can click the mouse on the buttons. While clicking the mouse is a bit cumbersome, it works pretty well. Most beginners I’ve seen who are first introduced to the calculator program are able to immediately start using it by clicking the buttons with the mouse. Only later do they realize they can also type on the keyboard. (And why are the users able to quickly figure out how to use the software? Because it draws on the familiar idioms.)

But consider a more complex device. Suppose you are writing software that runs on a laptop that lets a sound engineer control all the electronic sound devices on the stage at a rock concert. One of these devices might be a sound wave generator that plugs into a keyboard, letting the keyboard player have additional sounds beyond what the keyboard first had. The sound engineer will use the software to do the following:

• Determine whether the device is functioning

• Choose the sound for the device

• Control the volume of the device

• Reboot the device

(That’s good enough for our purposes. A real program one would probably do more.)

Since we already know what the software does, the next question is how to design the user interface: Do you simply draw a picture of the device on the screen or not? And from there what do you do? First off, let me say that if you draw a picture of the device on the screen, the users will be happy (at least initially). But if you do draw a picture, you must be very careful to make sure that that little picture interacts with the user the way the user expects!

REAL WORLD SCENARIO: The LCD Dash in the Car Died, and Now I Can’t Drive It!

Talk about an experiment gone bad. During the early 1980s, my dad bought a car whose entire dashboard was one giant LED screen. The car had no speedometer, no fuel gauge, no temperature gauge…nothing. It had just one giant LED screen. When you booted (er, I mean started) the car, the LED would light up. Although it didn’t show a big splash screen advertising the car manufacturer, it did have a speedometer, a fuel gauge, and so on, all rendered on the LED screen. The thing was a blast. Everybody would comment about it. (Oh and did I mention the car talked, too? I’m totally serious. “Your fuel is low.” “A door is ajar.”)

This whole LED screen thing was great until something happened: One day it died. Not the car, just the LED. No biggie, take it into the shop, right? Sure, but getting to the shop wasn’t easy. My dad had no speedometer and no fuel gauge! The whole dash was black. He had no way to know how fast he was going and no way to know if he had enough gas to get there!

When he got back he wasn’t so shaken as just plain irritated. But that was only half the problem. The other half was that it seemed the only real way to fix the LED was to install a new one, which required that my dad purchase a new one. The thing cost several hundred dollars.

I notice few cars these days have a dash like this. It was an experiment gone bad. Oh, and as for the talking aspect of the car? Let’s just say that the words “Shut up!” became a common utterance among the passengers of the car, and that feature, too, is strangely absent from today’s cars. However, I understand that some of the new global positioning systems have a similar problem. One editor said she was in a car where a GPS device was driving her nuts because it kept yelling, “You missed your turn. Please make a u-turn as soon as legally possible,” over and over and over.

Now for some issues to help you decide whether to draw the device:

• Does the user of the software already know how to use the device itself?

• Does the user of the software need to know how to use the device itself to use your software?

• Most important, will the user benefit from seeing a drawing of the device?

In the case of sound engineers, most likely they will already know how to use the device itself. That takes care of that one. But in other cases, such as an operations center at a telecommunications center, while some of the operators may know how to use the device itself, others (such as hired temps) might not know how to use the device.

If you are sure the people know how to use the device, then you might consider drawing the device on the screen. But if people don’t know how to use the device, then you have the chance to create a different user interface for the product that’s possibly better than that on the device itself.

But if the user of the software is going to be managing the device (making sure it’s functioning and that sort of thing) or reading data from the device, then will it even make sense to draw the device? If the device is just a box with no blinking lights and no buttons, then why draw it? Or if the device does have blinking lights and buttons but these things have nothing to do with the way the software will be interacting with the device, then again, why draw the blinking lights and buttons?

In the two subsections that follow, I tackle two approaches: drawing the device itself and not drawing the device itself.

Drawing the Device Itself

Drawing the device itself can be exciting and fun, but the truth is, usually you’ll just be opening up a can of worms with a drawing. Remember, this drawing serves a purpose beyond simple artistic value. Your ultimate goal in drawing the device, then, is to create something useable. Don’t just draw a picture of a device for artistic sake.

RULE

Just because your interface is a drawing of a device doesn’t mean you need to skimp on the usability aspect of the user interface. Every rule about interface design applies here just as much, if not more.

Since you’re starting out making a user interface that is different from what people expect on the computer screen, you’re already at a bit of a disadvantage. Therefore, you have a double-edged job ahead of you: Be true to the device, while creating a user interface that still manages to adhere to the idioms people expect out of the computer (be it Windows, Mac OS, etc.).

How do you do this? By recognizing and implementing the two levels of interaction: that of the device and that of the software representing the device. Therefore, you need to figure out a way for your users to “escape” from the device and interact with the software. You have some choices here. You can:

• Use a pop-up menu that responds to a right mouse click, as the Palm Emulator does, since most likely the device’s interface doesn’t have a need for the right mouse click.

• Draw the device inside a regular window that itself contains a menu bar, and possibly toolbars and a status bar. The user would interact on the software level through these menus, toolbars, and status bar.

In addition, make sure that the software interaction level supports most of the usual functionality itself. This includes, when possible, the ability of the user to create a new session (a New File menu item), save a session (Save and Save As menu items), and open a session (Open menu item). Sometimes, of course, these menu choices might not be feasible, but such cases are rare. If you have a way of configuring the device, then you have a way of saving sessions.

But remember, if the device has a strange interface (unlike the Palm computer, which has a simple interface requiring simple taps with the stylus), then you will probably do more harm than good trying to draw the device. Drawing LED displays and big dials and actually making these things functional is complex and results in a difficult interface to use with the mouse; further, doing so totally violates the standard idioms we know and love. But, on the other hand, you might just be drawing these items for the “coolness” factor and they won’t actually be functional. So my decision? Here it is:

RULE

Don’t draw the interface unless doing so adds to the usability and the interface is easy to use. Yes, having a cool-looking device with knobs might be visually appealing at first, but I guarantee that if you have pictures of dials and buttons that aren’t functional, the first thing people will do is try to click them.

Besides, over time, the users will no longer even notice the graphical appeal, and they will care only about the usability.

Look again back at Figure 2.1. Wouldn’t you try turning those knobs? I did even though I wrote the program and know they don’t actually do anything. (I just used a graphics program to draw out the thing and paste it into an image control in Borland Delphi to create the program!) I think deep inside a part of me really wanted to believe the dials would turn.

Given the choice between coolness and usability, opt for usability. Do the pictures of the devices in Figure 2.1 even serve any purpose? No. So get rid of them. Are there situations where such drawings do serve a purpose? Yes, but only if they actually provide some important visual feedback. In my sample they do nothing. Does the drawing of the Palm device serve a purpose? Yes. You can actually click the buttons and the screen in the Emulator.

The moral is, then, think twice before drawing the device. But if you do, make sure that the interface is useable.

Not Drawing the Device Itself

Suppose you’ve chosen not to draw a basic mock-up of the device. Instead, you’re going to adhere to the standard of Windows or the Mac or X or whatever you use. Life is easier, right?

Maybe, but you still have to come up with a way to interact with the device; you still have the two levels of interaction. Consider the case of the audio box used by the rock band and the sound engineer. The sound engineer needs a software application that will let him quickly and easily control and interact with the device.

A good way to do this is to list the functionality of the device and then find user interface elements that are standard parts of the operating system (such as buttons, sliders, and what-not) that can serve to represent these aspects of the device.

For example, while the device itself might have knobs that you can turn, the software application might instead have sliders that are more within the standard of the operating system. While the device might have an LED output, the software version might use a static text control in the default font (rather than some ugly LED font) or use an edit control that the user can type into. The following graphic shows a slider control on Windows XP alongside an edit control. If this setup were in a program controlling an audio device, it would be much easier to use than a custom control showing a knob would be. You can quickly move the slider left and right, which changes the text to the right. Or you can just type the value into the edit control.

But remember as you design this kind of program to still make a distinction between the two levels of interface, the device and software levels—even if the user isn’t going to be totally aware of these levels. In other words, if you’re using the menu bar in the main window for the software level of interface, with such menu items as Open, Save, and so on, don’t confuse the topic by mixing a menu item that says Set Volume Level in with the other menu items. Instead, divide up your menus and also allow the user to set the volume level using the slider control you previously decided on. That way, your software will still maintain the two levels. (In Chapter 5, “Highly Navigable Software,” in the section “Constructing Sensible Menus,” I give more details on menu design.)

Real-Time Interaction and Instant Updates

The virtual device you have on screen may or may not be connected in real time with the actual device. In other words, if you moved the computer and the device side-by-side, and you saw the image of the device on the screen, complete with its LEDs and blinking lights and buttons, would the image and the device look the same?

Or, if you’re not drawing the image as is, but you still have some duplicate functionality (for instance, the numbers showing up on the LEDs on the actual device also show up in the status bar at the bottom of your software), then will the numbers you see on the device and on the software always match and change simultaneously?

In some cases, maybe not. If the software is management software, it may poll the device for data and update its user interface only when the polled information changes. If the device goes down and its LEDs all go blank, the device on the screen might not change for another 30 seconds or even two hours, depending on how often your system polls the device.

And when the user interacts with the virtual device, will changes to the virtual device immediately occur in the actual device? In most cases, you will write your software to have changes happen automatically. But again, maybe not; it depends on your situation.

RULE

If you’re building software for hire, find out if the users require immediate updates or if polling is acceptable. And whatever your decision on the timing of the interactions, make sure the users of the device are fully aware of how the software will behave. If changes don’t affect the device immediately, make sure the users know.

Further, whether you use polling or not, another important factor to consider is the communications protocol. In the telecom network management world, one common protocol is UDP. If you’re familiar with TCP/IP and UPD, then this might surprise you. Why? Because a UDP packet of data sent from one computer to another is not guaranteed to make it.

Unfortunately, many devices in the network management world are set up to use only UDP, and so even if you want to switch to TCP for your protocol, you can’t. You’re stuck with UDP. But that’s not always bad, because most network management devices send out data over and over (not constantly, but periodically) when there’s a problem, and if a few packets get lost, no big deal.

RULE

When you design the software to interact with the device, make sure you are aware of whether the protocol you are using is guaranteed, and make sure your users are aware also.