Siêu thị PDFTải ngay đi em, trời tối mất

Thư viện tri thức trực tuyến

Kho tài liệu với 50,000+ tài liệu học thuật

© 2023 Siêu thị PDF - Kho tài liệu học thuật hàng đầu Việt Nam

Modular Web design: creating reusable components for user experience design
PREMIUM
Số trang
359
Kích thước
42.8 MB
Định dạng
PDF
Lượt xem
1541

Modular Web design: creating reusable components for user experience design

Nội dung xem thử

Mô tả chi tiết

MODULAR

W E B D E S I G N

Creating Reusable Components for User Experience Design

This page intentionally left blank

Nathan Curtis iii

MODULAR

W E B D E S I G N

Creating Reusable Components for User Experience Design

Nathan Curtis

Modular Web Design: Creating Reusable Components for User

Experience Design and Documentation

Nathan Curtis

New Riders

1249 Eighth Street

Berkeley, CA 94710

510/524-2178

510/524-2221 (fax)

Find us on the Web at www.newriders.com

To report errors, please send a note to [email protected]

New Riders is an imprint of Peachpit, a division of Pearson Education

Copyright © 2010 by Nathan Curtis

Acquisitions Editor: MICHAEL NOLAN

Project Editor: VALERIE WITTE

Technical Editor: AUSTIN GOVELLA

Copyeditor: DOUG ADRIANSON

Proofreader: SCOUT FESTA

Production Editor: CORY BORMAN

Composition and Interior Design: MAUREEN FORYS

Indexer: VALERIE HAYNES PERRY

Cover Design: TERRI BOGAARDS

Notice of Rights

All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical,

photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on getting

permission for reprints and excerpts, contact [email protected].

Notice of Liability

The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the

preparation of the book, neither the author nor Peachpit shall have any liability to any person or entity with respect to any loss

or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer

software and hardware products described in it.

Trademarks

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 Peachpit was aware of a trademark claim, the designations appear as requested by

the owner of the trademark. All other product names and services identifi ed throughout this book are used in editorial fashion

only and for the benefi t of such companies with no intention of infringement of the trademark. No such use, or the use of any

trade name, is intended to convey endorsement or other affi liation with this book.

ISBN-13: 978-0-321-60135-3

ISBN–10: 0-321-60135-1

9 8 7 6 5 4 3 2 1

Printed and bound in the United States of America

To my son Liam,

with whom I build.

To my daughter Caroline,

who tears down with glee.

And to my wife Tina,

who makes it so we can all play.

Foreword

THE OTHER MORNING I got called into an emergency online meeting to look at a new

design that one of our marketing groups had created and needed to roll out worldwide

on a one-day deadline. Frankly, I feared the worst. Cisco is a pretty big company, and in a

typical week I may see between 10 and 20 different designs, some of which in their fi rst

incarnations start with visual comps of things our Web team can’t quickly implement,

or otherwise take liberties with the brand identity or style and therefore require a course

correction. (If you work in a design group anywhere, I am sure you will empathize.)

As I opened the PDF from the marketing group, I had a delightful surprise: The group had

recently adopted our standard wireframing templates, pioneered by Nathan Curtis, and

everything they had put together on this fast-turn project was completely standard. In dis￾cussing the design with them, I made one note on a component that they’d placed in an

unusual location, and that was that. Design approved, deadline met. And I knew that there

would be a good-looking, user-tested visual design and HTML code and style sheets avail￾able from our off-the-shelf library to back up what they had designed.

At Cisco, we have a component system that includes all of the commonly used capabilities

on our sites. Increasingly, this system extends down to the level of HTML code and CSS.

We put this system in place not because a central group has tight control of every page,

but because we don’t. Our Web teams are distributed and work collaboratively, and

need to work from standard templates and documentation so that all of the pieces on

our millions of Web pages work together.

Our employees who support our designs across our many Web areas are distributed

worldwide, and in addition we have dozens of vendors worldwide who produce new

creative. The fact that we have templates—that work down to the component level—is

a big win for global consistency.

In the years I have worked with him, Nathan Curtis has been a passionate and tireless

advocate for the component-driven design approach to design and design systems that

ultimately made the above possible, including that pleasant interaction with that mar￾keting group’s design. Nathan’s natural, module-driven philosophy can benefi t almost

any size of Web or mobile experience, and is essential for large sites that often manage

hundreds of key experiences and present them via millions of pages that need to stay

consistent and clear.

I am looking forward to having this book within easy reach at work and at home.

—Martin Hardee

Director, Web Experience Design, Cisco

Preface

BY THE FALL OF 2007, I’d been working on—and become fascinated by—the component

libraries that teams use to effi ciently and consistently create user experience. I’d been

“thinking components” for much longer. So when my family traveled back to my boyhood

home in northeastern Ohio for Thanksgiving, I wasn’t prepared for the giant revelation

that awaited me.

On the holiday morning, we were all sitting around the living room, and my mom dumped

out a huge container of LEGO bricks in front of my 2-year-old son. He was awestruck and

