Deadly Sugar addiction harming OLPC XO laptop

I’ve had the OLPC XO laptop now for several months, and feel I understand it well enough to comment further on it. I’ve spent a lot of time working with it, and feel that it is working as well as an OLPC XO is ever going to work. I’m using a development build of the software, with power management enabled. It reliably dual-boots into XFCE or Sugar, and I’ve installed the applications that I need. On the Sugar side, I’ve made a number of small adjustments, and it does run reliably (it does what it is supposed to, most of the time).

Getting familiar with the OLPC has had its ups and downs. I set out to write a careful, balanced assessment of the device, its software, and the overall program. I thought that it made sense to look at the OLPC from the perspective of an adult user looking for a lightweight computer, vs. a child in a difficult environment looking for an educational device. However, the more I looked into it, the angrier I became about some of the design decisions that have shaped the OLPC, in ways that cripple it for adults and children alike. My conclusions in a nutshell:

• The hardware is great: It is really well-designed and fit for purpose. Not really used to its full potential yet.
• The Sugar user interface is terrible: It is poorly executed (but that is just a timing issue), but worse, it is based on fundamentally wrong assumptions about children, and the way the OLPC will be used. These wrong assumptions are:
  • Children need to have a massively simplified user interface
  • Software needs to be simplified in order to run on limited hardware
  • For most children using the OLPC, this will be the only computer they have access to
• The program has weaknesses baked in: in the way development is run, in the way institutional relations are addressed and others.

Don’t get me wrong: I support the goal of the program. Getting computers into the hands of millions of children, following an educational model that emphasizes exploration and self-direction is a good thing. I am not of the camp that argues that clean water, food, shelter should be emphasized instead. (Those things are crucial – however, insisting that they have to be provided before any educational programs are launched is a mistake.)

However, I think that stubbornness, ideology and arrogance have so influenced the program that it may suffer badly in consequence.

It is possible to save the OLPC program. I think the path to doing this would mean changing the direction of software development to better link with the existing Open Source/Linux movement, and making the OLPC far more inter-operable with the rest of the computing world.

Hardware design

The OLPC hardware design is, in a word, brilliant. At first glance, the impression is of reassuring solidity. There are no major openings visible in the case, ie. it is dust and moisture resistant. The screen hinge seems very solid.

Once powered up, the screen is notable for its quality. It is bright and easily viewable. In its black & white non-backlit mode, the resolution is impressive. It is very comfortable to use as a book reader in bright sunlight.

Wireless performance is extremely good. The XO consistently detects more networks than any computer I have ever used. (Edit: This is not actually true. The XO seems to detect some features of nearby wireless routers as if they were a separate mesh network, hence the network view shows a lot of possible connections. However, these are not “real”). There are issues with the software to manage wireless connections, but the hardware is great.

I have only a few issues with the hardware design, all of them minor:

• It is a bit hard to figure out how to open the laptop at first – it is not obvious that the wireless “ears” have to be rotated to their vertical position in order to unlatch the lid.
• The mouse buttons are labelled “X” and “O”, in addition to two of the game buttons, also labelled “X” and “O”. In many cultures, “X” is the standard notation for “wrong”, while “O” indicates “correct”. (This is why the game buttons carry these symbols: game consoles mostly come from Japan nowadays, where the X/O meaning is implicitly understood.) labeling the mouse buttons this way as well is confusing.
• Lack of Caps-Lock key, and non-labeling of the function keys. I understand that these are not needed under the Sugar front-end, but they are when using the Linux command line, and access to the command line is pretty fundamental to using the XO.

Software design

Sugar is the user interface for the OLPC XO. It supports a very simple, graphical user interface, a new method for managing software applications (“activities”), the ability to share via wireless most of the activities, a communications manager, and a time-based storage manager (“Journal”).

Frankly, I believe Sugar cripples the OLPC for pretty much all of its target constituencies. The main reasons are:

