#4910 NORM Never A: Sugar UI overlaps three top bars on every activity

[Zarro Boogs per Child]

#4910: Sugar UI overlaps three top bars on every activity
--------------------+-------------------------------------------------------
 Reporter:  gnu     |       Owner:  marco         
     Type:  defect  |      Status:  new           
 Priority:  normal  |   Milestone:  Never Assigned
Component:  sugar   |     Version:  Build 623     
 Keywords:          |    Verified:  0             
--------------------+-------------------------------------------------------
 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.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4910>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system