Talk:OLPC Human Interface Guidelines

From OLPC
Revision as of 15:12, 22 November 2006 by 81.193.69.91 (talk) (→‎Icons)
Jump to navigation Jump to 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)

The term XO is being used. How does one say XO in speech please? Is there a note anywhere about this? Some languages do not have a letter X. Does one pronounce X as English EX as in expression or as English Z as in the way that the word xylophone is said? It is possible to imagine at least two possible English-style ways to say XO, namely the two syllable EX-O and the one syllable ZO, rhyming with the English word go. Yet many, quite possibly most, of the people using the laptop will not have English as their first language or know any English at all. Would it be a good idea to try to have a common way to say XO which may not necessarily be the way that a native speaker of English would intuitively say it?


Are you going to implement tooltips to the interface? The game "The Movies" has an excellent tooltip feature (they call it bubles), and I recommend you to try the demo just to see it. Here is a shot of the second possible state of the bubbles tooltip in the game, and I can describe more or less these three states like this: Basic, Basic + Important detail(s), Basic + Full Details. The 2nd and 3rd state pop-up after some seconds. if you leave the mouse on the tooltip's object.

Right now, tooltips are not dynamic, they always and only show one thing. It's usually a description (for interface tooltips, program menu entries, etc.), or a name + description (launchers placed in Gnome's panel, for example). System tray icons are starting to show more important functions. When you only have the ability to show and not show a tooltip, I think it diminishes the ability to use a tooltip with greater levels of granularity of importance and details.

I think these dynamic tooltips could be helpfull to use in XO icons, and object's metadata when they are outside the journal, where, I supose, a better interface will exist to show this information. Being dynamic doesn't overload them like KDE currently does, for example (a gigantic square full of metadata).

If all this waiting for more information on the tooltip is nasty, then you could also allow to click on the tooltip itself to speed up the process (as it also happens in the game I mention).

Rollovers Replace Menus

Cursor

Controls