Ticket #4910 (closed defect: invalid)

Opened 6 years ago

Last modified 6 years ago

Sugar UI overlaps three top bars on every activity

Reported by: gnu Owned by: Eben
Priority: normal Milestone: Future Release
Component: interface-design Version: 1.0-software-build-623
Keywords: Cc: eben, mikus@…
Action Needed: Verified: no
Deployments affected: Blocked By:


The Sugar UI has grown by aggregation and now puts a minimum of three bars of controls at the top of the average activity. The controls are allocated to those bars seemingly at random; and the different bars are reached by very different UI mechanisms.

The three bars are the Frame, the Activity bar, and the "whatever this activity is called" bar (e.g. "Browse"). The great advantage of the Frame was that it would get out of the way -- but the other bars won't. This makes the Frame an unusual standout without much remaining purpose in life. Whatever control you are trying to hit is seldom in the bar that you can see; so you have to first navigate to the right bar, and they are selected differently!

Let's say you are in Browse and want to type a new URL. You have to make sure the Frame is down (either by pressing the Frame key, and/or by moving the mouse out of the margins). Then you can head for the file-folder-tab "Browse". It has no graphical design that would indicate that it changes the bar above it; it's just a square button. (Most such tabs have rounded corners and change the thing below them, like when picking a file folder...) You click and release on Browse. Now you have a page title bar. You mouse over to the title and start clicking. How many clicks? Hard to tell -- some of the clicks change from title to URL, some highlight different parts of the URL, depending on how long it is. Eventually you can type a URL, but you're already exhausted.

Or suppose you're in Browse and it tells you there's a network problem. To get to the Mesh View screen, you have to bring up the Frame. This happens by pushing the mouse into a corner, hovering there, and then carefully moving it so it doesn't exit the Frame, til you find the thing you want to click on. How totally different from our first exercise above could this be? (You could use the Frame key, which simplifies the careful mousing, but then that begs the question of why there's two ways to do this. And yes, pressing the Mesh View key is much easier -- so why is there a Mesh View icon in the Frame at all, any more?)

To close the activity, you have a similar hunt, dumping any frame, then clicking on Activity, then on the close box. Of course the close box is all the way across the screen from the Activity button.

