Human Interface Guidelines/Design Fundamentals/Key Design Principles: Difference between revisions
No edit summary |
Hryanjones (talk | contribs) m →Accessibility: Broken link -- found what appears to be a decent replacement. |
||
| (One intermediate revision by one other user not shown) | |||
| Line 13: | Line 13: | ||
====Usability==== | ====Usability==== | ||
OLPC places an emphasis on discoverability and usability due to our [[Human_Interface_Guidelines/Design Fundamentals#Know_Your_Audience|target audience]]. Usability has everything to do with the actual behavior of the activities, the layout of the buttons and tools, and the feedback that the interface provides to the children when they interact with it. Ultimately, the design decisions that make your activities usable will depend greatly on the type of activity you are developing, and it will be up to you to consider carefully the kinds of interactions that the children will expect when presented with it. As a general rule, if the interface provided does what the child expects it to, you are off to a good start. However, since it is quite difficult to know what they will expect—and in practice not all children will expect the same things—there is no substitute for user testing. | OLPC places an emphasis on [[Discovery|discoverability]] and usability due to our [[Human_Interface_Guidelines/Design Fundamentals#Know_Your_Audience|target audience]]. Usability has everything to do with the actual behavior of the activities, the layout of the buttons and tools, and the feedback that the interface provides to the children when they interact with it. Ultimately, the design decisions that make your activities usable will depend greatly on the type of activity you are developing, and it will be up to you to consider carefully the kinds of interactions that the children will expect when presented with it. As a general rule, if the interface provided does what the child expects it to, you are off to a good start. However, since it is quite difficult to know what they will expect—and in practice not all children will expect the same things—there is no substitute for user testing. | ||
====Simplicity==== | ====Simplicity==== | ||
| Line 68: | Line 68: | ||
* Providing an enlarged print/icon option for folks whose vision is less than 20/20 (but who still can see things that are somewhat enlarged - e.g. 18 point fonts) | * Providing an enlarged print/icon option for folks whose vision is less than 20/20 (but who still can see things that are somewhat enlarged - e.g. 18 point fonts) | ||
* Using the keyboard without needing to press more than one key at a time (all modifiers must work with AccessX functionality) | * Using the keyboard without needing to press more than one key at a time (all modifiers must work with AccessX functionality) | ||
* Supporting programmatic access to the GUI (which for us will mean supporting [http://developer.gnome.org/ | * Supporting programmatic access to the GUI (which for us will mean supporting [http://developer.gnome.org/atk/2.0/atk.html ATK] in Sugar and all activites) | ||
* Either shipping with some number of assistive technology applications (is a screen reader an "activity"?), or making them easy to download | * Either shipping with some number of assistive technology applications (is a screen reader an "activity"?), or making them easy to download | ||
* Providing some way for a user to discover accessibility support and enable what they need (Windows XP & Vista offer an "accessibility wizard" for this purpose; we don't have good upstream technology from GNOME we can take for this unfortunately; the Ubuntu accessibility folks are perhaps furthest along in thinking about this) | * Providing some way for a user to discover accessibility support and enable what they need (Windows XP & Vista offer an "accessibility wizard" for this purpose; we don't have good upstream technology from GNOME we can take for this unfortunately; the Ubuntu accessibility folks are perhaps furthest along in thinking about this) | ||