Bureaucrats, emailconfirmed
1,221
edits
IFD:Course Interaction Design (view source)
Revision as of 17:14, 12 November 2010
, 12 November 2010no edit summary
No edit summary |
|||
| Line 4: | Line 4: | ||
Licence: | Licence: | ||
This work is | This work is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported. | ||
[http://creativecommons.org/licenses/by-sa/3.0/ http://i.creativecommons.org/l/by-sa/3.0/88x31.png] | [http://creativecommons.org/licenses/by-sa/3.0/ http://i.creativecommons.org/l/by-sa/3.0/88x31.png] | ||
| Line 96: | Line 96: | ||
====Safety==== | ====Safety==== | ||
Safety 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 work by doing so. | Safety 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 work by doing so. | ||
===Simplicity=== | ===Simplicity=== | ||
| Line 389: | Line 383: | ||
Not offering feedback will confuse and frustrate users - immediate and well designed feedback will make them feel good as they feel in control of the system. | Not offering feedback will confuse and frustrate users - immediate and well designed feedback will make them feel good as they feel in control of the system. | ||
===Modeless Design=== | ===Modeless Design=== | ||
| Line 403: | Line 396: | ||
Very often you encounter modal dialogs. They pop up in front of your main window and block the interaction with it. So clicking the main window will have a different result that usual and it is: nothing. This is especially bad if the modal window just is a notification that something worked or not. | Very often you encounter modal dialogs. They pop up in front of your main window and block the interaction with it. So clicking the main window will have a different result that usual and it is: nothing. This is especially bad if the modal window just is a notification that something worked or not. | ||
Modal notifications can be turned into non-modal ones as a bar that slides into the window from above ("infobar"), Modal windows for editing (like the depicted font- | Modal notifications can be turned into non-modal ones as a bar that slides into the window from above ("infobar"), Modal windows for editing (like the depicted font-dialogue above) can be often realized as sidebars. | ||
Modes should be avoided. E.g. introducing a navigation mode- and editing mode will just confuse your users. Make the different functions available without the demand to enter a mode. If there is no way to avoid a mode, indicate clearly and visible that the mode is triggered and how the user can escape the mode. | Modes should be avoided. E.g. introducing a navigation mode- and editing mode will just confuse your users. Make the different functions available without the demand to enter a mode. If there is no way to avoid a mode, indicate clearly and visible that the mode is triggered and how the user can escape the mode. | ||
Besides of modes there are other conditions that can cause errors and problems. The following chapter will explain more. | |||
===Preventing Errors and Dealing with them=== | |||
"To Err is human" states Don Norman in his famous Book "The Designs of Everyday things". A good design should not leave it up to to the user to care that his or her actions does not destroy data or have any other bad results. | |||
[[File:SicherheitNutzerdaten.png |thumb|150px| "Close" and "Save" close to each other: not save!]] | |||
Many errors are ''slips'' that happen while performing the intended action but messing it up on the way. 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 hit close instead. The next slip can happen right after this: Out of habit the user can press "no" after a the "do you really want to..."-dialogue window, that was not expected. "don't bother me now. I want to save my data!" - and the data is lost, "close" was selected by accident and the dialog-window that was dismissed by choosing "no" was the final warning. | |||
[[File:UndoRedo.png|thumb|150px|undo-redo-buttons]] | |||
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. | |||
There are sometimes errors that derive from the way the technology that is used. E.g. if an application syncs files via a network and the network can not be accessed, the application can not work as intended. Many applications show error messages in a case like this: "IP Level 3 Error! Syncing process failed". This will trouble the user: The Message uses system oriented terms that are only understandable for programmers and the user does not know how to solve the problem and does not know what happened to the data. A good error message uses simple and known terms and helps the user to recover the problem. This could look like this:"It seems that the necessary network connection is not available at the moment. Please put in your network cable or establish a wireless connection and try again to sync. Click the help button for further information". But before we consider that, we should make up our mind if it would be possible to make the system handle the error: The syncing actions could be remembered, the application could check if the problem is just because there is no network connection at the moment and that inform the user that the files will be synced later. | |||
==Get to know if your ideas work!== | ==Get to know if your ideas work!== | ||
===User Interface Design Heuristics=== | ===User Interface Design Heuristics=== | ||