• It is designed around an assumption of limited intellectual ability on the part of its users – it is too “dumbed-down” and prevents a lot of useful, and necessary exploration
• It is designed around the assumption that hardware resources are extremely limited – however, the choice of Python as the main development environment makes it much, much slower than “real” Linux-based user interfaces.
• Sugar isolates the OLPC XO from other computing environments – applications have to be “Sugarized”, ie. modified to run under the Sugar UI, and store all their data in the “Journal”. It is awkward and difficult to exchange data with other computers that don’t share the OLPC’s model for data formats and storage.

I’ll cover each of these points in turn:

The trouble with Sugar
In a nutshell, by trying to be “simple”, Sugar makes using the OLPC slow and cryptic. By now, unanimous feedback from everyone I know who has used it (girls and boys, ages 5 to 60, from skilled programmers to naive users), is that it is confusing and frustrating to use.
The Sugar interface is designed to be super-simple. It does not support multiple windows, rather, each “mode” (neighborhood, friends, home, activity) fills the screen. Simple graphical icons are used everywhere, no text. Functions are basically limited to starting applications, sharing them with other XO users, and retrieving previous activities. On the surface, this sounds fine: simplify functions to the bare essentials.

However, there is a problem with this approach: it limits the ability to learn by exploring the computer. Things like setting the clock, changing the color of the system icon, or the computer’s name, have to be done from the Linux command line. There is no gradual escalation of complexity: you dive straight from Sugar into the world of the Linux command line. Moreover, most of the applications on the XO are considerably more complex than the interface, and require literacy: a Python interpreter, a Smalltalk based authoring system, a modular synthesis environment, to name a few.

Moreover, there are many design elements in Sugar that are just annoying:

• The pop-up window frame, that obscures menus and toolbars. Completely unnecessary, since there is a dedicated button on the keyboard to bring up the frame. Disabling it is one of the most frequent requests from XO users. It made my 4 year old niece give up on the XO.
• Completely modal toolbars and menus. Even when there is enough room, the toolbars and menus at the top of most activity screens are completely modal. For example, in the Browser, if you are looking at the Activity menu, you can’t see the Zoom buttons.
• Network screen. All the various wireless networks detected are shown using an icon – organized randomly. Not even a spatial metaphor – random! The most important things when setting up a network connection are the name of the network and the signal strength. The former is hidden! You have to hover the mouse over every network icon to find the one you want!
• The Journal. All data produced by Activities is kept in the Journal, a chronologically organized data store, that is not readily accessible to the regular file system. This means that Linux apps running on the OLPC behave differently from Activities, and vice versa.

Choice of activities

The activities installed on the OLPC are a real mixed bag. It looks like half-baked implementation of “constructionist” educational approaches, but without a lot of the basics included.
Some of them are very good, others so rudimentary as to be useless. Very few of them seem to capture the attention of a 4, 6 or 10 year old. It is bizarre that a computer intended for children and shipped without documentation includes 3 programming environments, but no typing tutor. The Paint application is limited and almost unusable, odd considering that the perfectly fine and free Tuxpaint exists!
Children are smart – they don’t need Sugar

Finally, there is the basic assumption that the interface has to be dumbed-down to make it accessible to children. This severely underestimates the children! The Hole in the Wall project from India made standard Windows-based PCs with a fast Internet connection available to street urchins – with no guidance at all, they were able to start carrying out practical tasks in a matter of weeks.

Hardware constraints?

From the beginning, one of the major design goals of the OLPC was to take advantage of Moore’s Law, but in reverse: rather than achieve exponentially greater computing ability for the same price, achieve exponentially cheaper computing for a more conservative level of capability.

In order to do this, the OLPC forgoes elaborate graphics and storage capability, and relies on the Linux operating system, which is famously efficient. Much of the initial Sugar design is driven by these constraints.

In practice, however, Moore’s Law has had pretty profound effects: even a $100 (or $188) laptop is pretty good. The OLPC XO is as powerful, and better in many ways, than the laptop I used for work in 1999.

What this means, is that the OLPC is actually able to run pretty sophisticated software, and do it well – as long as it is not handicapped by the Sugar UI. Sugar is mostly written in interpreted Python, which while easy to use (and in theory, modifiable by the user) is not terribly efficient. This makes the everyday experience of using the OLPC XO quite slow and frustrating, and this is attributed to the hardware, which is not true!

