Talk:OLPC Human Interface Guidelines

Introduction

General Comments

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

There should be cross-referencing between this guide for Sugar and similar guides for making good accessible content and texts, using clear names and metadata, using clear attribution of your sources and connections to other projects. A more freeform collection of style guidelines that do not apply to sugar under Style guide; the appearahce can eventually be coordinated. Sj talk

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)

This note probably belongs in a more pedagogical part of the olpc wiki world, but I'm dropping it here until I find that better place. As a reminder to developers, the habit of using the word "Activity" this way may have been helpful. As terminology for users -- teachers and students -- it could render normal use of the word "activity" cumbersome.

Example -- a "student activity" of measuring things, looking up information about them, and writing a report involves several "Activities" (programs/apps/whatever). A development "naming convention" shouldn't reprogram a friendly, standard word in the teacher's vocabulary, forcing me to say "task" and "project" when I want to say "activity." (And 'activity' when I mean 'program') Football is an activity. A spelling bee is an activity. A friendly group task is an activity.

"In our next class activity, we will see how to switch from one laptop 'Activity' to another... The 'Activities' we will use..."

I hate to engourage nerdy neologisms, but maybe the xo is unique and deserves some words of its own, possibly "xoactivity" in this case -- "exack" or "zack" for short. Or perhaps if we just get out of the way, useful language will evolve. Robby 10:43, 11 January 2008 (EST)

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)

I hope a kid who tires of the pre-school UI will be able to run all the apps without it. It would be terrible to have the pre-school UI be a requirement for doing classwork and interacting with the mesh network. AlbertCahalan 23:19, 1 March 2007 (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

I wish it were an effective tool of "cultural conquest", because worldwide unification of culture would go a long way toward reducing world conflict. Multiculturalism divides us, which leads to mistrust and misunderstanding, which brings us additional hatred and violence.

two language

I suggest a minimum-two-language approach where the local language(s) is(are) primary in the interface, and English is a universal secondary language. (In places where English is the primary language, the next-most-common language can be added as secondary, e.g. in the US it would be Spanish and in Canada it would be French.) This is consistent with present realities in many cultures and the world at-large.

There is no need to create an implication of domination or conquest; that implication was decidedly not present in the development of the international layout for telephone dials or for that matter the QWERTY layout for keyboards. The implication is not inherent in the object, it is an addition that is deliberately created and associated with the object. Children do not assume power relationships of the adult type any more than they assume sexual symbolisms of the adult type (e.g. kids don't see the lines of a muscle car as implying the depiction of the curves of the female body): these things are adult realities and kids won't "go there" unless adults lead them there; that innocence should be respected. The implication that one associates with the object of a lauguage choice can be one of domination and power differential, or it can be one of simple standardization for the sake of interoperability (whether technical as with telephone dials, or linguistic).

See also Aldous Huxley, _Island_, where his fictional characters in Pala used English for international business and scientific publication, and Palanese for normal daily interactions and for their national literature. Huxley makes clear that neither language is ontologically superior across the board; only that each language is _more useful for specific tasks_. The context that you create for the use of language choices, can convey this spirit of ontological equality and mundane task-related usefulness, and thereby not only respect but reinforce the innocence of kids with regard to power issues, thereby strengthening local cultures.

If you really want to start exploring the cultural implications of implicit assumptions, the place to start is with the sense of *time,* and the idea of *chronological ordering.* Many cultures and many individuals regardless of culture, do not treat time as a linear vector or as a common denominator against which to measure other variables; some "spatialize" and some are acausal, atemporal, or synchronous. The idea of "relatedness by 'position' in time" is a *very* culture-specific assumption. (If anyone is interested, I could do a *lengthy* writeup on this topic, including for example the idea that items would be ordered along multiple axes of relatedness by various types of psychological association: if this interests folks involved in the project, post a reply here with an email address and I'll find it and get in touch.)

(comment by George, 1 November 2007)

i18n

Develop a graphical programming language that's fully internationalizable. Programming constructs (control structures, function calls, methods on objects, variables) are graphical modules that plug together without requiring any particular text syntax, and they display translatable text labels (and all text should be searchable). Variables and method names are just symbols that can have multiple names and documentation attached, translated into different languages. Don Hopkins

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?

The Display

Please do not use a grey background - if possible - ever - white is best for a background and allows optimal contrast and optimal readability in sunlight.

A grey background limits the readabilility of the display in sunlight. Please always use black on white fonts for small print. And color on white for large print. The screen we have devised for the laptop is special, and works both inside and outside - but works best with black on white for small print, and no grey backgrounds.

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

Controls

There is no control for dimensions, i.e. a number and a unit, where both may be changed.

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?

Please use black on white form for small fonts - this will make them most readable in both black and white and color modes. - Mary Lou

Keyboard

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

Some thoughts

I wrote in my blog some thoughts about the UI ideas presented in this document. There are some critics and recommendations, too. The post is here:

http://flosse.dicole.org/?item=100-laptop-s-olpc-s-user-interface-looks-good-but

On quick skimmable display while processing context and connection

I was thinking today about the difference between a quick skimmable display and waiting to launch a new proces, take up cpu and memory and wait to be introduced into a new Activity. I cannot think of many activities in which I don't want that skim and that overview before being immersed - before even choosing to be immersed - in the full-fledged activity. At any rate, the distinction is especially strong in the browser and on a connected network, whether the connections are hyperlinks or shared state or shared network view... where fluidity is essential. --Sj talk 18:50, 4 March 2008 (EST)