foxfirefey (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
foxfirefey) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_design2010-10-24 12:22 pm
foxfirefey) wrote in dw_design2010-10-24 12:22 pm
Recommended design reading
Cognitive dimensions of notations -- someone at the GSOC gave a great review of these. I'm putting my notes in below the cut, and it looks like there's also a nice printable tutorial.
1. Abstraction Level
If you have wrong abstraction level, users always need to translate into the abstraction level you need.
2. Closeness of mapping
In the kitchen, you have four burners and four valves with no obvious mapping so you always use the wrong one--one way is to shift the burners so the valves line up, or replicate the burner pattern in the valve placement
You are using a control that is far from the thing you are operating.
Depends on the audience and the field.
3. Consistency
Once you've learn one feature, how much do you need to learn to use another feature?
Example: having a right click menu on all items, using the same icons
There's also consistency with the operating system and system settings so users have to learn less and don't have to configure it separately
4. Diffuseness/terseness
How brief or tense your data is -- how much information on each screen do your users need? If you cram too much at once, you need information overload. If you don't include enough, they'll have to click or go out of their way to get it. What is the crucial information? Difficult decision. Need to do some testing.
5. Error-Proneness
How easy is it to make an error.
Design the interface in such a way that it's not even possible to make the error. What errors are possible, how can you avoid them?
Example: typing in a filename as opposed to dragging an icon to the trash
6. Hard mental operations
Example: resizing where the user has to calculate height/width proportions by themselves. Can have a input field for aspect ratio, or maintain ratio, etc
What data does the user have, what are you asking for? Ask for the data the user has, not modified version of it, so you avoid hard mental operations. Looking for something is a hard thing--for instance, in icon example, finding the file can be harder than typing
7. Hidden dependencies
Make dependencies obvious -- display things close together if possible so that you don't have situation where you change something and come back to your work to find other things changed completely. XML is very bad for thing for humans.
8. Juxtaposition
Example: diffs, because programming languages don't have this feature on their own
Remember what your users actually care about, make similar things close together
9. Premature commitment
Don't ask users for information they don't know yet--makes situations where the user has to go BACK to change previous information to match what they want later
With systems like LaTeX, you have to specify things like the width of margins before they see the document--can be hard unless they come with the specifications--would be better if the user could edit those margins when they are viewing
10. Progressive evolution
Connected, displaying partial results even when you don't have all the data yet
Example: you should display some circle if they give a position even if you haven't been given a radius yet
Bad example: programming languages
11. Role expressiveness
Is the role of each component obvious as part of the whole solution?
12. Secondary notation
Allows users to input things that don't matter to the computer for their own reminders -- example, comments in source code
13. Viscosity
How hard is it to change something once it's already done? Easier to edit is better.
14. Visibility
Is the information users need displayed? Is it displayed in the format the user needs?
1. Abstraction Level
If you have wrong abstraction level, users always need to translate into the abstraction level you need.
2. Closeness of mapping
In the kitchen, you have four burners and four valves with no obvious mapping so you always use the wrong one--one way is to shift the burners so the valves line up, or replicate the burner pattern in the valve placement
You are using a control that is far from the thing you are operating.
Depends on the audience and the field.
3. Consistency
Once you've learn one feature, how much do you need to learn to use another feature?
Example: having a right click menu on all items, using the same icons
There's also consistency with the operating system and system settings so users have to learn less and don't have to configure it separately
4. Diffuseness/terseness
How brief or tense your data is -- how much information on each screen do your users need? If you cram too much at once, you need information overload. If you don't include enough, they'll have to click or go out of their way to get it. What is the crucial information? Difficult decision. Need to do some testing.
5. Error-Proneness
How easy is it to make an error.
Design the interface in such a way that it's not even possible to make the error. What errors are possible, how can you avoid them?
Example: typing in a filename as opposed to dragging an icon to the trash
6. Hard mental operations
Example: resizing where the user has to calculate height/width proportions by themselves. Can have a input field for aspect ratio, or maintain ratio, etc
What data does the user have, what are you asking for? Ask for the data the user has, not modified version of it, so you avoid hard mental operations. Looking for something is a hard thing--for instance, in icon example, finding the file can be harder than typing
7. Hidden dependencies
Make dependencies obvious -- display things close together if possible so that you don't have situation where you change something and come back to your work to find other things changed completely. XML is very bad for thing for humans.
8. Juxtaposition
Example: diffs, because programming languages don't have this feature on their own
Remember what your users actually care about, make similar things close together
9. Premature commitment
Don't ask users for information they don't know yet--makes situations where the user has to go BACK to change previous information to match what they want later
With systems like LaTeX, you have to specify things like the width of margins before they see the document--can be hard unless they come with the specifications--would be better if the user could edit those margins when they are viewing
10. Progressive evolution
Connected, displaying partial results even when you don't have all the data yet
Example: you should display some circle if they give a position even if you haven't been given a radius yet
Bad example: programming languages
11. Role expressiveness
Is the role of each component obvious as part of the whole solution?
12. Secondary notation
Allows users to input things that don't matter to the computer for their own reminders -- example, comments in source code
13. Viscosity
How hard is it to change something once it's already done? Easier to edit is better.
14. Visibility
Is the information users need displayed? Is it displayed in the format the user needs?
no subject