Installing an alternative user-interface, like XFCE, is an eye-opener: while not lightning fast, at least things happen in a reasonable time, with feedback to the user. Windows open and close quickly. Using an environment like Processing, you can make reasonably good animated 3D graphics. XFCE, Processing, Java (on which Processing is based) have the advantage of having been honed and optimized by a large community, over a period of several years. The hard work of making them efficient has already been done.
Sugar, in contrast, is still in development, and under considerable time pressure. Hence the choice of Python, to shorten development time, at the cost of crippling the OLPC’s perceived performance. I see a contradiction here – if the goal was to make the most of restricted hardware, why wasn’t a greater premium placed on optimization and efficiency? Why not reach out to projects that had already done a lot of the hard work?

The open-ness argument is somewhat weak as well: a student who is willing to reverse-engineer and modify an operating system in Python (without any documentation!!!) is probably going to be fine with doing that in C.

Stuck in an OLPC ghetto

The most serious problem with Sugar, however, is how it gets in the way of connecting to the broader computing ecosystem. There are thousands of useful, free, Linux applications in the world. They can run OK on the OLPC – except for Sugar! Since Sugar does not support multiple windows, displays are messed up. Applications need to have a Sugar “wrapper” defined in order for them to appear in the task bar and the home screen. Most seriously, they need to be modified to read and write the Journal, not the regular file system.

This makes data exchange with other computers needlessly awkward and difficult. There is (in theory) a way to copy files from a USB drive into the Journal. In practice, this has never worked for me: the Journal sees only the root level of the USB drive, and the copy operation often does not work. If I have a folder of textbooks in PDF format, and want to read them, the process of copying them across is really quite awkward. Someone has written some command-line scripts to copy documents in and out of the Journal – I’m sure it works, but once again you go from Sugar-level basics to late 80’s commandline complexity. What happened to the 20 years of user interface development in between???

The OLPC XO would be considerably more useful if it allowed connecting to other computers via methods more streamlined than the command line. I’ve traveled extensively in Southeast Asia, and South America, and everywhere I went, there was some kind of low-cost computing infrastructure already in place, with Internet connectivity, printing and the ability to play MP3s, Youtube videos and all sorts of other media. Bear in mind that most of the world’s poor children live in cities, and hence are not going to be too far from a place with Internet connected computers. Pretending that this infrastructure does not exist, or at best, that you can “turn other computers into XO school servers” is unrealistic and arrogant. Favelas (slums) in Rio de Janeiro have computer stores and Internet cafes.

Another problem with the Journal is that it assumes that all files stored on the XO are the product of activities, and are best viewed chronologically. This is false: it is highly likely that a child will acquire, and want to exchange with peers, collections of books, pictures, songs, videos, etc organized by themes.

A child who grows up with the OLPC will find it difficult to apply their skills to other computers that they will encounter, and this is a real disservice to them.

Implementation weaknesses

Finally, technical issues around the Sugar interface are significant enough to severely handicap the entire project. First, Sugar is slow, mostly since it is written in Python, an interpreted language. This slowness is enough to cause children to get bored and lose interest. Sugar is buggy, and does not provide enough information to fix problems. A commonly reported problem is of applications that don’t start: the icon will flash as if it is loading, but will never load.
What makes it all worse is that there are realistic alternatives. There has been a lot of work on user interfaces that don’t require a command line over the course of the past 20 years. The OLPC ignores most of this, unnecessarily. The OLPC project is difficult enough without attempting to invent a new (and unnecessary) UI paradigm. Attempting to maintain Sugar will likely be the greatest workload for the project volunteers. Unfortunately, this is not a burden that will be taken up by users: trying to understand someone else’s code is extremely difficult, and any sufficiently skilled coders will want to devote their efforts to more productive fields.

I really think that going with an established Linux windows manager such as XFCE would have been a better option. It would have tapped into a much larger developer community, would have given access to many more features of the machine without reverting to the command line, and would simplify connection to the rest of the computing world. A simplified front end could have been built on top of XFCE. Anecdotally, my experience with 4, 6 and 10 year children and the OLPC suggests that they prefer (in some cases strongly!) a more conventional window-type environment to Sugar! This bears repeating: moving the OLPC XO to a more conventional window manager benefits *all* of its user communities: children, teachers, and adults hoping for a lightweight travel laptop. Performance is better, there is access to a much larger pool of applications, and connection to other computers is made much easier. The major loss is access to the collaborative features of Sugar, which are quite nice.

