OLPC needs a usable GUI (i.e. not Sugar)

[gnu]

The OLPC development team should replace the clumsy Sugar interface. In release after release, it just gets worse. Each problem is compounded by a lack of documentation matching the running software (i.e. you can never tell if it's deliberately designed to be terrible, or merely full of terrible bugs). It's like wandering blind in a Colossal Cave where the only things you can see are cutesy icons that don't react to anything you do. It's so simple that only a one-year-old can enjoy it, i.e. somebody whose idea of a good time is to drool spittle on the laptop and push on things at random. There's no way to do 90% of what ordinary GUIs let you do, and the 10% that is provided is carefully hidden so you'll need a guru on IRC to find it. Assuming you can get the wireless working, and you downloaded your own IRC program, and found out where the browser had stuffed it, and on and on...

Some people probably think that we can just solve each individual problem and things will get better. E.g. Build 303 requires the user to do a complicated undocumented dance before it will let them log in. Yes, this could be solved. But the deeper problem is that the Sugar team continues to invent such obstacles to intuitive use -- and considers them progress. With each release, the laptop becomes harder and harder to use, because the UI designers don't seem to know the difference between easy and hard, between intuitive and inscrutable. The fix is not to keep fixing their errors; the fix is to find designers who have sense, so they stop doing new things that need constant fixing.

Why should kids have to batter their way through this idiocy before they can get to any educational materials? Why does everybody just keep shrugging and apologizing for how rotten the UI is, without doing anything about it? It's true, on paper, Sugar's ideas might have been a brilliant advance in the state of the art, another miracle like the LCD screen, like the power management, like the OLPC business model. But once Sugar was implemented and we could use it, it turned out that it WASN'T a brilliant idea; in fact, it sucked. Face facts! Give it up and get something that works, rather than have it torpedo the project. You'd have a nice machine here if it didn't fight the user at every chance.

Let's move to a window system where the objects on screen are responsive to the user. Where programs are programs, and none of them are jargon "activities". Where you can run more than the twelve apostles that are lined up along the bottom of the screen.

OLPC should abandon Sugar and install a working Linux GUI.

[orospakr]

Hi John,

That assessment is not entirely fair.

Of course it sucks. It's not done yet!

Sugar is prerelease software, and is still in a state of flux.

A traditional desktop environment does not meet OLPC requirements in many respects, including the new collaboration, and storage (Journal) mechanisms. Try retrofitting GNOME or KDE with that.

[orospakr]

(and yes, I agree with the Activity launcher at the bottom the screen being retarded. I think everybody does. There are several ideas already in motion to improve it)

[AlbertCahalan]

Oooooh, them's fighting words. :-)

You're at least half right though.

The whole "activities" thing is dumb. English-speaking kids will be in an environment where everybody else will use terms like "app" and "program". For the non-English-speaking kids, surely there are similar local terms that will be the norm. Perhaps the translators have already undone the error.

Junking the normal Mac-style desktop (copied by Win95, GNOME, KDE...) is a very good idea. If you are running any apps, you can't see the desktop via any logical mechanism. The desktop really should be void of anything, optionally to be decorated by the user.

Junking the task bar and/or virtual desktops was a poor idea. One might do well with one app per desktop; there would seldom be more than one task button on the screen. (thus retaining compatibility with stuff like the gimp)

Full-screen, possibly excepting a task bar, is a good default. It's needed for a 3-year-old or a not-so-bright 4-year-old. It'll annoy a 10-year-old for sure. There should be a window manager to help uncooperative apps go full screen via a fat window border. Example: if an app is 1000x700, you get 100-pixel borders. (minus anything needed for a task bar) Perhaps metacity could be hacked to do this; there could then be an adjustment to free the older kids from the toddler interface.

The collaboration may well go against human nature. My apps are mine! My data is mine! Mere communication is another matter of course; silently passing notes would go over very well.

The Journal storage hasn't been documented all that well, so I'll avoid judging it much, but it sounds like a neat idea that will fail in real-world use.

[marco]

It's really unfair to make such a judgment without even try to make a distinction between implementation limitations and design issues. I'm going to try to extrapolate the few concrete points in your rant...

It's so simple that only a one-year-old can enjoy it

What's the deal here? Does adults need or appreciate complex interfaces? If you are actually complaining about missing features, please be more concrete.

Build 303 requires the user to do a complicated undocumented dance before it will let them log in

Don't blame the design people for it. Dan had to go ahead and implement "something" because he needed some features for the network infrastructure work. Even so, I think the solution on the short would be to just not *require* a picture. But at some point we need to figure out the real design for the intro screen and implement it.

But the deeper problem is that the Sugar team continues to invent such obstacles to intuitive use -- and considers them progress

Now, you are really confusing me. First there is no closed Sugar team, everyone is welcome to join and contribute. Second, as far as I can tell everyone of the people currently involved has been aknowledging the issues when someone raised them. Can you point to a concrete case where this did not happen?

because the UI designers don't seem to know the difference between easy and hard, between intuitive and inscrutable

You are assuming there is a closed group of designers working on Sugar. That's *not* the case, There are design meetings instead, run by a bunch of eterogenous people. Developers, visual designers, project managers. External ideas are always welcome.

Why does everybody just keep shrugging and apologizing for how rotten the UI is, without doing anything about it?

I'm personally spending 16 hour per day, weekends included to do something about it. Unfortunately a lot of people prefer to shrug and rant rather than try to do something about it.

But once Sugar was implemented and we could use it

Now you are confusing me again. What makes you think that sugar is implemented?. I suppose you took a look the HIG before going on with the rant... If not please do and notice how far Sugar is from being implemented.

Let's move to a window system where the objects on screen are responsive to the user.

Please point out concrete cases where the objects are not responsive, post tickets, contribute patches etc.

Where you can run more than the twelve apostles that are lined up along the bottom of the screen.

You are confusing implementation and design. The activities list on the frame is comparable to the launcher icons on the gnome panel for example. It will be still possible to launch every activity you install from the journal.

Where programs are programs, and none of them are jargon "activities"

You guys are really scaring me here. I don't think we expose the term activity at all in the UI. Feel free to call them as you prefer.

OLPC should abandon Sugar and install a working Linux GUI.

Heh, I wonder if you made an effort to be so not concrete? You are not even proposing what we should install...

[gnu]

Here's the classic hubris, straight off the devel list:

> Wouldn't it be better to fix Sugar and Matchbox to handle "normal"
> applications running directly on the real X server?

Not if that involves overlapping windows, no.  The whole point of
classic was for those apps that people, for whatever reason, just _have_
to run that don't deal well with Matchbox, which fullscreens all
non-dialog windows by default.

Which is the behavior we want.  If you're running a legacy application,
you use Classic to do so.  Those legacy applications do not fit into the
Sugar framework.

The problem with having something like Classic is that it's a crutch
that developers can use to ignore optimizing their application for the
OLPC laptop.

Dan }}}

