Bureaucrats, emailconfirmed
1,221
edits
no edit summary
No edit summary |
No edit summary |
||
| Line 212: | Line 212: | ||
Metaphors seem to be simply great at the first glance. But they can cause a lot of problems too. They can constrain the user because real world constrains do not apply in the computer. In bad cases the whole interface just follows the metaphor instead of the users needs. This happened in "Microsoft Bob" which was a desktop replacement using a house as metaphor. To access different kinds of applications you needed to go to different rooms. To start the word processor you clicked on a sheet of paper on the desk in the living room etc. The use was cumbersome and unintuitive, so Bob did not succeed. Not as bad as Bob but worth mentioning is the interface of QuickTime 5 that used a wheel to change the sound intensity. So... how do you turn a wheel using your mouse? It turned out that it the usual linear movement worked as well - the same you do when you use a normal slider. | Metaphors seem to be simply great at the first glance. But they can cause a lot of problems too. They can constrain the user because real world constrains do not apply in the computer. In bad cases the whole interface just follows the metaphor instead of the users needs. This happened in "Microsoft Bob" which was a desktop replacement using a house as metaphor. To access different kinds of applications you needed to go to different rooms. To start the word processor you clicked on a sheet of paper on the desk in the living room etc. The use was cumbersome and unintuitive, so Bob did not succeed. Not as bad as Bob but worth mentioning is the interface of QuickTime 5 that used a wheel to change the sound intensity. So... how do you turn a wheel using your mouse? It turned out that it the usual linear movement worked as well - the same you do when you use a normal slider. | ||
Metaphors can ease interaction - but bad metaphors can cause a lot of trouble. It is often better go see if any standard exists - thats what the following chapter is about. | |||
====Resources==== | ====Resources==== | ||
*[http://www.uie.com/articles/design_intuitive/ What Makes a Design Seem 'Intuitive'?] Essay by J. Spool with a great visualisation of the releationship of knowledge and intuitiveness. | *[http://www.uie.com/articles/design_intuitive/ What Makes a Design Seem 'Intuitive'?] Essay by J. Spool with a great visualisation of the releationship of knowledge and intuitiveness. | ||
| Line 329: | Line 329: | ||
===Prototypes=== | ===Prototypes=== | ||
All ways of design above have in common that they can more or less look like the intended product but they don't have any functionality. "Models" of your software that provide functionality are called "Prototypes". They are mainly used for testing your ideas | All ways of design above have in common that they can more or less look like the intended product but they don't have any functionality. "Models" of your software that provide functionality are called "Prototypes". They are mainly used for testing your ideas. | ||
Prototypes are easy to make (especially compared to the final product) and don't waste resources if an idea does not work. Ideas that don't work get sorted out and you can try something new. Because it does not hurt to be wrong you can be creative and find new ways of doing things. | |||
When testing with a prototype you give test participants a task to solve. A prototype needs to simulate the situations that can occur when the participants do the task you gave them. So at least you need to cover the possibilities to resolve the task. | |||
I recommend to build your prototype in paper. It may sound strange but it is easily done, costs almost nothing and usually has good results. The interaction is simulated by manually changing parts of the paper-Interface. E.g. You draw a dialogue box on paper and place it over the rest of the interface if the user triggers the action that shall make it appear. Or if a "link" is clicked you change all parts of the site that are supposed to be different from the old one. | |||
====Materials==== | |||
[[File:PaperPrototyping_Materialien.jpg|right|200px|thumb|Almost everything is in your office already]] | |||
*'''Paper itself''': The core material. You can draw your interface on it, you can apply glue, sellotape etc. and you can stack it and have e.g. consitent background and changing parts like dialogue boxes oir sitebars. Not to mention that it is very cheap. So it is no problem to restart or apply changes. | |||
*'''pens''': You need them to draw your Interface. | |||
*'''Sellotape''':Useful for taping pieces together or to create parts of the interface you can write on with wipable pens. | |||
*'''Transparency Foil:''' Useful if the writing/sketching area for the user needs to be bigger. Can be put on top of the rest of the interface. | |||
*'''wipable Pens:''' They need to be applied on sellotape or foil and are always needed if the interface demands text input. They are as well great for changing parts of the interface. There are dry-wipable and wet-wipable. For the most cases, the latter are better, since they are not wiped of in the testing process as long as you don't do it by purpose using a slighly wet cloth or something like this. | |||
*'''Restickable Glue:''' Make a piece of paper restickable – like post-its, so You can temporarily fixate elements and prevent them from moving. This is very useful. You probably need to order them. Costs ~1,50€ and are worth the money. | |||
====Interacting with a Paper-Prototype==== | |||
<gallery widths=200px caption="Interacting"> | |||
File:PaperPrototyping_manipulation.jpg|the computer changes parts of the interface | |||
File:PaperPrototype_TextInput.jpg|text input via pen | |||
</gallery> | |||
To make your prototype Interactive you need an other person as "computer" who is familiar with the interface and changes the prototype according to the users interactions. Don't try to do a test alone: To change the screens, write notes and communicate with the user will not work in one time. | |||
The users interacts with the paper-prototype by using their fingers like the mouse cursor: If they tap an element this has the results of a mouse click, and the computer changes the interface accordingly. If you have special input modes e.g. right click you can tell the user that this can be told to the computer ("now I right-click") If you need text input you should give the user the possibility for text input via a non-permanent-marker. | |||
==Get to know if your ideas work!== | ==Get to know if your ideas work!== | ||
| Line 339: | Line 362: | ||
For answering your questions you will need to build a prototype. (You can and should test finished products too, but I assume you design) Prototyping is creating a "model" of your software that enables you to try out certain things. Think of building a model aircraft: It will be sufficient to show if an engineers idea will be work in general. | For answering your questions you will need to build a prototype. (You can and should test finished products too, but I assume you design) Prototyping is creating a "model" of your software that enables you to try out certain things. Think of building a model aircraft: It will be sufficient to show if an engineers idea will be work in general. | ||
There are several techniques to create a prototype. You will read about paper prototypes and coded prototypes. Paper prototypes can be made by everybody who can use a pen and scissors. The system responses are simulated by you as you will change the prototype manually. Coded prototypes need to be programmed and are therefore more difficult to make. They can simulate some more things in hi-fidelity and you can test them remotely via screensharing as you don't have to be with your tester as you don't have to change anything manually. | |||
===Choosing a task=== | ===Choosing a task=== | ||
So what shall your testers do with the Prototype? You need to give them some tasks they are going to do. So you should follow some simple steps: | So what shall your testers do with the Prototype? You need to give them some tasks they are going to do. So you should follow some simple steps: | ||
| Line 357: | Line 378: | ||
===Build a Paper-Prototype=== | ===Build a Paper-Prototype=== | ||
[[File:PaperPrototyping_Zeug.jpg|right|200px|thumb|A paper prototype consists of Paper or Cardboard pieces and a few additional materials]] | [[File:PaperPrototyping_Zeug.jpg|right|200px|thumb|A paper prototype consists of Paper or Cardboard pieces and a few additional materials]] | ||
Now as you now what you want to test and how you make this clear to the user, you can build your prototype. | Now as you now what you want to test and how you make this clear to the user, you can build your prototype. | ||
====Ressources==== | ====Ressources==== | ||
* A List Apart on [http://www.alistapart.com/articles/paperprototyping/ paper-prototyping] | * A List Apart on [http://www.alistapart.com/articles/paperprototyping/ paper-prototyping] | ||
* Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder. ISBN 978-1558608702 | * Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder. ISBN 978-1558608702 | ||