界面设计模式(英文影印版)(第二版)

.other people's advice
personal recommendations
2. organizing the content:
information architecture and application structure
the big picture
the patterns
feature, search, and browse
news stream
picture manager
dashboard
canvas plus palette
wizard
settings editor
a

.　　As such, patterns can be a description of best practices within a given design domain.They capture common solutions to design tensions (usually called "forces" in pattern literature) and thus, by definition, are not novel. They aren't off-the-shelf components; each implementation of a pattern differs a little from every other. They aren't simple rules or heuristics either. And they won't walk you through an entire set of design decisions--if you're looking for a complete step-by-step description of how to design an interface, a pattern catalog isn't the place to find it!
　　Patterns are:
　　Concrete, not general
　　All designers depend upon good design principles, like "Prevent errors;' "Create a strong visual hierarchy;' and "Don't make the user think." It's rather hard, however, to design an actual working interface starting from fundamental principles! Patterns are concrete enough to help fill the space between high-level general principles and the low-level "grammar" of user interface design (widgets, text, graphic elements, alignment grids, and so on).
　　Valid across different platforms and systems
　　Patterns may be more concrete than principles or heuristics, but they do define ab stractions-the best patterns aren't specific to a single platform or idiom. Some even work in both print and interactive systems. Ideally, each pattern captures some minor truth about how people work best with a created artifact, and it remains true even while the underlying technologies and media change.
　　Products, not processes
　　Unlike heuristics or user-centered design techniques, which usually advise on how to go about finding a solution to an engineering or design problem, patterns are possible solutions.
　　Suggestions, not requirements
　　You should almost always follow good design principles and heuristics, of course. And organizations need designers to follow style guides so that their products stay self-consistent. But patterns are intended to be only suggestions; you can follow them or reject them, depending on your design context and user needs.
　　Relationships among elements, not single elements
　　A text field is not a pattern. The spatial relationships between a text field and a piece of help text near it, however, might be a pattern. Likewise, changes in a set of elements over time--as a user interacts with the software--may constitute a pattern, though some patterns capture only static relationships.
　　Customized to each design context
　　When a pattern is instantiated in a design, the designer should adjust the pattern as needed to fit the situation. You could use some of the pattern examples verbatim, but as long as you understand why the pattern works, why not be creative? Fit the pattern to your particular users and requirements.
　　Some very complete sets of patterns make up a "pattern language;' These patterns resem ble visual languages in that they cover the entire vocabulary of elements used in a design (though pattern languages are more abstract and behavioral; visual languages talk about shapes, icons, colors, fonts, etc.). The set in this book isn't nearly as complete, and it con-tains techniques that don't qualify as traditional patterns. But at least it's concise enough to be manageable and useful.
　　Other Pattern Collections
　　The text that started it all dealt with physical buildings, not software. Christopher Alexander's A Pattern Language and its companion book The Timeless Way of Building established the concept of patterns and described a 250-pattern muhilayered pattern language. It is often considered the gold standard for a pattern language because of its completeness, its rich interconnectedness, and its grounding in the human response to our built world.In the mid-1990s, the publication of Design Patterns by Erich Gamma, Richard Helm,Ralph Johnson, and John Vlissides profoundly changed the practice of commercial soft'ware architecture. This book is a collection of patterns describing object-oriented "microarchitectures." If you have a background in software engineering, this is the book that probably introduced you to the idea of patterns. Many other authors have written books about software patterns since this book. Software patterns such as these do make software more habitable--for those who write the software, not those who use it!
　　The first substantial set of user-interface patterns was "Common Ground;' the predecessor to the book you're reading now. Many other collections and languages followed,notably Martijn van Welie's Interaction Design Patterns; van Duyne, Landay, and Hong's The Design of Sites; the Little Springs mobile patterns, now known as Design4Mobile; the Yahoo! Design Pattern Library, which morphed into Designing Web Interfaces; and the rest of the O'Reilly design pattern library, including Designing Social Interfaces, Designing Gestural Interfaces, and the first edition of this book.
　　About the Patterns in This Book
　　So there's nothing really new in here. Ifyou've done any web or UI design, or even thought much about it, you should say, "Oh, right, I know what that is" to most of these patterns.But a few of them might be new to you, and some of the familiar ones may not be part of your usual design repertoire.
　　These patterns work for both desktop applications and highly interactive websites. Many patterns also apply to mobile devices or TV-based interfaces (like digital recorders).Though this book won't exhaustively describe all the interface idioms mentioned earlier, these idioms help to organize the book. Some chapters focus on the more common idioms: forms, information graphics, mobile interfaces, and interactions with social networks. Other chapters address subjects that are useful across many idioms, such as organization, navigation, actions, and visual style. (The book does not address idioms such as online games or communities, simply due to lack of space.)
　　This book is intended to be read by people who have some knowledge of such interface design concepts and terminology as dialog boxes, selection, combo boxes, navigation bars, and whitespace. It does not identify many widely accepted techniques, such as copy-and-paste, since you already now what they are. But, at the risk of belaboring the obvious, this book describes some common techniques to encourage their use in othercontexts or to discuss them alongside alternative solutions.
　　This book does not present a complete process for constructing an interface design. When doing design, a sound process is critical. You need to have certain elements in a design process:
　　Field research, to find out what the intended users are like and what they already do
　　Goal and task analysis, to describe and clarify what users will do with what you're building
　　Design models, such as personas (models of users), scenarios (models of common tasks and situations), and prototypes (models of the interface itself)
　　Empirical testing of the design at various points during development, like usability testing and in situ observations of the design used by real users
　　Enough time to iterate over several versions of the design, because you won't get it right the first time
　　These topics transcend the scope of this book, but there are plenty of other excellent re sources and workshops out there that cover them in depth.
　　But there's a deeper reason why this book won't give you a recipe for designing an interface. Good design can't be reduced to a recipe. It's a creative process, and one that changes under you as you work--in any given project, for instance, you won't understand some design issues until you've designed your way into a dead end. I've personally done that many times. And design isn't linear. Most chapters in this book are arranged more or less by scale, and therefore by their approximate order in the design progression: large decisions about content and scope are made first, followed by navigation, page design, and eventually the details of interactions with forms and toolbars and such. But you'll often find yourself moving back and forth through this progression. Maybe you'll know very early in a project how a certain screen should look, and that's a "fixed point;" you may have to work backward from there to figure out the right navigational structure. (It's not ideal, but things like this do happen in real life.)
　　Here are some ways you can use these patterns:
　　Learning
　　Ifyou don't have much design experience, a set of patterns can serve as a learning tool. You may want to read over it to get ideas, or refer back to specific patterns as the need arises. Just as expanding your vocabulary helps you express ideas in language, expand- ing your interface design "vocabulary" helps you create more expressive designs.
　　Examples
　　Each pattern in this book has at least one example. Some have many; they might be useful to you as a sourcebook. You may find wisdom in the examples that is missing in the text of the pattern. If you're a designer who knows the patterns already, the examples may be the most useful aspect of the book for you.
　　Terminology
　　If you talk to users, engineers, or managers about interface design, or if you write specifications, then you could use the pattern names as a way of communicating, and discussing ideas. This is another well-known benefit of pattern languages. (The terms "singleton" and "factory;' for instance, were originally pattern names, but they're now in common use among software engineers.)
　　Comparison of design alternatives
　　Ifyou initially decided to use Module Tabs to organize material on a page and it's not working quite as well as you hoped, you might use these patterns to come up with al- ternatives, such as Titled Sections or an Accordion. Other sets of"either/or" patterns are presented in this book, often with reasons to choose one pattern or another. Skilled designers know that presenting alternative designs to clients frequently leads to a better choice in the end.
　　Inspiration
　　Each pattern description tries to capture the reasons why the pattern works to make an interface easier or more fun. Ifyou get it, but want to do something a little different from the examples, you can be creative with your "eyes open." You could also use the book to jumpstart your creative process by flipping through it for ideas.
　　One more word of caution: a catalog of patterns is not a checklist. You cannot measure the quality of a thing by counting the patterns in it. Each design project has a unique context,and even if you need to solve a common design problem (such as how to fit too much content onto a page), a given pattern might be a poor solution within that context. No reference can substitute for good design judgment. Nor can it substitute for a good design process, which helps you find and recover from design mistakes.
　　Ultimately, you should be able to leave a reference like this behind. As you become an experienced designer, you will internalize these ideas to the point that you don't even notice you're using them anymore; the patterns become second nature and a permanent part of your toolbox.