The problem with having something like Sugar is that it requires every application to be "optimized" for it.  It's already hard enough to get every application optimized for a 128MB,
swapless, slow machine.  Shouldn't it be a Sugar design goal that the thousands of ordinary X applications OUGHT to just work, out of the box, over the network, with it?  Why cut off that reservoir of working code?

To answer some of the questions above:

* Complaining about missing features:  I want a web browser that works like Mozilla.  That
can open more than one web page at a time, and do more than one thing at once.  That can download files to ANY ARBITRARY LOCATION OF THE USER'S CHOICE.  That lets me see where a link will go BEFORE I click on it.  That has a scroll bar I can see, and hit.  And that better handles idiotic web pages that assume a particular screen size.  I want a terminal emulator that can open more than one window, and that has some way to switch back to doing something else.  I want a way to switch applications easily.  I want copy and paste.  I want the last twenty years of user interface design, without having to go back and reinvent every wheel individually.

* Unresponsive objects on screen:  The XO that is the only thing on the screen after it boots.
The undocumented triangle that sometimes appears on that same screen.  The application icon
in the top frame.  The right mouse button EVERYWHERE.  The vast majority of keys on the keyboard almost all of the time (except within specific applications).

I showed the XO to someone new last night.  (This happens all the time, people love it.)  When nothing worked in the UI, I had to explain that everything useful is hidden around the edges of the screen where it's hard to find.  People who use it for ten minutes can go, oh, whatever.  They took it as a mystery.

