APress - User Interface Design For Programmers (2001).pdf - Inżynieria - darekisap

User Interface Design for Programmers

by Joel Spolsky

ISBN:1893115941

The author of this book proposes simple, logical rules that can be applied without any

artistic talent to improve any user interface, from traditional GUI applications to Web

sites to consumer electronics.

Table of Contents

User Interface Design for Programmers

Foreword

Introduction

Chapter 1 - Controlling Your Environment Makes You Happy

Chapter 2 - Figuring Out What They Expected

Chapter 3 - Choices

Chapter 4 - Affordances and Metaphors

Chapter 5 - Broken Metaphors

Chapter 6 - Consistency and Other Hobgoblins

Chapter 7 - Putting the User in Charge

Chapter 8 - Design for Extremes

Chapter 9 - People Can't Read

Chapter 10 - People Can't Control the Mouse

Chapter 11 - People Can't Remember

Chapter 12 - The Process of Designing a Product

Chapter 13 - Those Pesky Usability Tests

Chapter 14 - Relativity—Understanding UI Time Warps

Chapter 15 - But… How Do It Know?"

Chapter 16 - Tricks of the Trade

Chapter 17 - Designing for the Web

Chapter 18 - Programming for Humans

Shockingly Selective Bibliography

Index

List of Figures

List of Sidebars

User Interface Design for

Programmers

Joel Spolsky

Apress ™

any means, electronic or mechanical, including photocopying, recording, or by any

information storage or retrieval system, without the prior written permission of the copyright

owner and the publisher.

1-893115-94-1

12345678910

Trademarked names may appear in this book. Rather than use a trademark symbol with

every occurrence of a trademarked name, we use the names only in an editorial fashion and

to the benefit of the trademark owner, with no intention of infringement of the trademark.

Editorial Directors: Dan Appleman, Gary Cornell, Karen Watterson

Technical Editor: Allen Holub

Projects Manager: Grace Wong

Copy Editor: Kiersten Burke

Production Editor: Janet Vail

Indexer: Carol Burbo

Compositor: Susan Glinert

Artist and Cover Designer: Karl Miyajima

Interior Book Designer: Diana Van Winkle, Van Winkle Design Group

Distributed to the book trade in the United States by Springer-Verlag New York, Inc.,175

Fifth Avenue, New York, NY, 10010

and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17, 69112

Heidelberg, Germany

In the United States, phone 1-800-SPRINGER; orders@springer-ny.com ;

http://www.springer-ny.com

Outside of the United States, contact orders@springer.de ; http://www.springer.de ; fax +49

6221 345229

For information on translations, please contact Apress directly at 901 Grayson Street, Suite

204, Berkeley, CA, 94710

Phone: 510-549-5937; Fax: 510-549-5939; info@apress.com ; http://www.apress.com

The information in this book is distributed on an "as is" basis, without warranty. Although

every precaution has been taken in the preparation of this work, neither the author nor

Apress 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 information contained in this

work.

Foreword

Dave Winer, CEO, UserLand Software

I remember as if it were yesterday my first experience with a user. I had been developing a

software product for three years, all the while thinking it was easy to use. A friend who had

been listening to me gush about how great it was asked if he could try it. Hesitantly, I said

yes.

I launched the program and we switched seats. I tried to say nothing as he wondered what

to do. The software didn't have anything to say. "What should I do?" he asked. I thought to

myself, "I have some work to do."

This is the moment of truth for any software developer, and one we avoid. In The Soul of a

New Machine , Tracy Kidder tells about the first problem report from "the field" about a

computer system developed at Data General in the late 1970s.The lead developer was

surprised. In his mind the computer was a development project; that real people would try to

use it attacked his perception of his own product.

We all go through this; at a superficial level we think we're designing for users, but no matter

how hard we try, we're designing for who we think the user is, and that means, sadly, that

we're designing for ourselves. Until you prove that it's usable by other people, your software

is certainly not designed for them.

Until you make the shift and let the users tell you how your software works, it simply can't be

usable. Every successful software product is proof of this, as is every failure. How many

times have you installed some software or visited a Web site and wondered, "What does this

do?" Now, understand that other people are asking the same question about your software.

It's a puzzle, to solve it you must figure out how to get your software into a user's mind, and

to learn how to do that, you must learn how that mind works.

Joel's book is a milestone built on a strong foundation of practical experience. He's

absolutely right that user testing is easy.You don't need a lab to do it, although many people

think you do.You just need a computer and a person who doesn't know your software. It's an

iterative process. Do it once, it'll change your whole perspective. Do some engineering. Do it

