Human Interface Guidelines/Introduction

Introduction

Who Should Read This Document

These guidelines are targeted primarily at developers who are building tools for the OLPC laptop. They provide an in-depth view of the various features of Sugar, the laptop user interface, and focus closely on the parts of the UI that pertain directly to software development and the ways in which applications, embedded into "activities," interact with the operating system.

However, as these guidelines are intended to provide a comprehensive overview of the user interface, these pages should also be of general interest. Hopefully the descriptions of the various UI elements, particularly in the Laptop Experience section, will quench the thirst of all who want to better understand the project and its goals.

How to Read This Document

Undoubtedly, many who have made it to this page have read at least one set of human-interface guidelines in the past. Nonetheless, we strongly request that you read the content of this document in full. Many of the terms contained within will be quite familiar to you, however, we urge you to review them anyway, since our approach to the user experience shifts away from the traditional desktop. As such, this document may introduce some unfamiliar ideas around such otherwise familiar terms that you should consider throughout development.

While we would urge you to read this document once from start to finish, extensive use of both internal and external hyperlinking allows you to peruse its contents at will. Hopefully this will make revisiting particular parts of the guidelines quick and easy, and will allow you to move naturally through the details that pertain most to you.

API Reference
Inline references to related APIs appear throughout.

Additionally, where relevant we have included links to the APIs in order to make the relationship between design and implementation clearer. Please take advantage of this as you develop for the laptops.

 Several have noted that we may need to split these guidelines into several wiki pages due to its increasing length.
 This makes sense for web viewing, but eliminates the possibility of reading straight through the document.  It has been
 written to read from beginning to end, and this format also provides the ability to print it in its entirety, which we
 should certainly support.  We could, of course, reformat the entire document as a .pdf once "finished";  we could also
 just provide a printable page on the wiki that looks as this one does now.  In either case, we have a problem wit
 keeping the two documents in sync after future revisions, but this is surmountable.  Thoughts?