Bureaucrats, emailconfirmed
1,221
edits
→Foundations
No edit summary |
|||
| Line 44: | Line 44: | ||
Learnability is what will be the first thing that comes into your mind if you think about interaction design. Paradoxically it is a principle that is ignored in many products: Industry often uses a lot of functions that dimish learnability and many student projects ignore learnablity and focus on efficiency. | Learnability is what will be the first thing that comes into your mind if you think about interaction design. Paradoxically it is a principle that is ignored in many products: Industry often uses a lot of functions that dimish learnability and many student projects ignore learnablity and focus on efficiency. | ||
You can improve the learnability of your application by learning common principles of design like "visibility" or "consisteny" and by testing your ideas with your users. Material for lerning this will be provided in latter chapters. | |||
====Efficiency==== | ====Efficiency==== | ||
Your product has a good efficency if the user can archive a high productivity. This simply means he/she can do more in less time once it is known how one uses the product. | |||
Efficiency can be archived with optimazing the ways the functions are accessed and with providing additional ways of interaction like keyboard shortcuts. | |||
Efficiency is important, but in my experience it is easiely over-emphasized as one does not need to learn one's own designs and efficient stuff feels just great. But a command line interfaces or gestural interaction are cool and really efficient if you can use it but they need to be explicitly learned before they can be used. | |||
====Savety==== | ====Savety==== | ||
Savety is protecting the user and his/her creations from undesired outcomes. Very basic is that you provide a product that does not crash and destroys the users data by doing so. | |||
You should as well prevent that the user selects data-destroing functions by accident. E.g. putting the "save" and the "close" entry close to each other in a menu will cause data loss: if the user wants to save, he may press "no" after a dialog window appears: "don't bother me now. I want to save my data! What was this dialog window anyway? oooohhhh shit!" - the data is lost, "close" was selected by accident and the dialog window that was dismissed by choosing "no" was the final warning. | |||
Even if you prevent accidental actions the users data is not save. Users may misunderstand the name of an action or just try out what the result will look like. Therefore you should provide an undo-facility. This means the user can do an action and if it turns out that this has been a bad idea it can be undone. This is a great feature that demands a bit of thinking when the code is written but it is worth it. As a side effect your application becomes more learnable as well: users are able to learn by doing without any worries. | |||
==Get to know what your users need== | ==Get to know what your users need== | ||