Talk:OLPC Human Interface Guidelines

Introduction

General Comments

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

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)

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)

Design Fundamentals

Know Your Audience

You're making a mistake! The Younger, the better - not worse!

I was in exactly the same situation 13 years ago (I'm 21 now) - one computer per child isn't only a novel concept in developing countries. I had never used a computer before, I had no idea how to interact with it, blah blah blah (kids don't care about that). ADULTS get may get scared when they have to learn something entirely new. But kids just don't work that way. Kids learn something new every day. And they can learn everything, and probably faster than you can. Note that that's an intelligence factor. Kids aren't dumb, they just think different(TM). Also, they like to learn. Especially stuff adults use. I learned how to use DOS and Pascal 13 years ago, others before me learned the C64 and BASIC. What's wrong with the shell and scripting languages, what's wrong with Gnome? Kids don't need intuitive interfaces. That's why they know how to program the video recorder and you don't. When you grow up you reach an age where you think you know how things work. Beyond that age you'll feel more comfortable using "intuitive" products. Note that intuition differs between people, based upon their individual experiences. So the point is, it's easier to learn complex stuff at a young age. Use that knowledge. Imagine a world where everybody knows how to use a window manager AND the shell. Okay that's a bit too far-fetched. But you know what i mean. A UI like yours is more suited to really old people that never have used a computer before. I'm thinking of a laptop with really big keys...

Please discuss!

Our goal is a low floor and no ceiling. A simple place to start and the ability to drill down as deep as you want into the complexity of the machine; this is why, for example, we have a view-source key and have chosen to build the UI from scripting languages. (And of course, the Shell will be accessible on the Laptop.) That said, just because kids can learn to deal with the complexity of the traditional desktop doesn't mean it is better tool for learning. "What's wrong with Gnome?" It is designed for a larger screen and a bit too resource heavy in its standard configuration. We are using GTK, hence many of the best Gnome features. "Imagine a world where everybody knows how to use a window manager AND the shell." Imagine a world where everyone knows how to reach to complexity through personal expression, where computation is but one form of that expression. ==Walter 21:45, 24 November 2006 (EST)

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.

What is preventing you from implementing universal "undo" and putting an Undo key on the OLPC laptop keyboard?

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

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)

Yes, why is it not possible to implement a completely zoomable interface, as described in THI?

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)

I disagree. First, current implementations of wikis require manual indentation, signing, changing between reading mode and editing mode, and wading through lots of text to find the part you wanted to comment on while reading. Second, wikis allow anyone to change or delete my comments, while I want my comments to stay as I made them. So wikis are collaborative documents, but they are poorly suited to discussion. Firthermore, as I understand, the OLPC bulletin boards will enable messages to be geographically positioned, so that you can put comments about different parts of an image close to the parts.

A much better and more general structure is xanological structure of Project Xanadu. Any piece of content can be referred to, commented on, transcluded and rearranged in other pieces of content, automatically keeping track of the context in which the content originated, as well as the creator, the time, etc. This generalizes HTML links and pages, since you can link to or transclude any piece of content in your "document", not just link to whole documents or transclude images. It generalizes versioning, including the OLPC "journal", since all changes to content in general are stored. It generalizes "objects", as it allows any content to be an object of interest, without being predefined as an "object"; a child would be able to comment on, transclude or modify a part of a story, or part of a song or part of a program. What's more, it makes applications obsolete, so that activities are just bunches of content with some notification mechanism added. It would greatly simplify the whole system, including its implementation, use and understanding by the children. So is it not possible to implement xanological structure for the OLPC laptops, instead of journaling, objects, bulletin boards, a web browser, word processor, and text editor?

The Sugar Interface

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 + Urgent 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.

• This is exactly what we already have in mind, actually. If you note the topic below this - Rollovers - you'll see how we're thinking about it. This section isn't fleshed out in the HIG yet, but we are operating under the same basic 3-state principle: The icon is immediate info, followed by a primary rollover state (which contains the textual name, and perhaps one other detail), and finally a secondary rollover which expands to reveal high detail (such as a thumbnail, a menu with contextual actions, editable metadata, etc.) There is a chart detailing the timing for this sequence available now, and a click will speed it up as you mention. - Eben

== I see, very interesting, something like Sophie's interface, or squeak's. I tried Sophie, and I very much liked the idea of each object showing its own availabe tools. Are you thinking of implementing the more "ordinary" text tooltip for buttons like these? With sophie, each "halo" (in squeak terms) didn't have any text tooltip, which brought me back to a decade ago ("what does this tiny 22-pixel wide icon do??" :) ) But I'm looking forward to trying that out in the future.

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).

Fonts

In section 7.5 of the article, under Fonts is the following.

> ... and also looking into a large-type version of the interface for the younger children.

The large-type version could also usefully be integrated as an option into the version of the interface used for all children as that would allow a child with vision difficulties to be able to use the ordinary system without a special version of the interface needing to be obtained. Would this put too high a load on the software if all laptops had that capability even if it were only used on a few laptops?

Keyboard

I think the symbol you're displaying on the Control key is actually the Alternate or Option icon.