Finally, there is the file formats issue. Things like MP3, Flash and Java are not supported out of the box because they are not Open Source, and have potentially restrictive licenses. However, it is possible to enable support for all of these, through more-or-less complex installation processes. Proponents of the OLPC argue that instead of MP3, you can use OGG; instead of Flash and Java, use Python. However, MP3, Flash and Java are part of the existing Internet! Refusing to support the once again compartmentalizes the OLPC into its own dead-end.
Technically, the problem is easily solved: set up simple mechanisms to allow the user to install those capabilities. However, the attitude issue is more difficult to solve: the refusal to embrace existing standards seems pigheaded and stubborn. My experiences with Java are especially frustrating: Java runs, and runs well, on the OLPC, however, online documentation is scanty, and the OLPC’s built-in Browse activity seems designed to handicap it. Comments from the developers suggest that they are uninterested in addressing this problem. (Java runs perfectly well outside the Sugar environment, using Firefox and XFCE).

As I said before, the developing world, especially cities, has plenty of computing infrastructure. Whether you like it or not, those computers are full of MP3s, Divx AVIs, Flash games, etc. Refusing to acknowledge that in the OLPC software platform seems shortsighted, and likely to lead to frustration.

The OLPC does have a number of interesting educational applications on board. However, it would have made more sense to develop these independently of the OLPC, and make them available to schools that already have cheap Linux or Windows computers. This way, a child could take projects from the OLPC, and easily work with them, print them or present them on the computers at a school, a home or an internet cafe. Moreover, this would allow the “education” project to be independent of the $100 laptop project. Right now, the only way to do this is by emulation, a process so complex that in the words of the OLPC wiki, “Some people who want to get involved in developing applications for the OLPC are overwhelmed by this complexity. Unfortunately, that comes with the territory.” That, to me, is ridiculous and a cop-out.
Open Source nature of the program

The OLPC program is organized on Open Source principles: that is, all of the code that runs in the OLPC is accessible and modifiable by the user, and covered by intellectual property licenses that guarantee this access. Also, as a consequence, most Open Source projects are “free” (as in beer) as well as “free” (as in speech).

I admire Open Source principles, and feel that they will beneficial to the future development of culture, computing and the Internet. The decision to base the OLPC project on Open Source lines is a good one.

However, there are problems with Open Source, and these have manifested in the OLPC project.

Basically, Open Source works really well when people who have a problem have the skills, and the motivation, to fix a problem themselves. In software, the required skills are programming skills. Hence, problems affecting people with programming skills tend to be fixed quickly, and well. Hence, the stellar products of the Open Source movement are things like operating systems and programming tools (text editors, development environments, compilers).

However, when there is a mismatch between the people with a problem, and the people with the skills to fix it, generally market mechanisms work much better. This is particularly true in technical domains: it is unlikely that a best-in-class C programmer will also happen to be a top-notch photographer, video editor, doctor or elementary school teacher. (I’m not saying it is impossible: it is just very rare). So if you have a problem that can be addressed through software, you can either try to do it yourself, or get the attention of someone with the right skills. Paying people is a pretty good way of getting their attention! Otherwise, and this is the case with most Open Source projects, you depend on the personal motivation of the person who can fix the problem

One argument that is raised against this, is that with Open Source, the “user can fix their own problem”. This is not really true: most users will tend not to have (or want to acquire) technical skills to solve their problem, and in addition, it is very, very difficult to try to find problems and fix them in a project started by someone else. For complex projects such as an operating system, I would argue that the learning curve to understand the existing project and codebase is steeper than the learning curve for a new programing language. Frederick Brown addressed both of these issues a long time ago in his book “The Mythical Man Month”: he found that the best programmers were orders of magnitude more productive than an average programmer, implying that it is better to focus on enhancing their productivity, instead of enabling greater numbers of mediocre programmers; and that it was often better to ditch an existing project and start a new one from scratch, than to try to understand and build upon the previous work.