But no developer is actually developing ON the machine, because it's so sucky.  And the kids won't be so lucky.  Eat your own dogfood, Sugar developers; write and edit and debug your code on the XO.  I bet you won't last two days before you run screaming back to a real GUI.  Yet we expect the kids to be able to read and modify the sugar code, on the XO?

[RafaelOrtiz]

Yes, all this critics could be true or not..but in this case the children have the last word, i have been able to perform some tests with children between 6 and 11 years (in my country Colombia) and they only complain about one thing.

Velocity of performance

they dont complain about difficulty or easiness, they just want to explore and to play. if the activities run slowly they get frustrated. i know that sugar is in a very early development stage and i just hope the issues about performance could be solved ASAP, and although i love the sugar concept (journaling and share activities), i think that the the usability issues have to be resolved. I also think that one of sugar main purposes is to give the kids tools and skills to have the capacity for run more complicated tasks like programming (not necessarily to run Kde or Gnome..or menu-like environments)

i hope that this experience can help in some way.

[AlbertCahalan]

Dogfooding is an excellent idea. In case anybody is still unfamiliar with the term, it means really using your own code -- not just "testing" your code.

Linus no longer develops Linux on Minix. The gcc developers compile with gcc, not Visual Studio 2005. X developers don't use NeWS. Microsoft doesn't run sendmail. The bash developers don't use csh, tcsh, or zsh.

I sure hope the sugar developers no longer use GNOME, KDE, Xfce, etc.

[marco]

Yes, all this critics could be true or not..but in this case the children have the last word

I couldn't agree more.

i have been able to perform some tests with children between 6 and 11 years (in my country >Colombia) and they only complain about one thing. Velocity of performance

Thanks for the feedback, it's good to know what are the problems exposed by testing on the target users. And yeah, that's not surprising. Performance is clearly the usability "bottleneck" right now. We are working on it and I hope we will see improvements on this front soon.

I also think that one of sugar main purposes is to give the kids tools and skills to have the capacity for run more complicated tasks like programming (not necessarily to run Kde or Gnome..or menu-like environments)

+1

[jg]

I have *some* sympathy with gnu:

But only some.

Having a 9 and 12 year old (well, he turns 9 tomorrow), I've seen both my kids struggle with both conventional Windoze and Linux desktops. Ages 6-12 is our prime audience.

Conventional desktops are fully usable by kids only after they are able to read decently well (at least in my experience). This should hardly be surprising, as they were designed for adult developed world office workers.

Having dialog boxes of text they can't read pop up in windows that get lost *really* sucks, when you are a parent (or kid). So Sugar is getting to a position where in fact for young children, once we have the performance nailed, I think it will be much better for those kids, particularly on our relatively physically small screen.

On the other hand, there are applications which my 12 year old was experimenting by age 9-10 which exist on Linux that it is unlikely we're going to get "sugarized" to be one window at a time any time in the forseeable future.

We have one way to run these now (by running an entire environment inside an Xephyr X server); the problems with this approach is both memory usage and lack of *any* integration when it comes to cut and paste, and encouraging people in those application communities to start taking our collaborative environment seriously (which we certainly want everyone to do). As kids get older they graduate to more serious applications: just this morning, my daughter just turned twelve was crowing that she could now duplicate everything she'd seen in a Photoshop tutorial in the Gimp).

I don't think this "solution" of a full environment embedded in a sugar activity is adequate in the long run.

Another approach is to use a different window manager than Matchbox, and have sugar and sugar applications sent appropriate window manager hints to get the current behavior: but we could then still run existing applications as well on the one X server and have fuller integration with applications in general. This is the approach I personally believe we need to follow, while not losing sight of the approachability I've seen that conventional desktops so badly fail at.

