Designing Web Interfaces
Bill Scott
Theresa Neil
Copyright 2009 Bill Scott and Theresa Neil
O'Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (.
Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly Media, Inc. Designing Web Interfaces , the image of a Guianan cock-of-the-rock, and related trade dress are trademarks of O'Reilly Media, Inc.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
![OReilly Media SPECIAL OFFER Upgrade this ebook with OReilly for more - photo 1](/uploads/posts/book/54668/images/00001.jpg)
O'Reilly Media
Foreword
In architecture, parti refers to the underlying concept of a building.[] Will it be an academic structure aimed at increasing cross-disciplinary collaboration or a theater flexible enough to support quick set changes? To bring a specific parti to life, architects must not only define its essence but also know how to manage the huge number of considerations that ultimately impact its construction.
Design principles are the guiding light for any architect's parti. They define and communicate the key characteristics of a building to a wide variety of stakeholders, including clients, builders, city planners, and engineers. Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole. But design principles are not enough.
Every aspect of a building from an attic to a Zen garden has a set of opportunities and limitations that can either add to or detract from the main concept or parti. These include standard dimensions, spacing requirements, aesthetics, physical limitations, and more. Architects who want to bring coherent visions to life need to learn the detailed ins and outs of these design considerations so they can select the best solutions from the options available.
This combination of design principles at the top and design considerations at the bottom is what allows architects to fill in the middle with meaningful buildings that enable people and organizations to interact, communicate, and get things done.
Those of us whose parti is bringing rich web applications to life can also benefit from a framework of design principles and considerations to guide us. In these pages, Bill Scott and Theresa Neil give us just that. Through 30 years of designing and developing software, Bill and Theresa have been the consummate taxonomistsnaming, documenting, and sharing in loving detail what makes rich interactions succeed and fail.
The breadth of solutions they have encountered has given them a unique perspective on the design principles behind the most successful rich interactions on the Web. From , the principles he outlines in this book are your yardstick for measuring the value that rich interactions bring to your web application. Through in-depth descriptions of context and trade-offs, Bill and Theresa support each principle with the design considerations and best practices you need to make informed decisions. Engineers, product managers, marketers, and designers can rally around and continually return to these principles and considerations to ensure that everyone is evaluating the impact of design decisions the same way.
This combination of rich web interaction design principles at the top and design considerations at the bottom allows web designers to fill in the middle with meaningful structures that enable people and organizations to interact, communicate, and get things done. Just like our friends, the architects.
So, dive in and immerse yourself in the direction and details you need to bring your rich web application partis to life!
Luke Wroblewski October 2008
Senior Director, Product Ideation and Design, Yahoo! Inc. Author, Web Form Design: Filling in the Blanks (Rosenfeld Media) Author, Site-Seeing: A Visual Approach to Web Usability (Wiley)
[] The term parti comes from Matthew Frederick's book 101 Things I Learned in Architecture School (MIT Press).
What Happened
My (Bill's) first personal computer was a Radio Shack Color Computer (circa 1981)complete with a chiclet-style keyboard. The first few months the main user interface was the command line, typing in COLOR BASIC code.
Later, an upgrade to an Apple IIe brought a nicer keyboard with lots of games. But the interface was basically the same. The command-line and text-driven menu systems ruled the day. When the IBM PC came on the scene it brought more of the same. Lotus 123, which was the state-of-the-art spreadsheet application at the time, was controlled by a set of cryptic keystrokes. Not much of a user experience.
Then an interface revolution started. The Macintosh arrived in 1984, and shortly after its introduction, I brought one home. The mouse opened the door to a brand-new world of interaction. Instead of having to learn archaic commands to navigate through text-based menus, interaction in this new environment happened naturally in a direct, intuitive manner.
OK, you are probably thinking, so what? That was 1984. This is now. What does this have to do with a book about designing web interfaces?
Everything.
For most of the history of the Web, sites and applications were marked by primitive interfacesjust like the early desktop era. Most sites were built from two events:
- Clicking hyperlinks
- Submitting forms
Try to create an interesting user experience from just those two events. And, to add insult to injury, every click and every submit was punctuated with a page refresh. Creating a seamless user experience was next to impossible.
Interestingly, the technologies have existed for many years to get around these limitations. But it was only after they became widely available across the most common browsers that developers could count on them in their everyday development. In 2004, Google launched Gmail and Google Maps using a set of techniques later dubbed Ajax by Jesse James Garrett.
The difference was dramatic. The Ajax-enabled Google Maps now interacted more like a desktop application with real-time pan-and-zoomall with no page refresh. Mapquest, on the other hand, behaved like most other web applications at the time, refreshing the page each time the map was repositioned or zoomed. The contrast was clear between the old world of the Web and the new world as enabled by Ajax.
Why We Wrote This Book
While I got the chance to live through the first interface revolution for the desktop (even writing one of the first games for the Macintosh[
A few years ago our paths crossed at Sabre (parent company of Travelocity). Together we founded a user experience design team and worked to improve dozens of products, performing heuristic evaluations and participating in full web application redesigns. From that work, we distilled a number of user interface design patterns as well as anti-patterns (common mistakes to avoid).