In the case of the OLPC project, it is pretty clear that there is a core group of developers interested in the development of a new user-interface paradigm. They *are* not motivated by requests from teachers or children that would enhance the pedagogical value of the OLPC. It is also pretty clear that there are not a lot of teachers or children out there in a position to start making changes and enhancements themselves. (This may change over time: however, I have not seen any significant contributions to the OS, UI or activities from outside the core US-based development team.)

I suspect that this is a key factor preventing governments from committing to the OLPC project: they have zero leverage with regard to the development team if they want specific features or functionality implemented, and it is unlikely that they want to invest in training people up to manage a technology that is so boxed-in to its own little world. In contrast, an organization like Microsoft, if faced with a large government order, would be very responsive to requests!

Issues with the OLPC program

Leaders of the OLPC program have often been quoted as saying that this is an “education project”, not a “laptop project”. This is not true, and is one of the biggest problems with the project. (Which, after all, is called the “One Laptop Per Child” project…)

If it really is an education project, why not focus on educational initiatives that can be used regardless of the computing infrastructure available? There are plenty of computers in the developed world, more capable than the OLPC, that are being thrown away every day. Developing a suite of applications and a streamlined, Linux-based OS that runs on them sounds quite worthy, and the development effort could be shared with the OLPC.

The argument against doing this is mostly ideological: the OLPC is based on a “constructionist” educational philosophy that insists that children need to explore at their own speed, with their own personal computer. I think this is a weak argument: most children that I see using computers like to gather around one, and teach/show each other things. Plenty of interaction going on there (that is not replaced by something like the OLPC’s chat functions…)

The OLPC project would be in a much stronger position if it really was an “education project”. Having a core of educational applications and a good free operating system, for which the OLPC XO was just one of many possible platforms, would have been a much stronger argument.

Trying to sell a laptop that locks a government into a very specific educational and technical approach is unlikely to be an easy sell.

Things I like

There are things I like about the OLPC as it stands. The most important are the collaboration capabilities. The OLPC includes the ability to detect and connect to other OLPC laptops automatically, and share Activities. It is fun to make music, write documents, share pictures, and this aspect of Sugar works well.

However, I am not sure that it is “mission critical”. I have used collaboration tools such as Groove and Google documents extensively, and real-time editing, though fun and attention-getting, never really catches on as a common style of working. It is questionable whether children really need this if they are all physically in the same room.
I would be happy to sacrifice realtime collaboration on the OLPC in return for a better level of integration with the rest of the computing world.

The graphic design of the Sugar interface is OK, simple and well-adapted to the size of the screen. However, this can probably be replicated by developing themes and skins for other Linux window managers.

Things I would change

A few changes would make Sugar more functional, and the OLPC a much more practical and useful device:

• Extend support for unmodified Linux applications – ie. have them appear in Sugar, better support for applications that open multiple windows, install from the GUI, etc. This allows tapping into the very wide variety of existing Open Source applications that already exists.
• Acknowledge de-facto web standards – MP3, Flash, Java. Even if you can’t ship them with the OLPC, allow them to be easily installed. This opens up access to audio books, podcasts, existing games and applets.
• Extend the ability to manage the system from the GUI – right now the jump from Sugar to command line is too big.
• Provide a conventional file manager, and allow “activities” access to the regular file system (in addition to the Journal). This is critical to allowing the OLPC to work well in environments where other computers are in use.
• Separate the educational software project from the $100 laptop project. Make it easy to run programs equivalent to the major OLPC activities on other cheap computing hardware: Linux or Windows based computers.

Those changes would allow much better interoperability with the rest of the computing ecosystem, without removing any of the characteristics of Sugar.

A pretty quick way to achieve almost all of these improvements, at the cost of losing the collaboration features, is to just ditch Sugar and replace it with XFCE or something like that. This is one of the most irritating aspects of the OLPC development: that it turned its back on 20 years of UI and software development, and tried to implement a new software paradigm from scratch. This was not necessary, and has isolated the OLPC in its own little Sugar ghetto.