[sugar] Sugar UI design and Tux Paint

[Albert Cahalan]

On Jan 2, 2008 11:25 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
> > Journal integration is an interesting problem. Tux Paint keeps
> > some extra per-image data in extra files. I'm thinking that an
> > export-to-journal button might be most appropriate.
>
> There is an explicit "keep" button in the activity toolbar to allow
> kids to save an object in a particular state.  Other than this, there
> shouldn't be any need for custom buttons to interact with the Journal.

Heh. If porting were that trivial...

Please try Tux Paint. Save a few drawings. Now load one.
Notice that Tux Paint always starts up with the last drawing.
That's the user experience I want to keep, because it's
wonderful for kids. Even if I didn't want to keep that, there
is a great big pile of code behind it.

BTW, so far nobody has even provided example code for
the raw D-BUS calls to interact with the journal.

>  The activity should save implicitly anything it requires to maintain
> it's state.  Ideally, this extra data should be kept as metadata on
> the image file so that other activities can read the image itself.

The metadata includes a thumbnail image and a text file
to associate the image with a "starter image". A starter
image provides an immutable background and foreground.
For example, there is a beach scene with palm trees in
the foreground. There is a coral reef scene that has a part
of the reef in the foreground; one can place fish that peek
out from behind it.

In any case, I have lots of existing code to deal with.
I can put the data in one file: tar, cpio, ar, or pax?

> > I could use a way to tell Sugar to not start up a second instance.
> > I haven't verified that it is safe to run two copies of Tux Paint,
> > but even if it is, the laptop is unlikely to have the RAM for it.
>
> This isn't really an option.  The entire Sugar model is based on the
> notion of objects as instances activities.  There will be a natural
> limit (likely bounded by RAM) to the number of activities that can run
> simultaneously on an XO, but this is not something that should be
> avoided by making arbitrary special cases for particular activities.
> Activities should strive to be as lightweight as possible, and beyond
> that Sugar will have to handle the situation when "things fill up".

Being "lightweight" is being stripped bare. Tux Paint is meant
for low-end hardware like the XO, barely. Kids love the stamps,
the stereo sound, undo, etc. Put a kid in front of it and watch.

If I had more RAM, then I would try to use it for better quality.
Tux Paint isn't meant to be just another MS Paint clone.

Note that Sugar itself consumes much of the RAM. Less than
half of the RAM is available for activities, and this is shrinking.

> > Shutdown tends to have the usual trouble. Tux Paint makes this
> > highly configurable. I had two dialog boxes. I got rid of one by
> > configuring Tux Paint to save on exit, but I'm really not comfortable
> > with saving random junk that the user will just have to delete.
>
> This will improve with time in the Journal, as we add better support
> for starred entries with filters on the Journal to show only those
> which are starred, and once we introduce the notion of temporal
> falloff and versions.  We'll re-examine how much of this type of
> management is really required by the user once those features have
> been integrated.

Nice, but I need to make things better ASAP.

> > The other asks if the user should overwrite or make a new file.
> > Never minding the wisdom of such dialog boxes, Sugar is defective
> > to not allow for it. (one sees the problem in SimCity too, etc.)
>
> This is a non-issue once differential versions are part of the
> Journal, which is the assumption that the entire model was designed
> on.  While I understand the need for it, and the concern for the
> current behavior, I think that Sugar is doing a reasonable job for now
> until versions are integrated.  If I have a drawing (in real life) and
> pour some paint on top of it, then I can't get my old drawing back.
> To do that, I would first make a copy of the drawing and then paint on
> one of them, which is how it can be handled in the UI for now.

I can't see this ever working OK. It reminds me of my gmail
inbox, which is a 6094-message disaster despite my efforts
to delete the spam and other useless junk. The fundamental
problems are very journal-like: slow interaction, poor support
for directories, and lots of incoming junk.

Drawings really should be separate from camera pictures.
They are used in different contexts, in different ways, etc.

> > I'm strongly tempted to configure Tux Paint to grab the screen.
> > That frame is horribly easy to invoke.
>
> Here again you're discussing the possibility of overriding Sugar
> behavior, eliminating consistency across the UI and activities.

I know. It's rotten. The current behavior is terrible though.
My test subject was constantly invoking the frame, even
after switching to a real mouse. She ended up launching
lots of other activities by mistake. Eventually the system
would run out of memory and kill the program she'd started
with, making her lose all her work.

Maybe I'll do a "lock out the frame" button.

> These
> kinds of problems are things that should be entered in tickets, or
> discussed on lists so we can find a general solution.  When particular
> activities try to "work around" Sugar no one really benefits.  I think
> that a very slight delay on the corner activation might be an ok
> decision to prevent accidental invocation of the frame if it proves to
> be a problem.

There is a frame key.

> > We're still searching for a mark-move, mark-copy, cut-paste, and/or
> > copy-paste interface that little kids can deal with. One idea is to
> > have something like the gimp's quickmask mode on one button, and a
> > stamp on the button next to it. Another idea would be to select via
> > flood-fill on non-background pixels. It's a really hard problem
> > because Tux Paint tries to support a bright 2-year-old or regular
> > 4-year-old.
> >
> > So far, we haven't really considered supporting canvas sizes other
> > than the one that fills the screen. Do people think that matters?
> > I don't know of any reasonable way for a tiny kid to deal with
> > scrolling and zooming.
>
> In the interest of "no ceiling" I think this will be important.

I can go for "high ceiling". At some point one needs to
switch to the gimp. Currently this means ditching Sugar
because the gimp is strongly multi-window. (eh, it looks
like Sugar itself has a low ceiling)

> If a
> class wants to make a webpage, it goes without saying that they might
> need images of various sizes.

For some values of "need"...

img src=foo.png height=55 width=40

> This doesn't mean, of course, that it
> has to be a prominent feature.  A single button for changing the
> canvas size could suffice.  You wouldn't even have to offer the
> parameters when a new object  is made if you want to keep things
> simple for the base case.  If people need and want the feature, it can
> be found.

Assuming automatic zoom-to-fit, then something similar to
the rectangle tool could work for getting a smaller canvas.
Kids will tend to do this by mistake though, then wonder why
the drawing is so coarse and ugly. This probably makes the
feature undesirable.

> Alternatively, you could create a visual mechanism for creating the
> starting canvas size.  Perhaps by showing the white canvas on a gray
> background with transformation handles and editable "height" and
> "width" labels the child could type in specific dimensions or drag the
> edges of the canvas to set it up visually (always "zooming" so that
> the entire canvas is visible, for visualizing proportion of height to
> width).  With this approach, the use of any tool other than the canvas
> transform handle would lock in the current canvas size for the
> document.  This would make the decision about the size similar to
> choosing a sheet of paper to draw on, eliminating the complications

"type in specific dimensions" means knowing numbers.

I'm not sure where the "gray background" is supposed to go.
Tux Paint has no dead space on the screen for that. The canvas
is always a perfect fit, zoomed 100%, without scroll bars or
slack space.

> that come with adjusting the canvas of an existing image. (A crop tool
> may still be useful. This again is a natural metaphor for cutting the
> edges of the paper off; the inverse can be accomplished by creating a
> brand new canvas of a larger size and then pasting all or part of the
> previous image into it, eliminating the need for a "change canvas
> size" button.)

Paste is also difficult for kids. It involves hidden state.