again with a new person. Repeat the process until the first-time user knows what to do and

can actually use the software to do what it was designed to do.

Joel's book is about more than software design and user-centricity. Once you learn how to

communicate with users through software, it's inevitable that all your communication will

improve. The central "aha" is to realize that other people use your software, and they don't

know what you know, and they don't think like you think they do.

There are some very simple truths in this book, and sometimes the simplest truths can be

most difficult. But Joel makes it so easy! His stories are clear and human and fun. And that

may be the biggest lesson, if you haven't been designing for users, you're not having as

much fun doing software as you could.

I can tell you from personal experience that there's nothing more satisfying as a professional

software developer than to have a product resonate with the market, to have thousands of

people tell you that they couldn't work without your software.To get there, you have to learn

from them as you teach.Yes, your software is great, I believe you, but if no one uses it, it

can't make the world a better place. (Dave Winer, http://www.scripting.com/ )

Introduction

Most of the hard core C++ programmers I know hate user interface programming.This

surprises me because I find UI programming to be quintessentially easy, straightforward,

and fun.

It's easy because you usually don't need algorithms more sophisticated than how to center

one rectangle in another. It's straightforward because when you make a mistake, you can

see it right away and correct it. It's fun because the results of your work are immediately

visible.You feel like you are sculpting the program directly.

I think most programmers' fear of UI programming comes from their fear of doing UI design .

They think that UI design is like graphic design: that mysterious process by which creative,

latte-drinking, all-dressed-in-black people with interesting piercings produce cool-looking

artistic stuff. Programmers see themselves as analytic, logical thinkers: strong at reasoning,

weak on artistic judgment. So they think they can't do UI design.

Actually, I've found UI design to be quite easy and quite rational. It's not a mysterious matter

that requires an art school degree and a penchant for neon-purple hair. There is a rational

way to think about user interfaces with some simple, logical rules that you can apply

anywhere to improve the interfaces of the programs you work on.

This book is not Zen and the Art of UI Design . It's not art, it's not Buddhism, it's just a set of

rules. A way of thinking rationally and methodically. This book is designed for programmers.

I assume you don't need instructions for how to make a menu bar; rather, you need to think

about what to put in your menu bar (or whether to have one at all).You'll learn the primary

axiom which guides all good UI design and some of the corollaries.We'll look at some

examples from real life, modern GUI programs.When you're done, you'll know enough to be

a significantly better UI designer.

Acknowledgments

I would like to thank Gary Cornell at Apress for making this book possible and Allen Holub

for reviewing it.Without the encouragement of Noah Tratt, I never would have started writing

down my experiences in the software trenches, and without the support of Dave Winer and

his public EditThisPage.com system, I wouldn't have had a forum for writing the original

online version of this book. Many thanks also to the hundreds of readers of Joel on Software

( http://joel.editthispage.com ) who responded to the original articles, proposed numerous

corrections and enhancements, and whose frequent fan mail kept me going. I also want to

thank Andrew Kwatinetz at Microsoft who taught me a lot of what I know about UI design;

Ken Dye, who taught me most of what I know about usability testing; and Joseph Roberts,

who taught me all the tricks of localization. I am also grateful to Jared Samet for

proofreading the final document, encouraging me, and believing in me, and my parents, who

made me grow up thinking that all adults write books.

Chapter 1: Controlling Your Environment Makes

You Happy

My first real job was in a big industrial bakery that churned out hundreds of thousands of

loaves of bread every night. The bakery was designed to have six bread production lines.

For every two production lines, there was a dough mixer, which produced these gigantic 180

kg lumps of dough that could be dumped to the left or the right, as shown in Figure 1-1 .

Figure 1-1: The bakery, as designed

Well, this was the design. In reality, Mixer C hadn't been built yet, nor had lines three or five.

So the arrangement was more like Figure 1-2 .

Figure 1-2: The bakery, as implemented

Alert readers will be wondering, "how did the dough get from Mixer B to production line six?"

Well, that's where Wee Joel came in. My job, if you can believe this, was to stand to the left

of Mixer B, then catch these walrus-sized lumps of dough as they flew out of the mixer in a

big bathtub with wheels, then roll the bathtub over to production line six, and using a

winchlike device, heave the dough onto the line. I had to do this once every ten minutes from

about 10 P.M. until 4 A.M.

There were other complications. Line six couldn't really handle 180 kg of dough all at once,

so I had to slice each blob with a giant knife into about ten pieces. I don't even want to go

into how absurdly difficult that was.

APress - User Interface Design For Programmers (2001).pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: