Talk:OLPC Human Interface Guidelines

From OLPC
Revision as of 15:20, 6 November 2006 by Orospakr (talk | contribs) (Key Design Principles)
Jump to: navigation, search

Introduction

General Comments

The page needs copy-editing. "apply this principal" [principle]; "it's" for [its], etc.

Who Should Read This Document

How to Read This Document

Internal hyperlinking

external links to API

The Core Ideas

Activities, Not Applications

Instead of "much more than a semantic difference in the naming convention" say "much more than a difference in the naming convention" since semantics is about meaning, not naming. Nitpicker 21:26, 27 October 2006 (EDT)

Collaboration

Creation

"the best way to learn how to write a program is to write one" or perhaps to teach someone else how to write one. The aphorism that those who cannot do it teach it instead is false and pernicious. Nitpicker 21:26, 27 October 2006 (EDT)

"apply this principal" -> "... principle" Nitpicker 21:26, 27 October 2006 (EDT)

Journaling

Design Fundamentals

Know Your Audience

Inexperienced 
Young 
International 

Key Design Principles

Respell article section title to match this one. Nitpicker 23:22, 27 October 2006 (EDT)

Performance
Usability
Simplicity
Reliability
Adaptability
Interoperability
Mobility
Exposability
Accessibility

Add

Efficiency
Do not require the user to enter more data or commands than are needed to accomplish the task at hand. The GOMS method predicts the time for a given design pretty well, although user testing is, of course, the ultimate comparator between designs.
Recoverability
One can be more bold if one knows that ones work will not be lost by virtue of some mistake. This suggests a robust UNDO facility and argues against the usual editing feature that highlighting a section of text deletes it when new text is entered. Thus, a forgetful user can lose a paragraph or a page or more inadvertently even when the highlighted section is off screen and thus invisible. Better to require the extra keystroke to make the deletion always explicit and never implicit.
Modelessness
Command gestures do not change meaning (at all). Since modal dialog boxes make all other command gestures fail completely, they should never be allowed. To add insult, such boxes with only one choice available have purely negative utility.

[This is in contrast to applications with multiple text editor functions inside, all different, so you can't spell check a file name, for example.]

Monotony
Only one way to do any given task. [No need to stop to decide which way to do it.]
Transparency

Well-commented and accessible code is all well and good, but:

  • language keywords are based on English;
  • identifiers throughout the activity and libraries are also likely to be English;
  • the comments are likely English (or some other language).

All this means that someone will always require at least basic English as a prerequisite. This is gravely unfortunate. Some even consider this sort of thing to be a tool of "cultural conquest", which is a very disturbing thought indeed. Alas, I have no suggestions to even begin to solve this problem. Andrew Clunis


See "The Humane Interface" by Jef Raskin for more detailed and science based discussion of a full range of user interface issues. He also started the Macintosh project at Apple and thus began the Graphical User Interface craze that is still with us. Nitpicker 23:22, 27 October 2006 (EDT)

The Laptop Experience

Introduction

Zoom Metaphor

With millions of years of successfully navigating back to the nest built in to our genes, geographical navigation is so natural that good implementations of zooming make systems which can be learned in literally less than one minute of training. This was a measured result for the hospital information system mentioned in Jef Raskin's "The Humane Interface" for novices. For computer experts, the measured result was less than two minutes. Nitpicker 23:31, 27 October 2006 (EDT)

The Frame

Bulletin Boards

We should prefer wikis to the usual add-another=message-at-the-end bulletin board since wikis permit continual improvement as well as separating the readable body of information (article) from the often tedious discussion and meta-discussion (talk page) which has a much smaller interested audience. Nitpicker 23:39, 27 October 2006 (EDT)

The Journal

Activities

The Sugar Interface

Input Systems

The Grid System

Icons

Icons may be of some use for pre-literate children, but the research supporting their utility has been vastly misinterpreted. Words alone are far more understandable. If zooming is always available, then there is room for as much explanation as anyone wants in any tiny space near the object of discussion. If hyperlinks are always available, a similar truth pertains. Nitpicker 23:45, 27 October 2006 (EDT)

Rollovers Replace Menus

Cursor

Controls