dove right in, putting all sorts of pieces together. As he built “ships” and other things, I

uncovered the directions for building an actual, formal spaceship. He was intrigued, so I

took advantage of a “teachable moment” to show him how to build LEGO constructions.

Whoa. As I slowly sifted through the massive LEGO pile, retrieving each individual piece,

my son quickly lost interest and began building his own stuff again. So I set about fi nding

all the pieces we needed, one by one, for over an hour. The set wasn’t that big, but it took

forever to source the collection. As I did so, I laid them out on the fl oor in an organized

way, arranging pieces in rows and columns based on shape, size, color, and other facets.

When done, my son and I launched into building the ship, and got it done in no time at all.

And he was ecstatic.

Partway through that process, I realized that “this is what I do for my job.”

As a designer, each project begins with stakeholders requesting that we design and build

something for them, much like some sort of spaceship. They may even bring a picture of

what they want: a shiny fi ghter with all the latest bells and whistles.

Our initial reaction, knowing that we’ve built lots of ships before, is to respond with, “Well,

here’s how we build ships. It’s not exactly like your picture, but it fl ies, goes really fast,

has adjustable wings, engines, a cockpit, missiles, landing gear—the works.” Collaborative

discussions yield a common understanding of what they’ll get, and then we go to the pro￾verbial big bucket of LEGO to get started.

What do we fi nd? An unorganized morass of all sorts of pieces. We start with the best

intentions, but we must build it fast. We dump out all the LEGO on the fl oor. We grab

pieces fast, and assemble a design. We have the best intentions, but we make compro￾mises and uninformed decisions. Over many projects, we end up with a fl eet of ships that

sorta, kinda, look and feel the same. Or, more likely, they don’t.

LEGO even goes so far as to clearly instruct us to start with two critical steps before put￾ting any pieces together. First, make sure that you’ve got the right environment set up so

viii Preface

that it’s easy to snap each piece into place. For designers, that means using templates

with grids, asset libraries, and more. Second, organize your pieces into piles, fi rst by color

but then those other “special” and miscellaneous piles. For designers, that means creat￾ing categorized, reusable chunks that are easy to fi nd and use.

But what if, by sheer magic, when you dumped out your box, pieces magically aligned into

helpful rows and columns based on color, shape, size, and special use? You could just

glance at the table and grab the piece you need for each step. That’s LEGO nirvana!

A table of near-perfectly organized LEGO pieces, arranged so that you can scan, choose, and use each piece

to quickly build your ship.

That’s usually how I feel when I’m assembling layouts based on reusable page compo￾nents, even if they only solve 70 percent or 80 percent of the overall page design I need.

I’m excited about creating the custom work needed for the last, focused innovation that’s

needed. But I get off to a great start, don’t have to reinvent any wheels, and have a

framework that’s consistent with the overall design system. Your teammates, your

engineers, and—most importantly—your users appreciate this.

Preface ix

This book covers two concepts: designing with components and standardizing an experi￾ence with a component library.

Part I explores design principles and techniques for chunking your design into compo￾nents, and using those components to effectively design rich interactions and communi￾cate them to others. Over the fi rst six chapters, we’ll cover the following:

1. Defi ne. Understand components and how they fi t in the design process.

2. Divide. Break down your page designs into meaningful chunks.

3. Vary. Communicate how a component changes under different conditions.

4. Combine. Assemble components together to form page designs.

5. Reuse. Apply principles for embedding and linking component instances in your

artwork.

6. Document. Create useful deliverables to illustrate component-based designs.

With a solid foundation in component-based design principles and reuse, Part II teaches

you how to build (chapters 7 through 11) and manage (chapters 12 through 15) a library of

reusable component assets:

7. Appraise. Ask all the right questions to make sure you’re ready to invest in a library.

8. Discover. Figure out what goes in—and what stays out of—your library.

9. Organize. Defi ne categories, variations, names, keywords, and more.

10. Setup. Select your software tools, create templates, and decide conventions.

11. Build. Create each reusable chunk and package them up for everyone else.

12. Administer. Know your role as librarian, and be ready to curate the collection.

13. Guide. Document the role each component plays in your experience.

14. Adopt. Execute a planned series of activities so that your library takes hold.

15. Integrate. Transform how your team gets work done using components.

With that in mind, let’s break it down.

Acknowledgments

WITH THE TRUST OF MICHAEL NOLAN and the team at Peachpit Press, this project got

started down the right path. As for my lead editors Valerie Witte (project editing) and

Jeff Riley (development), you kept me organized, the work fl owing, and the mood as light

as it needed to be. To Maureen Forys, Charlene Will, and the rest of the Peachpit team, I

offer a hearty—if also a bit meek—thanks for sharing your keen sense, creating a pol￾ished design, and putting up with me and my pesky “details.” This book is immeasurably

better—less wordy, less one-sided, and more accessible to those who think about compo￾nents less than I do—based on the feedback of my technical editor Austin Govella.

Through my work over the past fi ve years, I’ve been exposed to design and library efforts

across many, many organizations. I’m deeply appreciative to those who have given me the