Walter Bender also would like to see better provision for existing applications in our environment: John, do you want to spend some time with me to see if we can "have our cake and eat it too" (which I believe is possible)?

Until the details of how to do this is worked out, and we know exactly what is needed to get there, I don't want to disturb the Sugar development team one bit.

So I'll throw down the gauntlet to gnu: let's understand what is needed to have both worlds meet more gracefully.

• Jim

P.S. You are also welcome to put your UI of choice on the system in any case; this is an open platform.

[RussNelson]

Replying to gnu:

If I may make a meta-comment here, what we are seeing from John is a natural reaction to Open Source development by paid programmers. People have a tendancy to sit back and say "You're the professional, now act professional and do a professional job."

Build 303 requires the user to do a complicated undocumented dance before it will let them log in.

I agree that the startup could use a little more hinting, as could the XO screen.

such obstacles to intuitive use

No computer is intuitive. A better term is "familiar".

Why should kids have to batter their way through this idiocy before they can get to any educational materials?

John, whether this is idiocy or not is testable. Put a group of kids who has never seen it, in front of a Windows machine, and put a group of kids who have never seen it in front of Sugar. Ask them to perform various tasks and see how long it takes them.

Let's move to a window system where the objects on screen are responsive to the user.

Better: report your unmet expectation as a bug. For example, the OLPC should NEVER EVER discard a keystroke. EVER.

[joaoboscoapf]

There are alternatives to Sugar that work great. Have you ever seen the pepper software? Take a look at it: http://www.pepper.com/linux/olpc.html

It is just like Sugar! Actually, it has almost everything Sugar have and will have in the future. Its interface is just like Sugar, with the frame, activities, zoom metaphor and etc. You should at least give it a try! Take a look at the video application and you'll see what i am talking about ...

Certainly, work in Sugar is to reinvent the wheel. I think a very smart decision to speed up the OLPC project development would be to join efforts with pepper team to integrate it better with the XO. Pepper is much better than sugar. This is obvious since pepper is a 5 years old software and Sugar is still 0.6 ...

[jg]

Heh...

Who do you got Pepper machines early on? Walter did.

There are other attributes of Pepper (e.g. having been built in Java) which cause other problems.

[joaoboscoapf]

Replying to jg:

Heh... Who do you got Pepper machines early on? Walter did.

I didn't understand. I installed the pepper software in a XO laptop B1 not a pepper machine. So it uses OLPC build 303 with pepper UI (not sugar). Just give it a try and see it by yourself.

There are other attributes of Pepper (e.g. having been built in Java) which cause other problems.

What is the problem with Java? Its performance seems to be ok. Java can run pretty fast if using the dynamic compiler (JIT). Java now is also a free-software platform. And I think there are more Java programmers out there than python ones, so finding people to work with it will not be a problem.

[jg]

Sun's Java *may* become a free platform later this spring; we are certainly rooting for this completion. As is, Sun's J2SE is a 70 megabyte monolithic beast, most of which are jar files, and therefore compressed.

Alternatives such as Harmony are not yet complete as far as we can tell; it looks like a very much better more modular set of libraries, but we don't know of a free jvm we can get to use with that library stack, though we investigated at least somewhat recently.

A problem is it isn't very suitable for rapid prototyping, or kids seeing how their system works.

And we're perfectly happy if others work on alternative UI's: we're focused on the young children for which conventional systems work badly.

[joaoboscoapf]

Replying to jg:

Sun's Java *may* become a free platform later this spring; we are certainly rooting for this completion. As is, Sun's J2SE is a 70 megabyte monolithic beast, most of which are jar files, and therefore compressed.

I thought it was already open source. At least that's what I saw in some press notes, like http://www.sun.com/software/opensource/java/. Anyway, the JRE for java is just 16 MB and that is what you need to run Java applications. JDK is much bigger but you just need it for development of applications.

And we're perfectly happy if others work on alternative UI's: we're focused on the young children for which conventional systems work badly.

