Uh-oh, it looks like your Internet Explorer is out of date.
For a better shopping experience, please upgrade now.
In a fantasy world, you design and build the core of your application, the parts that do all the heavy lifting. And the graphical user interface? Well, that's the domain of the hot-shot sitting one cube over, who went to school to learn how to give users sensible and effective control over the functionality you construct.
In the real world, there is no hot-shot sitting one cube over, and you have to build the GUI yourself.
- Arranging text and controls in a sensible order
- Understanding and making the most of the behavior of windows
- Improving the effectiveness of dialog boxes
- Using advanced controls such as TreeViews, ListViews, and tabs
- Designing menus and toolbars
- Providing users with sensible customization options
- Understanding how the rules change when designing for the Web
- Handling page layout and navigation on the Web
- Anticipating changes in the next version of Windows
Throughout, author Mike Gunderloy is doggedly realistic. Like in his previous book, Coder to Developer: Tools and Strategies for Delivering Your Software, Mike describes how things actually work and prescribes ways for you to achieve meaningful results without staging a revolution. This is hard-won, practical knowledge from a veteran developer whose advice, examples, and overall vision will change the way you think and work.
|Product dimensions:||7.50(w) x 8.84(h) x 0.93(d)|
About the Author
Mike Gunderloy is an independent consultant who has worked with Microsoft data access and web technologies for more than a decade. He is the author of the best-selling Coder to Developer: Tools and Strategies for Delivering Your Software, the popular Access 2002 Developer's Handbook series, and ADO and ADO. NET Programming, and he is co-author of .NET Programming 10-Minute Solutions, Mastering Visual C# .NET, Mastering SQL Server 2000, and .NET E- Commerce Programming, all from Sybex.
Read an Excerpt
Developer to Designer
By Mike Gunderloy
John Wiley & SonsISBN: 0-7821-4361-X
Chapter OneThe Big Picture
User Interface Design for the Busy Developer
Thinking About Software
Finding a Few Guiding Lights
Basics of a Good User Interface
My goal with this book is simple: to help you design and improve user interfaces for your Windows and web applications. By designing better user interfaces (UIs), you can improve user satisfaction and make users more productive. Ultimately, this will make you more appreciated and in demand as a developer. Along the way, I'll pass on lots of little tips and drill into many of the details that make for a good user interface. Most of the book will focus on little things, from toolbar buttons to laying out a web application. But before getting into the details, it will help to have an overall framework for thinking about user interface design. That's where this chapter comes in.
User Interface Design for the Busy Developer
Depending on the size of your development team and the workflow in your organization, several people may be responsible for designing an application's user interface:
If you have project managers whose responsibilities include writing software specifications, they may include user interface mockups in the specification.
If you're using extreme programming (XP) practices, you might have a customer representative dictating the design of the user interface.
If the organization is sufficiently large, you may have user interface design specialists who do nothing but work on these issues.
If the user interface isn't completely specified at the time that the code has to be written, it falls on the developer to make the initial design decisions. This is not usually the best possible situation. Without user feedback, it's hard to come up with a good design. But the task still needs to be done.
I'm primarily a developer myself, so if you're in that last category, I empathize. Designing the user interface is just one of the dozens of things that most developers have to do in the course of their jobs. Even if it's not your primary focus, you need to understand enough about user interface design to get the job done.
But remember: Designing a good user interface does not relieve you of the responsibility to develop a working application. You can't afford to invest all your development time in making the user interface pretty. That approach would sacrifice functionality. Instead, it's your job to strike a balance among all the competing demands on your time.
Take heart, however. Although you may never have thought about user interface design in detail, the basics are fairly straightforward. And like any other skill, they can be learned. I offer these words of comfort for the busy developer faced with user interface design:
If you can learn a computer language, you can learn to build a functional, usable, and reasonably attractive user interface.
Thinking About Software
What do you think about when you think about software? Ones and zeroes? Loops and conditional statements? Although these may be good ways to think about the internal construction of computer programs, they don't do much to illuminate the task of building a good user interface for an application. In this section, I'll guide you through some alternate ways of thinking about your software. These ways have proven helpful to me in the past when I've had user interface design work to do.
Software as a Conversation
One way to think of your software is as a conversation between the developer and the user. The user starts the conversation by running your application. You return with an opening gambit that lists the things you're ready to talk about. The user selects one, and you respond. The interchange of the user taking an action and then you responding (through your software) continues through the life of the application.
Thinking about software as a conversation makes it clear that you need to communicate with the users of your application. It's unrealistic to expect users to figure out what the application does and how to make it work by guesswork alone. Fortunately, there are several ways to communicate with the user: help files, printed documentation, and the user interface all contribute to your end of the conversation. Of these, the only one that you can depend on the user "hearing" is the user interface itself. Help files can be closed, manuals can be left unread, but it's the rare user who can fire up the application and then ignore the user interface completely.
But don't push this way of looking at things too far. Although you do communicate with users through the user interface of your application, it's a very limited kind of communication. You don't have any way to react to the user's facial expression or body language. You can't tell from timing whether they're understanding your intentions or missing them wildly. Despite these limitations in the software-as-a-conversation model, there's one big lesson to be learned here. In a real-life conversation, you wouldn't arbitrarily start speaking Esperanto or Hungarian without some indication that listeners are expecting the switch. Similarly, in software it is very dangerous to suddenly discard well-known user interface conventions without a good reason. A confused user is an unhappy user.
Similes, Metaphors, and Software
Another way to think about software is to compare it to some real-world object. This is a familiar tactic for making computer programs less scary-and their functions more obvious-to users. For example, Windows was originally designed as a sort of electronic rendition of an office worker's desktop, with file folders and documents and a calculator and a clock. You can move documents from one file folder to another, or discard them into a recycling bin. You can punch buttons on the calculator to do simple math, or set the time on the clock.
This may all seem quite obvious to you as a Windows user in the first decade of the 21st century. But when Windows first came out in the early 1990s, it was a revolutionary way to interact with computers. The similarities between the Windows desktop and a physical desktop helped many of us figure out how to use this new breed of software.
Sometimes software developers speak of this sort of thing as coming up with a metaphor for their software. But they're wrong: the relation between applications and the real world is one of simile, not metaphor. Think back to your middle-school English classes, and you may recall the difference between a metaphor and a simile:
A metaphor is a figure of speech in which one thing is equated to another, as in "Windows is an office worker's desktop."
A simile is a figure of speech in which one thing is said to be like another, as in "Windows is like an office worker's desktop."
The distinction is important, because these comparisons between applications and parts of the real world inevitably break down at some point. For example, you can't keep a pint of whiskey in the bottom drawer of the Windows desktop or spill ink on the letter you're writing. But the Windows desktop lets you change the label on a file folder without needing an eraser or a typewriter -something that would be quite a trick in the real world. The point is that the Windows application is not identical to the real world. At best, it is similar to the real world.
Another way to think about this is to consider applications as analogies to the real world. One dictionary definition of analogy is as a similarity in some respect between things that are otherwise dissimilar. We know that computer applications and the real world are two different things, and they are wildly dissimilar: The real world is made up of atoms, and applications are made up of bits. But there are areas where the two are similar. Thus, the Windows desktop does have an analogy to a real desktop, and by conjuring up the image of a real desktop in the user's mind, it suggests to the user how the Windows desktop can be manipulated.
Because applications are at best similar to the real world, users are forced to construct a map (a set of correspondences) between the application and more familiar objects. That is, some reasoning takes place of the sort "this application behaves like X, so I should be able to do Y," either consciously or unconsciously, as the user tries to figure out which parts of the real world experience are applicable to the software at hand. Not all such mappings are created equal. Figure 1.1 shows schematically how two different applications might compare to their real-world counterparts.
The upper part of the diagram demonstrates an application that maps very closely to its real-world model. There are a few things about the application that aren't in the real world, and vice versa, but the overlap between the two is substantial. The application behaves mainly as if it were a part of the real world. In the lower part of the diagram, a second application is a much less precise match to its real-world partner. Many things about the application can't be understood by reference to the real world.
It's tempting to suppose that more an application will be better and easier to use if it is a more precise match to its real-world model. This in turn implies that the user interface should mimic some portion of the real world. But that is not necessarily true. Remember Microsoft Bob? That was Microsoft's most "realistic" user interface to date, and it was a resounding flop. Among other problems, imposing too much of the real world on the way the system worked led to very difficult navigation, with artificial constraints to traveling around from one part of the application to another. That's fine in a game, but not in an operating system.
Another reason to beware of software similes is that they can lead to tunnel vision. If you're trying to exactly mimic some piece of real-world hardware in a software application, you may well miss opportunities to add and extend functionality that would benefit users. So if you start with a simile in mind, make sure that you don't stop there.
Software as a Means
As a final way to think about software, remember that software is a means rather than an end. The chance that a user will be running your application just because they want to run your application is almost zero. Instead, they will have some goal in mind, and your application is a way to reach that goal. Even when a user launches your application to explore its capabilities, they usually have a goal in mind, such as evaluating whether the application will meet their needs.
Keeping this principle in mind is a good way to avoid making your software overly cute at the expense of usability. Spending effort to add a photorealistic three-dimensional user interface inspired by your favorite movie may make you feel extremely clever, but if users can't find the menus among the clutter, it's a step backward for your application. Users also don't care about how clever your code is, or how much work went into the program. They just want to reach their goals. If your program is the best means to that end, great. If not, there are plenty of other programs out there to try.
This is an area where a good user interface can give you a boost in the market. If your application is easy to use, then it will be a more natural means. This can translate directly into happier users and more sales.
Finding a Few Guiding Lights
The next step beyond thinking about applications is to thinking about user interfaces. Some applications, of course, have no user interface (or so little user interface as to be practically none at all): Windows services are a prime example of such applications. But most applications display information to the user and allow the user to interact with the application in turn.
Before getting into specific guidelines for what constitutes a good user interface, there are three overall principles that you ought to keep in mind:
I'll discuss each of these principles in turn.
Concentrating on the Task
Just as user has a long-term goal in mind for their overall use of your application, they have a short-term goal to focus on at any given point. Writing a letter in a word processor, for example, might be broken down into three steps:
1. Choose an appropriate template to create the skeleton of the letter.
2. Type the text of the letter.
3. Print the letter.
Although the user wants to write a letter through this entire process, they need to perform a number of tasks along the way. The user interface is their only way to convince the application to perform these tasks in the right order. Making sure that the user can always perform their next desired task is part of the job of building a user interface.
At any given point, a good user interface will offer ways for the user to perform the next task that they have in mind. In most cases, though, you won't know precisely what the user wants to do next, so the user interface must offer choices. Even so, sometimes you can target your choices. Figure 1.2 shows the task pane that Microsoft Excel 2003 displays when you first launch the application. At this point, it's a good bet that the user wants to either create a new document or open an existing document, so the choices are focused in those directions.
Task panes like this strike a nice balance between making common tasks easy and making uncommon tasks possible. Most users can probably get to their proper starting point by choosing an option in this task pane, but the task pane doesn't block access to the other menus and icons within Excel. If you have some other starting point in mind, and you know what you're doing, the task pane won't get in your way.
If you're having trouble figuring out the tasks that a user might want to perform with your software at any given time, try writing some scenarios. A scenario is just an informal story about what a user might want to do with your software. For example, if you're writing the perfect application for sending out spam, a couple of your scenarios might read this way:
"Judy is a new spammer who isn't quite sure how to get the maximum returns from her ads for dubious imported pharmaceuticals. She launches SpamOVator and tells it to create a new spam e-mail. She then types in the text of her ad and presses the Analyze button. SpamOVator automatically inserts misspellings and obfuscates the URLs, while keeping the sense of the message intact and suggesting some subject lines. Judy selects a subject line from the list, presses the Send button, and spews out 100,000 copies of her ad."
"Bob is an experienced spammer who has limited time to get things done. He starts SpamOVator and imports his ad text from a Microsoft Word file. He's already crafted his own keywords to get past Bayesian filters, so he simply types in his subject line, hits Send, and goes on to his next project."
In a real product specification, each of these scenarios would be much longer, and there would be others to supplement them. The key to writing a good scenario is to focus in on a particular real-world user and describe their interaction with the software. From the scenarios, you can then derive a list of tasks that might be performed at any given time. For example, it's already clear that SpamOVator must both allow creating new messages from scratch and importing messages created in other applications, and that both of these tasks should be possible to perform as soon as you launch the program.
Using Common Idioms
The dictionary offers several definitions of the word idiom; the one that concerns me here is "The specific grammatical, syntactic, and structural character of a given language." (Thanks to the fourth edition of the American Heritage Dictionary of the English Language for that wording.) When pressed into service for user interface design, idioms are those broad patterns of behavior that persist across many programs. Take a look at Figure 1.3. If you've had any substantial experience with Windows at all, you're likely to agree that one of these applications looks right and the other looks wrong.
The word processor at the top of the figure has its menu at the very top of the window, with toolbars directly beneath that. The one on the bottom has these parts of the interface scattered around willy-nilly. Although both applications have the same functionality, users are likely to be much happier with the one on the top because it uses the idioms with which they are already familiar.
Ironically, both of these word processors are really Microsoft Word 2003. A few versions ago Microsoft went somewhat crazy with customization, and ever since then the Office applications have allowed you to move the menus to any place you might want them. I'll discuss this aspect of user interface design in Chapter 11, "User Choice, Customization, and Confusion."
Excerpted from Developer to Designer by Mike Gunderloy Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Chapter 1: The Big Picture.
Chapter 2: Putting Words on the Screen.
Chapter 3: Managing Windows.
Chapter 4: Command Buttons.
Chapter 5: Using Text Input Controls.
Chapter 6: The Other Controls.
Chapter 7: Dialog Boxes.
Chapter 8: Common Windows User Interface Elements.
Chapter 9: User Input and Navigation.
Chapter 10: Common Interaction Patterns.
Chapter 11: User Choice, Customization, and Confusion.
Chapter 12: The Web Is Not Windows.
Chapter 13: Building a Web Page.
Chapter 14: Common Web Design Patterns.
Chapter 15: Common Web Interaction Patterns.
Appendix: Looking Forward to the Next Generation: Designing User Interfaces for Avalon.