OLPC Human Interface Guidelines: Difference between revisions
(→Home) |
|||
Line 125: | Line 125: | ||
====Friends==== |
====Friends==== |
||
[[Image:friends.jpg|right|thumb|240px|Friends view]] |
|||
The Friends view takes a small step back from the Home space, opening up the screen to include one's circle of friends. Essentially, this view represents a spatially viewable and editable buddy list. From here one can add or remove friends, and I can also move individuals around, perhaps forming them into logical groups - the four in the lower left corner, for instance, might be my story group. All of my friends receive [[#Invitations|invitations]] whenever I start an activity from the Friends view, making collaboration implicit. Moreover, this view allows me to see what activities my friends are presently engaged in, providing the opportunity to [[#Joining Activities|join]] any non-private activities. Already, you can see how this view fundamentally changes the traditional application launch, allowing us to start new networked activities or join existing ones directly through the OS. |
The Friends view takes a small step back from the Home space, opening up the screen to include one's circle of friends. Essentially, this view represents a spatially viewable and editable buddy list. From here one can add or remove friends, and I can also move individuals around, perhaps forming them into logical groups - the four in the lower left corner, for instance, might be my story group. All of my friends receive [[#Invitations|invitations]] whenever I start an activity from the Friends view, making collaboration implicit. Moreover, this view allows me to see what activities my friends are presently engaged in, providing the opportunity to [[#Joining Activities|join]] any non-private activities. Already, you can see how this view fundamentally changes the traditional application launch, allowing us to start new networked activities or join existing ones directly through the OS. |
||
<br clear="all"/> <!--prevents image pushing title out--> |
|||
====Neighborhood==== |
====Neighborhood==== |
||
[[Image:neighborhood.jpg|right|thumb|240px|Neighborhood view]] |
|||
Zooming out one more step we reach the Neighborhood View, which may be the truest embodiment of the fundamental idea behind the OLPC program. Here we see everyone on the local mesh. However, at this level we are less concerned with the individuals themselves as with the activities they are presently engaged in within the mesh Neighborhood. For this reason, individuals cluster around their active activities in this view, providing a direct visual representation of the number of activities available as well as indicating their popularity, since group size is immediately perceptible. |
Zooming out one more step we reach the Neighborhood View, which may be the truest embodiment of the fundamental idea behind the OLPC program. Here we see everyone on the local mesh. However, at this level we are less concerned with the individuals themselves as with the activities they are presently engaged in within the mesh Neighborhood. For this reason, individuals cluster around their active activities in this view, providing a direct visual representation of the number of activities available as well as indicating their popularity, since group size is immediately perceptible. |
||
This means that, while the Neighborhood view doesn't provide any true spacial or geogpraphical data, it does provide an at-a-glace social geogrpahy of the mesh and its participants. Similary to the Friends view, launching an activity here implicitly opens that activity up for anyone in the Neighborhood to join. While no one receives an [[#Explicit_Invitations|explicit invitation]] in this case, the newly started activity will appear in the view, with its participants clustered about it, so that anyone who wishes to may join. Of course, this also means that the Neighborhood provides an excellent space for exploration. Here, one can both search for, locate and [[#Joining_Activities|join activities]] of interest using a powerful and adaptable [[#Searching|search]] technology, and also interact with and [[#Making_Friends|make friends]] with other children in their neighborhood they haven't yet met. |
This means that, while the Neighborhood view doesn't provide any true spacial or geogpraphical data, it does provide an at-a-glace social geogrpahy of the mesh and its participants. Similary to the Friends view, launching an activity here implicitly opens that activity up for anyone in the Neighborhood to join. While no one receives an [[#Explicit_Invitations|explicit invitation]] in this case, the newly started activity will appear in the view, with its participants clustered about it, so that anyone who wishes to may join. Of course, this also means that the Neighborhood provides an excellent space for exploration. Here, one can both search for, locate and [[#Joining_Activities|join activities]] of interest using a powerful and adaptable [[#Searching|search]] technology, and also interact with and [[#Making_Friends|make friends]] with other children in their neighborhood they haven't yet met. |
||
<br clear="all"/> <!--prevents image pushing title out--> |
|||
====Activity==== |
====Activity==== |
Revision as of 18:57, 1 November 2006
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. 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.
Core Ideas
Activities, Not Applications
Though it might take a little while to get used to, there are no software applications in the traditional sense on the laptop. The laptop user focuses around "activities." This is more than a new naming convention; it represents the intrinsic quality of the learning experience we hope the children will have when using the laptop. Activities are distinct from applications in their foci—collaboration and expression—and their implementation—journaling and iteration.
Presence is Always Present
Everyone has the potential of being both a learner and a teacher. We have chosen to put collaboration at the core of the user experience in order realize this potential. The omnipresence of members of the learning community will facilitate children in taking responsibility for one another's learning as well as their own. The exchange of ideas amongst peers can both make the learning process more engaging and also stimulates critical thinking skills. We hope to encourage this type of social interaction with the laptops.
In order to facilitate a collaborative learning environment, the laptops employ a mesh network that interconnects all laptops within range. By exploiting this connectivity, every activity has the potential to be a networked activity. We aspire that all activities take advantage of the mesh; any activity that is not mesh-aware should perhaps be rethought in light of connectivity. As an example, consider the web-browsing activity bundled with the laptop distribution. Normally one browses in isolation, perhaps on occasion sending a friend a favorite link. On the laptop, however, a link-sharing feature integrated into the browser activity transfors the solitary act of web-surfing into a group collaboration. Where possible, all activities should embrace the mesh and place strong focus on facilitating such collaborative processes.
Tools of Expression
Starting from the premise that we want to make use of what people already know in order to make connections to new knowledge, our approach focuses on thinking, expressing, and communicating with technology. The laptop is a "thing to think with"; we hope to make the primary activity of the children one of creative expression, in whatever form that might take. Thus, most activities will focus on the creation of some type of object, be it a drawing, a song, a story, a game, or a program. In another shift in the language used to describe the user experience, we refer to objects rather than files as the primary stuff of creative expression.
As most software developers would agree, the best way to learn how to write a program is to write one, or perhaps teach someone else how to do so; studying the syntax of the language might be useful, but it doesn't teach one how to code. We hope to apply this principal of "learn through doing" to all types of creation, e.g., we emphasis composing music over downloading music. We also encourage the children to engage in the process of collaborative critique of their expressions and to iterate upon their expression through a process of debugging.
The objectification of the traditional filesystem speaks more directly to real-world metaphors: instead of a sound file, we have an actual sound; instead of a text file, a story. In order to support this concept, activity developers may define object types and associated icons to represent them.
Journaling
The concept of the journal, a written documentation of everyday events, is generally understood, albeit in various forms across cultures. A journal typically chronicles the activities one has done throughout the day. We have chosen to adopt a journaling metaphor for the filesystem as our basic approach to file organization. While the underlying impementation of such a filesystem doe not differ significantly from some of those in contemporary operating systems, it also holds less importance than the journal abstraction itself.
At its core, our journal concept embodies the idea that the filesystem records a history of the things you've done, or, more specifically, the activities you've participated in. Its function as the store of the objects created while performing those activities is secondary, although also important. The journal naturally lends itself to a chronological organization (although it can be tagged, searched, and sorted by a variety of means). As a record of things you've done—not just the things you've saved—the journal will read much like a portfolio or scrapbook history of the children's interactions with their machine and also with thier peers. The journal combines entries explicitly created by the children with those which are implicitly created through participation in activities; developers must think carefully about how an activity integrates with the journal more so than with a traditional filesystem that functions independently of an application. The activities, the objects, and the means of recording all tightly integrate to create a different kind of computer experience.
Design Fundamentals
Know Your Audience
Inexperienced
The goal of OLPC is to provide children with new opportunities to explore, experiment, and express themselves. Many children in need of such opportunities have previously had little or no access to computing, and so will be unfamiliar with the laptop and how to interact with it. This will undoubtedly have effects on some aspects of activity development. On the one hand, it means that developers must focus energy into making interfaces discoverable, wholly intuitive, and building metaphors that strengthen and clarify the interface. On the other hand, since the laptop will the be the first experience of computing for many children, activities do not have to be overly true to legacy behaviors or expectations. This frees developers to innovate.
Young
Many of the children who will receive laptops are just entering kindergarten. Others will be in their young teenage years. Therefore, it is important to develop activities in ways that scale across age levels.
International
The OLPC initiative, by its nature, requires international involvement and participation. Developers must keep in mind the broad range of cultures and languages that the laptops must transcend. In particular, activities should not depend on western icons and modes of thinking, but should abstract ideas to a level that would be familiar to humankind in general, where possible. For instace, consider the camera button on the keyboard. Though one might be inclined to label this key with a small image of a camera and lens, the eye graphic speaks directly to our human capacity for vision, providing a cross-cultural icon that represents the compute's ability to capture what it sees.
Key Design Principles
Low floor, no ceiling.
Performance
OLPC aims at providing extremely low cost machines with battery life far superior to that of contemporary laptops. While the low-cost nature of the laptop doesn't make it an inferior machine, it does mean that developers must make every effort to write efficient code while minimizing memory usage as much as possible. The laptops will run on an AMD Geode GX-500 processor underclocked to 366 Mhz to save power. Additionally, in the absense of a hard drive, each laptop will contain 512 MB of SLC NAND flash for mass storage, including the underlying OS itself. For more detailed information, please view the laptop hardware specifications.
Since these hardware limitations will have a much more noticeable affect on the the number of activities that can run concurrently, the Sugar UI exposes these details directly to the user. The home screen features an activity ring which contains icons representing each instance of an open activity. The size of the ring segment that a given activity occupies represents its overall memory usage, and when the ring fills up no additional activities may be launched until another has been closed to free up resources. Take these limitations into account as you develop activities, since they will have a much stronger impact on the performance of your software on the laptops than on other platforms where advances in chip design and hard drive space have allowed a degree of sloppyness in application development without noticeable performance penalties.
Usability
An important aspect of any user interface, OPLC places extremely high emphasis on this point due to our target audience. The remainder of this document aims to facilitate the creation of usable interfaces, but the specification can't serve as the end all in terms of usability. Usability has everything to do with the actual behavior of the activities, the layout of the buttons and tools, and the feedback that the interface provides to the user through interaction. Ultimately, the design decisions that make your activities usable will depend greatly on the type of activity you're developing, and it will be up to you to consider carefully the kinds of interactions users will expect when presented with it. As a general rule, if the interface provided does what the user expects it to, you're off to a good start. However, since it's quite difficult to know what the user will expect, and in practice not all users will expect the same things, no substitue for user testing will provide enough adequate feedback.
Simplicity
We designed the entire laptop interface from the ground up with a goal of simplicity. While this point relates closely to the above, OLPC desires to single out simplicity as one of our key design goals. It can be quite tempting, and also quite easy, to add an overabundance of features to software. The availability of cycles and memory on other systems exacerbates the software-bloat phenomenon. Therefore, the laptops' hardware "limitations" should actually lead you in a more concise direction and aid in designing for simplicity.
Keep in mind that simple doesn't necessarily mean limited. OLPC hopes to demostrate to the world that simple - even minimal - controls can still have very strong expressive power. Avoid bloated interfaces that do too much, and limit the controls to those immediately relevant to the task at hand. Rather than creating a Swiss Army knife of an activity, think of the laptop itself as the knife, and instead develop a particular tool for that knife that does one thing, and does it very well. When all the activities on the laptop embrace this idea, the true power of the laptop will emerge.
Reliability
Of course we want to avoid instances where things go wrong, and this should be a primary goal for every peice of software. Again, due to our audience and our desire to present a friendly interface, OLPC wants to raise its level of importance. No matter how friendly the message we provide in the case of a systemwide crash, we can't prevent the unfriendliness of a manual reboot. We are committed to ensuring that the reliability of the OS prevents activities from causing system crashes, but even the spontaneous termination of an activity alone breaks the metaphors that the laptops try to embody in the name of kid-friendliness.
Adaptabilty
With the aforementioned goal of reliability and the omnipresent mesh network in mind, adaptability must be carefully considered. Many activities will involve participation from a locally networked group of friends. The mesh network provides an excellent tool for connectivity and collaborative creation even without an internet access point, and is extremely adaptable in itself due to the nature of such a network. However, this also means that signal strengths, and therefore bandwidth, may fluctuate, and at times activity partipants may even drop off temporarily. Activities should handle these cases with care. Temporary loss of connectivity should be handled silently, and reconnection of an individual to an activity they were previously participating in should happen with no noticeable side-effects. On the other hand, unintentional disconnection of individuals from networked activities due to unforseen reasons should likewise be handled in the simplest way at both ends of the connection. Detailed guidelines for collaborative activities reside in the Laptop Experience section.
Of course, though network adaptability is of utmost importance, other forms of adptability should also make thier way into activities. For instance, activities should have the ability to accept forms of user input that may not match the develper's expectations. In the end, writing adaptable code will do a good deal for making the code reliable.
Recoverability
Interoperability
Mobility
Transparency
OLPC also hopes to encourage the children using the laptops to explore the the technology under the surface. Towards this end, a view source key has been added to the laptop keyboards, providing them with instant access to the code that enables the activities that they use from day to day. This key will allow those interested to peel away layers of abstraction, digging deeper into the codebase as they learn.
To enable such layered exploration, OLPC has written much of what can be in Python, a scripting language, to enable children to view the source code. This means, aside from general good practice, code should be both readable and well commented. The [PEP 8] style guidelines for Python provide an excellent resource, and OLPC recommends that developers follow the practices layed out therein unless a compelling reason not to exists.
Accessibility
The Laptop Experience
Introduction
Before you begin developing activities, it is important to understand OLPC's goals for the laptops as well as the metaphors and interactions that are already in place in the OS itself which attempt to fullfil them. Understanding the ways in which the core elements work will provide insight into the overall feel that the laptops should have and the ways in which activities can integrate smoothly with the rest of the system and, just as importantly, with other activities.
Most are familiar with the traditional desktop metaphor that drives the modern day PC experience. This metaphor has evolved over the past 20 years or so, giving us distinct classes of interface elements that we expect to find in every OS: desktop, files, folders, windows, etc. While this metaphor makes sense at the office, and perhaps even at home, it doesn't translate well into a collaborative environment such as the one that the OLPC laptops will embody. Therefore, we have adopted a new set of metaphors that emphasize community. In order to understand the new metaphors in place on the laptops, you must understand the correlations between the Sugar UI and those of traditional desktops, while noting the clear distinctions which distinguish Sugar from them. The remainder of this section highlights the following correspondences, illustrating the reasoning behind our shift in perspective and detailing their functionality with respect to the overall laptop experience.
- Desktop : Neighborhood
- Menubar : The Frame
- Hierarchical Filesystem : Journal
- Applications : Activities
- Files : Objects
Zoom Metaphor
Home
Of all the zoom levels, the Home view relates most closely to the traditional desktop. As the first screen presented to the user at startup, it serves as a starting point for the exploration of both the mesh network and also of the activities and objects that belong to him/her. From this familiar screen, one may either back up first to a circle of Friends, and beyond that to a view of the entire mesh Neighborhood, or instead zoom in to focus on a particular Activity.
The Home view interface is minimal. In the center of the screen, the XO icon, sporting custom chosen colors, represents the child to whom the laptop belongs. The activity ring surrounds the character, indicating all of the currently open activities. Furthermore, the section of the ring that a given activity occupies directly represents the amount of memory that the particular activity requires to run, providing immediate visual feedback about the memory contstraints present on the machine, and exposing a means for the user to manage their resources without needing to expose the specific details. Most activity management happens here: starting new private activities, ending current activities, and switching the currently active activity.
When used in conjunction with the Bulletin-Board described in further detail later in this document, the Home view becomes the most direct relationship to a typical PC desktop as a place for keeping things handy: tomorrow's homework, the drawing I'm working on, a favorite song, a reminder to myself to take out the trash.
Friends
The Friends view takes a small step back from the Home space, opening up the screen to include one's circle of friends. Essentially, this view represents a spatially viewable and editable buddy list. From here one can add or remove friends, and I can also move individuals around, perhaps forming them into logical groups - the four in the lower left corner, for instance, might be my story group. All of my friends receive invitations whenever I start an activity from the Friends view, making collaboration implicit. Moreover, this view allows me to see what activities my friends are presently engaged in, providing the opportunity to join any non-private activities. Already, you can see how this view fundamentally changes the traditional application launch, allowing us to start new networked activities or join existing ones directly through the OS.
Neighborhood
Zooming out one more step we reach the Neighborhood View, which may be the truest embodiment of the fundamental idea behind the OLPC program. Here we see everyone on the local mesh. However, at this level we are less concerned with the individuals themselves as with the activities they are presently engaged in within the mesh Neighborhood. For this reason, individuals cluster around their active activities in this view, providing a direct visual representation of the number of activities available as well as indicating their popularity, since group size is immediately perceptible.
This means that, while the Neighborhood view doesn't provide any true spacial or geogpraphical data, it does provide an at-a-glace social geogrpahy of the mesh and its participants. Similary to the Friends view, launching an activity here implicitly opens that activity up for anyone in the Neighborhood to join. While no one receives an explicit invitation in this case, the newly started activity will appear in the view, with its participants clustered about it, so that anyone who wishes to may join. Of course, this also means that the Neighborhood provides an excellent space for exploration. Here, one can both search for, locate and join activities of interest using a powerful and adaptable search technology, and also interact with and make friends with other children in their neighborhood they haven't yet met.
Activity
Moving in the other direction from the Home view, we find the Activity view. This view contains the heart of the laptops, since this is where nearly all of the actual creation, exploration, and collaboration takes place.
The Frame
Bulletin Boards
Spatially Contextual Chatting Interface
Environment for Sharing
View Source
The Journal
Activities
Standard Mode
E-Book Mode
The Sugar Interface
Input Systems
The Grid System
Icons
Color
The basic color scheme for the laptop is constrained by the need to work in both color (backlight mode) and grayscale (reflective mode); thus we have chosen guidelines that ensure at least some achromatic contrast under all conditions. Further, sustained legibility of text is accomplished by a combination of colors whose achromatic contrast is large and whose chromatic energy is of low to moderate level. For this reason, we are striving for achromatic contrast of at least two Munsell value steps.
The default value for the Frame is N2.5; the default value for the background is N9. Therefore, to maintain sufficient contrast, the line values for icons that appear on both the Frame and the background should range between N5 and N7. The interior fill of those icons should maintain achromatic contrast with the line value, e.g., the fill color for an icon with a line value of N5 should be either ≤N3 or ≥N7.
Fonts
Once we understand the relationship between pango.SCALE and point size, we'll have a more deterministic set of guidelines for fonts. The display is 200DPI. One point is 1/72 inch or just less than 3 pixels. Hence a 12pt font would be roughly 36 pixels. We are settling on a default size for Sugar menus (using Bitstream Vera Sans) of an 11 pixel x height; 13 pixel ascender height; and 5 pixel descender height. In terms of that that is in point size on the actual display, I'd say it is about a 9 point font (it was a 19 point font in Illustraor on the Mac). It is quite legible. We will be looking at other faces, e.g., Arabic and Thai, and also looking into a large-type version of the interface for the younger children.