Not only is the top row of the screen permanently (ab)used for these control bars, but now the second row is also permanently allocated to Sugar rather than to screen space for the application. (And usually 3/4 of this row is empty and grey -- like 8/10ths of the Frame. You could fit all the controls in most apps into those two rows without doing ANY switching of top bars, and without using any more screen space. But that would be so... so... so, how can I put this? "like other GUIs?" "Easy?" I guess it wasn't considered.)

Now that pop-up menus are appearing on the items on the Frame, there's an additional exquisite inconvenience. If you pop up the frame via the corners, then carefully mouse to e.g. the SimCity icon, a pop-up menu will ask if you want to Remove it. You can't click on that menu, though; if you move into it, the Frame will pop down! The only way you can hit those things is if you lock the Frame up (with the Frame key; or on the donut page).

I've gotten used to trying every icon in these top bars, to try to figure out how to do something. It's like a solitaire game or puzzle, the frustrating sort. Even the icons for "Save" and "Load" are hard to tell apart (an arrow going out of a laptop means...which? Or was that an arrow going up and out of a book?) In some apps like TamTam those buttons get me into very odd places. In TurtleArt, the only way to make it draw on the screen seems to be to load something from the "Samples", which are hiding in another of those arrow-and-laptop icons, all alone on a big empty top-bar by itself. Took a while to find that one!

Eventually it may become clear why you'd want to rename your browser to something other than "Browse Activity", or your TamTam to something else. It's still obscure to me -- but this feature takes up a big chunk of screen real estate on the Activity bar; sometimes the only thing there except the close-box.

The user interface for sharing an application is still obscure to me. Perhaps that's because it's barely documented (in release notes) and there are several different ways to do it, all clumsy. Perhaps that's because when I try it, it only works a fraction of the time. Far too often, I simply can't tell a cumbersome UI design from an implementation bug. Either way, it doesn't work for me. How many real bugs are going unreported because the user just figured they were clueless about what they were attempting?

It's clear that the Sugar UI has grown by aggregation. It wasn't pretty when it started; it's gotten downright ugly, inconsistent, and inconvenient by now; and we've barely started on it. It was an OK prototype -- the only problem is that we're shipping it to hundreds of thousands of kids. Perhaps it needs a major human factors redesign, making a clean and pretty interface to replace the current aggregated mishmash. Either that, or the underlying unique features of Sugar need to be extracted from behind its ugly face, so that other GUI designs with much higher acceptance rates can incorporate activity sharing, time-based file storage, or whatever other OLPC innovations seem appropriate.

Gnome apps should be able to do these things; so should Hildon apps. What a concept -- portable, shareable applications that can use cross-platform conventions like window manager hints, rather than having to be rewritten to store their files in $SUGAR_BASE_DIR and be sure to tell the window manager what their icon is using an obscure control file in a particular file hierarchy. But that's a couple of separate bugs -- the Sugar "not invented here, do it MY way" approach to the programmer interface and packaging API.

Sugar runs the risk of becoming the next APL -- its good ideas obscured and rejected by the world due to a painful human interface.

Change History

Changed 6 years ago by marco

  • owner changed from marco to Eben
  • component changed from sugar to interface-design

Changed 6 years ago by jg

  • milestone changed from Never Assigned to Future Release

Changed 6 years ago by mikus

  • cc mikus@… added

Invoking the Frame :

A major complaint with the current sugar is that the Frame pops up when the user does not need it. For the time being, the *default* ought to be "press the dedicted key on the keyboard to invoke the Frame".

[For myself, I often use the scroll bars at the right of certain activity screens. Move the cursor too far down, and I'm no longer in the activity. And I exit an activity by clicking on the 'close' icon at the top right of the activity screen. Move the cursor too far up, and I'm no longer in the activity. Other users have expressed similar complaints about no longer being in the activity if their cursor comes too near the left-edge-corners.]

So far, the sugar-control-panel seems to be used primarily to enter data describing the *user*. Its goal ought to be expanded to also support describing how that user wants *sugar* to work. For instance, if the user wants to use cursor gestures to activate the Frame (instead of only the keypress being available by default), let that be an option provided by sugar-control-panel.

Changed 6 years ago by Eben

  • status changed from new to closed
  • resolution set to invalid

This ticket is a large aggregation of complaints, which range from small to quite large. Some have been fixed. Others have suggested fixes elsewhere. Yet others are "by design" (good or not) and remain open to further consideration in the community. However, while I feel that some of what has been said here is valid critique (albeit of a much earlier version of Sugar), it's completely unfocused and really deserves to be broken into small manageable pieces, each with its own ticket (many of them already have one). For this reason, I'm closing this ticket as invalid with the expectation that those parties who have experienced the current incarnation of the Sugar UI and still find problems with it can report on them in such a fashion.

Changed 6 years ago by mikus

For myself, I'm content to continue to "comment out" line 56 (or equivalent) of eventarea.py.

I see that a "timing" parameter for the Frame 'autoraise' was added to sugar-control-panel. But the current implementation of sugar-control-panel continues to be awkward for me to use. In particular, I can use an editor to make a change (e.g., in eventarea.py) to the (alternate) build-version that I have *not* booted, but I can use sugar-control-panel only upon the version that I *have* currently booted.

As I noted in the Design pages of wiki.laptop.org, I have adequate means at hand to make the frame appear. What would help me would be a SIMPLE way (when the Frame is being shown) to signal Sugar "on this occasion I've seen enough; get this instance of the Frame out of my way".

Note: See TracTickets for help on using tickets.