adayinthe - Prototyping: A Day in the Life of an Interface...

Info iconThis preview shows pages 1–6. Sign up to view the full content.

View Full Document Right Arrow Icon
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 2
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 4
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 6
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Prototyping: A Day in the Life of an Interface Designer AS ONE OF THE FIRST icon and window graphics designers for graphical Annette Wagner interfaces, I have used some pretty archaic computer tools over the years. Product Engineering Even today, I still use paper and pen for design in addition to my computer Apple compmer' ’"C' tools. I am not a programmer, though I do extensive prototyping. Given that, how would life change if I had the “perfect” prototyping tools just for me? Well, look over my shoulder for a moment and I will show you my “perfect world.” i am a Macintosh interface designer in a meeting with a project team Working out the interface for a drawing application. The team includes a Product manager, software engineers, and writers. As the meeting pro- gresses, the team is working on the interface for an alignment dialog that interactively shows how objects will align on the screen. Everyone gets into the discussion, waving hands, drawing on the shared electronic Whiteboard, and describing behaviors and layout verbally. My electronic drawing pad is in front of me, and I can rapidly sketch the ideas from the meeting on the pad with a stylus. One part of the shared “'hiteboard mirrors what I draw on my pad, so that the team can see what I have so far. The pad has a complete palette of tools, including customized Pelettes of interface elements that can be drawn on the pad to create Wlnd0Ws and menus. I can use the faint grid to line things up to, or I can 79 F~.,J, “The 4,1- ’7: Hum ~Canu-p-«tr Ia'l’I-el-tte $0331» ” Smut; L .fiuwhy. 114(1an hag/C: “in 80 | PROTOTYPINC draw where I will on the page. There are as many pages as I might need to draw on; a click on the page corner flips through the pad to a new page or back to a previous page. When the meeting is over, I return to my office, download the drawings I have made in the meeting, and fire up my prototyping environment. Objects from the drawings can be selected and grouped together. Squares can be replaced with windows. Icons can be added to demonstrate a particular idea. A “zoom close” animation can be scripted in. Groups can be linked together in a sequence, can share common information, and can be activated through scripts. Within minutes, the drawings from my meeting have been turned into a visualization. A visualization is a minimalistic prototype useful for demonstrating and capturing ideas. Visualizations provide a mechanism for allowing team members to see a literal representation of what they have been talking about. Initial interface ideas don’t need to be detailed; a simple reiter- ation of ideas in a format that people can see is best. Think of the visualization as a “for example” generator. Many times, seeing an idea that has had only verbal de5cription can enable people to make a better design decision. Visualizations can also be shown to real users to get feedback. Even if the user cannot interact with the visualization, the concept can be demonstrated. ..i "an". sun-uhn-M-fl, _ c “ya .r».-...-.«.-v.- An important benefit is the speed at which new team members can be integrated as a result of the history portrayed by the visualizations. Visualizations require very quick tum-around to be useful. They are linear, with little branching, no interactivity, and little scripting or program- ming. It’s as if you took that napkin you drew on at lunch and turned it into a very simple animation or simulation. The idea is to capture the idea and put it in a format in which it can be examined, and to iterate those steps as many times as possible. ' A month of feverish work has gone by. I have been providing visualizations at every meeting. As the project has evolved, the wealth of visualizations has replaced the written specifications of the human interface. And, because of the variety of ideas produced, the interface is further along than we had , expected and more fun! Now we’re up against our first deadline; the product review is next week. We need to demonstrate the various interface proposals to manage- ment. Back in my prototyping environment, I load up several visualizations and look them over in a reduced “show page” format. I drag pieces of visualizations around on my storyboard to sequence elements and lay out branching. As I put together different elements in this storyboard fashion, I swap in interface graphics from my library and add scripts to make an interactive prototype. The interactive prototype allows team members and users to “try out” the interface and get their hands dirty. The intention is to provide a one— way path that demonstrates how a chunk. of an interface is going to work. For example, the prototype might show a ruler dialog in which most of the dialog works but which is not yet an entire application interface. With an interactive prototype the team can start to “feel” how an interface is going to behave. This level of prototype is fairly hard-wired because turn-around time is still critical. Interactive prototypes have minimal branching and scripting to make the interface seem fairly realistic. There is a library of reusable basic “interface behavior” scripts and interface graphics that can be added as necessary. Prototypes should be easily distributed. Each interactive prototype should end with a “comments window” in which the user can enter feedback on the prototype. The easier it is to gather comments, the more you will get. The more comments you get, the more data you have. This provides a way to test out theories and possible implementations before too much time is invested in a particular idea. The interactive prototypes are done. Before the review, the team hands Out a written specification and a set of interactive prototypes that parallel and demonstrate the specification. rung; 82 I PROTOTYPING Finally, the review is here. With the shared whiteboard, everyone at the review can easily see the interactive prototypes on the room’s large wall screen. The pad can be handed to people for them to try out the protOtype’ or they can try it out on one of the screens embedded in the table. It is easy to get straight to the heart of the concerns, as everyone has a clear concept of what the team is attempting to do. With easy access to the history of visualizations and the interactive prototypes, controversial areas are resolved more quickly and to everyone’s satisfaction. Once the review is past, it is time for the team to iterate the design and begin to focus on the final interface. Soon the team has narrowed down the interface designs to one proposal that encompasses the necessary func. tionality, appears to work smoothly, and is understandable. Or is it? It’s time to do user testing. In conjunction with another member of the project team, I take one of the interactive prototypes and start linking chunks of prototypes together into a user testing prototype. When I’m done, I end up with two user testing prototypes. Next I link in more complex programming modules that give the prototype enough “real” functionality to complete a task. Finally I link in the testing modules to collect data. User-testing prototypes are the most complex prototypes to create, as they require a fairly complete interface implementation and should be some- what robust. Sequences that can be sketchy in the interactive prototypes should be'complete in the user testing prototypes. For example, if the user is expected to swap disks to complete a task, then the functionality for ejecting and requesting disks should be part of the prototype. For some user tests, facilities for collecting different kinds data may be needed. Read the chapter by Kate Gomoll for more on user testing. The main emphasis with this kind of prototype is to build something with which the user can complete a typical task. v This implies an ability to take the interactive prototype and extend it with programming modules to complete the functionality. This includes code to fake behaviors such as disk insertion and ejection, status messages, error alerts, dragging, resizing, scrolling, and even a desktop. User testing is complete and the results have been evaluated. All the hard work of prototyping has paid off. User testing presented us with some surprises, and with a few iterations, the improvements to the interface Will be complete. Now I can devote my time to “filling out” the interface with error messages, final interface artwork, and the other implementation de‘ tails that round out an interface. And someday, the product will ship. Now that you’ve had a chance to see what my perfect tools might be like, you might wonder how I prototype today. n. gimp, Keep in mind as I describe my current tools that I am not a programmer. Tools like MacAppTM and PrototyperTM are beyond my limited programming ability. If I did have a programming background, MacApp would be an excellent object-oriented environment to work in, as it provides routines for standard menus, windows, and so on, and some facility for creating new elements. Prototyper, though not object-oriented, is useful for design- ing standard Macintosh interfaces, but it has no facilities for designing new interface elements. Today I use a variety of tools to produce prototypes. I make drawings and quick visualizations with felt tip pens and pads of marker paper. There is no computer interface yet to compare to this method for capturing ideas in meetings. But once the drawings are on the paper I cannot go back and move the shapes around, reuse portions, or add scripts. The level of integration that allows for easy, fast iteration of ideas doesn’t exist with today’s tools, even though iteration is critical to good interface design. I can capture ideas only as fast as I draw,-and if I am the only one who brings a drawing pad, then I am the only one drawing. Shared white- boards where everyone can contribute would help, but the closest thing to a Commonly available shared whiteboard is a electronic whiteboard that makes copies. And the copies are static. Visualizations need to get into the computer to be useful. I can use a scanner to scan in drawings and visualizations, but most times it is easier to recreate the drawings in a paint application than to turn scanned images . into clean art, especially if I am working in a well-defined interface like the Macintosh. I keep a large selection of ready-to-use interface elements in my computer scrapbook, everything from title bars to trash can icons. Recreating visualizations on the computer slows down the process of pro- totyping, leaving less time for thinking of new ideas. For interactive prototyping, I currently use HyperCard. I can set up a template stack that imitates the Macintosh desktop, complete with a menu bar, gray desktop pattern, and icons. However, HyperCard is not the easiest tool to use to produce prototypes of the Macintosh interface. There are no standard methods for producing menus, icons, windows, or basic behaviors. One can script elements together, but too often extensive knowledge of Programming is needed to make certain behaviors work correctly. HyperCard stacks are easily distributed, and adding in a “comments” Card is a simple task. It is possible to show a user a stack or to produce a PFOtotype stack that someone else can walk through with minimal help. Blit to do substantive user testing, I cannot produce a robust enough HyperCard prototype without extensive scripting and external code. There are no testing modules one can roll in or easy ways to collect data. When I reach the stage of user testing today, I must enlist an experienced pro- grammer to write code to collect data and add minimal functionality. The skill set of an interface designer can encompass programmin graphic design, industrial design, experimental psychology, Cognitive psy. chology, and so on. If we are to support this range of skills, tools must have several entry points. That way, I can use a drawing pad and you write scripts. And, regardless of what tool I use, I will still be able to produce a prototype. ...
View Full Document

This note was uploaded on 10/07/2009 for the course ENSC 12517 taught by Professor Evangraham during the Spring '08 term at Simon Fraser.

Page1 / 6

adayinthe - Prototyping: A Day in the Life of an Interface...

This preview shows document pages 1 - 6. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online