opportunity to learn, explore, and apply modular principles in ways that led to this book,

including (in alphabetical order): Melinda Baker, Gordon Baty, Holly Beaver, Randall Blair,

Carrie Garzich, David Hewitt, Barney Kirby, Crystal Kubitsky, Lee Fuhr, Livia Labate, Paula

Lawley, Elijah Lovejoy, Tim McLaughlin, James Melzer, Francis Rupert, Marilyn Salzman,

Yann Schwermer, Julia Stewart, Deanne Stock, Janet Wallin, Jim Webb, and so many oth￾ers. Certainly not the least, Robert Fabricant and those with him at Frog Design have infl u￾enced me signifi cantly through their inspiringly creative yet structured design delivery.

To my guest contributors, I send a hearty thanks for your effort. To Todd Warfel, keep

it real. To Joe Lamantia, keep it modular. To Nate Koechley, keep it standard. To Keith

Dufresne, keep rounding corners in wireframes! And to Christian Crumlish, my pattern

foil who provided timely feedback and turned in twice the number of guest contributions I

asked for, keep sharing the faith!

Jennifer Bohmbach, an information architect on Sun.com at the time, approached me

after a conference talk and told me about this “component library” her team built.

Through my work with the incomparable Sun.com and Cisco.com design teams, my belief

in the potential of design systems is forever changed. Andrew Payne, you’re the quint￾essential maverick we can’t do without—never let us designers tell you how it’s done!

Chris Haaga, your colorful quips are exceeded by how you masterfully tune the dials of

standards and creativity to keep the train moving. Martin Hardee, you are the master

evangelist and design director, getting everything—and everyone—to gel in just the right

way. This book would never have happened without my own “Gang of Four.” Thanks for

giving me a ticket to ride your train.

Acknowledgments xi

To be a good designer requires you to be a good communicator, including both pictures

and words. Writing is hard. It takes time. It takes practice. I’ve got a long way to go. That

said, thanks to Maura Stokes, the fi rst manager of my career, who instilled in me the

importance of writing.

To my crew at EightShapes—Dimple, Andy, Jason, and Chris—thanks for your patience

and understanding the many times I had to say “no” to other things to get this book done.

To my business partner and friend Dan Brown, I offer continuous gratitude for our rela￾tionship. I couldn’t have asked for a better, smarter, more patient, and more supportive

colleague, and I appreciate how we drive to make each other better. Thanks for giving me

the room to explore this diversion.

To my mom and dad, thanks for the gifts of education, love, and life.

To my 4-year-old son Liam and 1-year-old daughter Caroline, you bring me bountiful joy by

building up and tearing down LEGO creations, respectively. You remind me that we don’t

always have to follow the directions.

Tina Curtis, my wife, is amazing. Not only did she patiently give me the extra time to focus

on completing this project, but she did so without complaint. She shared my excitement

during the peaks and held my hand during the valleys. I can’t wait for you to read it!

Contents

PART I Component Design 1

Chapter 1 Defi ne 3

Rectangles! 5

For Designers, Engineers, and Everyone Else, Too 9

Components and Patterns 11

Divide and Conquer 16

Chapter 2 Divide 19

Beyond Pages 19

A Design’s Hierarchy 20

Page Chunks 22

Chunks Matter 26

From Sketching to Code 27

Example: Product 31

Example: Article 33

Example: Search Results 35

Example: Portal 37

Notes 38

Chapter 3 Vary 39

Varying Components 40

Variation via Pictures 43

Variation via Words 53

Pictures and Words Together 59

Notes 62

Chapter 4 Combine 63

Assembling Pages 64

Common Combos 70

From Projects to Systems 76

Chapter 5 Reuse 79

The Curse of Embedded Artwork 80

A More Dynamic Design 80

Reuse in Design Software 85

The Essential Links 91

A Culture of Linked Files 95

Unifying Design and Documentation 99

Chapter 6 Document 105

Why Document? 106

Recipes 108

Documenting the Hierarchy 113

Turning Projects into Standards 129

PART II Component Libraries 131

Chapter 7 Appraise 133

Why Create a Library? 134

Are You Building the Right Library? 137

Is Your User Experience Ready for a Library? 138

Are You Ready for a Library? 141

Is Your Design Team Ready for a Library? 142

Is Your Organization Ready for a Library? 143

Is Management Ready to Support a Library? 146

So, Are You Really Ready to Build a Library? 151

Chapter 8 Discover 153

Approaches 154

Library Scope 171

Value 173

Chapter 9 Organize 177

The Component Catalog 178

Categories 183

Variations 186

Examples 191

Codes 193

Names 200

Keywords 200

Chapter 10 Setup 203

Tools 204

Templates 209

Styles 213

Conventions 219

Chapter 11 Build 225

Roles 226

Build Files 227

Time to Build! 230

Pages and Elements 233

Packaging 235

Chapter 12 Administer 241

The Librarian 242

A Component’s Life 247

Updating the Library 250

Publishing 253

Inputs and Feedback 258

Tải ngay đi em, còn do dự, trời tối mất!