Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology (Anglais) Broché – 10 décembre 2001
Description du produit
Présentation de l'éditeur
Written from the perspectives of both a user interface designer and a software engineer, this book demonstrates rather than just describes how to build technology that cooperates with people. It begins with a set of interaction design principles that apply to a broad range of technology, illustrating with examples from the Web, desktop software, cell phones, PDAs, cameras, voice menus, interactive TV, and more. It goes on to show how these principles are applied in practice during the development process -- when the ideal design can conflict with other engineering goals.
The authors demonstrate how their team built a full-featured instant messenger application for the wireless Palm and PC. Through this realistic example, they describe the many subtle tradeoffs that arise between design and engineering goals. Through simulated conversations, they show how they came to understand each other's goals and constraints and found solutions that addressed both of their needs -- and ultimately the needs of users who just want their technology to work.
Biographie de l'auteur
Ellen Isaacs is a technology design leader at AT&T Labs. She has been designing user interfaces for over 12 years at such companies as Sun Microsystems, Excite@Home, and Electric Communities, where she worked on systems for Palm PDAs, the Web, Windows, and OpenWindows. Active in the human-computer interaction community, Ellen has designed and studied the use of innovative applications that help people communicate, collaborate, and manage their information. She has a Ph.D. in cognitive psychology from Stanford University. Ellen can be reached at firstname.lastname@example.org.
Alan Walendowski is a software engineer at AT&T Labs. He has been writing software for 15 years, working for companies such as Sun Microsystems, 3dfx, IBM, and ComputerVision. A "general purpose" programmer, he has developed device drivers, graphics engines, distributed systems, and user interfaces on various platforms, including PalmOS, Solaris, Linux, and Windows. Alan has a bachelor's degree in computer science from Boston University. He can be reached at email@example.com.
The authors have developed a Web site to continue the discussion started in this book. Please visit www.uidesigns.com to contribute your comments and questions.
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre numéro de téléphone mobile.
Détails sur le produit
Si vous vendez ce produit, souhaitez-vous suggérer des mises à jour par l'intermédiaire du support vendeur ?
|5 étoiles (0%)|
|4 étoiles (0%)|
|3 étoiles (0%)|
|2 étoiles (0%)|
|1 étoile (0%)|
Commentaires client les plus utiles sur Amazon.com
I didn't give it a 5-star only because, to me, the section of their HUBBUB experience and the conclusion was too long and could have been made more concise. Also, it was disappointing to see their product not following their own design goals well enough, which seemed to make the book less effective.
It is written by a UI Designer and a Software Engineer, and takes into account both of their viewpoints. After an initial introductory section to the basic concepts of good UI design, which is very thorough, as any butler should be (read the book to understand), the authors then relate a real-world example in which they collaborated on the design and implementation of a real product. Along the way, they provide some excellent ideas and techniques for how to go about producing a user-friendly user interface that won't take 5 major releases to get right. The product, an Instant Messaging application called Hubbub, is real and can be downloaded for free and installed on any Windows machine or Palm OS handheld. Although not as mature as other IM's out there, it is eminently usable and has some nifty UI features that the current crop don't offer. But it's not necessary to be a Hubbub user to read the book. It's just a nice side benefit for those who would like to give it a whirl.
In keeping with their overall ideas about good UI design, the book is very well organized, easy to read, and has several nice "GUI" features itself. You can tell that the authors themselves probably had a hand in how the book was put together. It is not overly long (about 300 pages), so it doesn't take several weeks to read. Nor is it written in a typical "computer textbook" style. There are plenty of pictures and figures that really help to demonstrate the various points the authors make. It also makes excellent use of color. But perhaps the best "feature" of this book is that it is peppered with "Design Guidelines", each of which sums up in a sentence or two an important aspect of good UI design. And, just to make it even easier, there is an appendix that brings all the design guidelines together in one location for easy reference later on.
Overall, this is an excellent treatment of a subject that probably causes more headaches for designers and engineers than any other in the world of software development. I highly recommend this book for any UI Designer, Software Engineer or Manager who wants to gain a better perspective on the issues involved in designing a user-friendly UI, and, even better, how to go about doing it right. I would not want to embark upon a UI-intensive project unless all parties involved had read this book beforehand.
After reading Ellen and Alan's description of how a UI Designer and a Developer should interact with each other, it just seems so obvious that everyone should work this way. User needs should affect architecture, and technology constrains design--how hard can it be to understand that? But the implications--design and development are iterative, and ongoing user testing is critical to the iterative process--could change the way some people think about programming projects. (The old Specify, Design, Program, Test, Release process seems somewhat naive in retrospect.)
The book has a kind of fun and lively feel to it. It's clear that the authors were having fun telling their various stories, and were excited about illustrating their points. The writing is casual, which made it amazingly easy to read.
On the other hand, once the informal style sold me on the overall approach, I almost immediately wanted a more rigorous treatment. I'd have loved an Appendix that summarized the formats of the various documents, for instance, and perhaps one that reviews the process flow diagram used at the beginning of the later chapters. (As a former academic, I found myself wondering as well about the independence and completeness of the Design Guidelines, too, but that's my quirk. It's probably not an issue most readers would care about.)
I think this book could become one of those that inspires a sort of religious commitment to its vision, and that that would probably be a very good thing.