Pepper is a "clone" of sugar and therefore i think it is suitable for young children too. Anyway, I just think you should try it out, even if it is just to "know your enemies" ... :)

thanks for your attention.

[gnu]

Jim, I'm all for working out what needs to be done to let ordinary X apps work despite Sugar. Here's a tiny piece of the problem: #1146.

But I'm unclear on the process you want me to help with. I'm no expert in the details of either GUI design or the interface between a GUI and its applications. All I know is what I see, which is that the GUI is clumsy and confusing, and that ordinary X applications don't work with it.

Perhaps I'm misdiagnosing the problem when I suggest it's arrogance on the part of the designers. It seems almost an NIH attitude: "If the application designer has never heard of Sugar, and has not bowed down to the gods of Sugar, then that application damn well won't run here. We make very sure of that." I don't know of any other X window manager that aspires to this. If this truly is the problem, trying to glue in fixes for the little issues ain't gonna work; new issues that "just happen to" prevent compatability will keep arising.

[jg]

The difference here is that a number of OLPC folk have worked with computers and young children in the developing world (remember, our major audience are the kids who can't read yet, are just learning to read, or basic education), and the messy desk *doesn't work*. It was designed for literate, developed world office workers.

And the other focus is on collaboration: most learning is person to person, kid to kid, parent to kid, teacher to kid, kid to parent. Therefore a very high focus on collaborative applications, that will become clear as we move forward from here given the UI. The "mesh view" and "buddies view" are central UI elements, not yet exploited, for building thos applications.

I've watched my own kids (now age 9 and 12) go through this, with innumerable calls for help from Mom and Dad. In most parts of the world, Mom and Dad have never used a computer, and may be illiterate or semi-literate: we get questions like "What is the Internet?". We believe Sugar is much better for this primary audience; kids usually are only getting 5-6 years of basic education. I think we have 2 remaining major goals we need to meet:

1) make it easy to run Sugar apps on existing desktop environments, so that if people choose other environments the apps are still usable (and infect the whole community with building collaborative applications). We expect the kids, as they get older, may find other environments more useful (at least if we can get everyone on board on the collaboration side!). And there are some truly neat Sugar apps being built that kids of all ages everywhere may want to run in whatever desktop environment they are using. 2) make it easy for kids to run existing applications in the Sugar environment, so they can start experimenting when interested in more complex software. So over the last 2 years or so, my daughter has gone from wanting very simple paint programs to where she takes Photoshop howto-s and replicates the results in The Gimp.

The process, which we've been unable so far to spend time on but hope to soon, is ensure Sugar is "doing the right thing" with ICCCM and extended freedesktop hints where at all possible, and adding to the freedesktop standards where needed. Secondly, I suspect it may be easier once that is done to adopt a more "standard" window manager in our environment, making full integration of complex apps in Sugar possible; matchbox was developed for PDA's where most applications were semi-custom.

[sleet01]

Wish I could get this build running on my own laptop.

[jg]

sleet01, closing this bug was not appropriate for you to do.

I am closing it, however, as with the new stuff documented in the wiki, you can choose to install other Linux distributions (Debian in the example, Fedora may also be documented).

[natalie1981]

Is it still using Sugar? Will the OLPC be available for the public?

Gadget Reviews

[gnu]

None of the problems reported in this bug have been addressed (before it was closed, or in the intervening year). The bug (and the one it points to, #1146) were merely closed by the developers to sweep the problem under the rug.

OLPC still needs a high quality GUI, and needs to stop wasting the efforts of talented programmers on reinventing wheels that have already been done six times over. (Like picking which wireless interface to enable -- or having and organizing a set of program icons to run -- or switching between already-running programs).

OLPC's focus on collaboration would get a big boost if it could stop messing with the GUI and actually make the collab interface work. It's been broken for weeks in 8.2.0 (#8281, #7462, #7417, ...).

[Quozl]

OLPC OS now includes GNOME, and this is alleged to be usable and not Sugar. Closing this ticket.