Bernie,
This is a good list, but I'd add a couple of things:
1). Make the "Keep" button hidden by default. If someone has a real
need for it in his Activity he can make it visible. It is the most
misunderstood control in the whole UI, and when you finally do figure
out what it does you wonder why anyone would want to use it.
2). Make the Journal UI a bit more like Sugar Commander. In other
words, represent the Journal proper differently than files and
directories on SD cards and thumb drives, and make the metadata for
Journal entries more visible.
3). My reading Activities open Journal entries by MIME type and
change the Activity ID of the entry on closing. In other words, when
you open a Plain Text file with Read Etexts it gets the Read Etexts
icon and in the future Read Etexts will be what is used to open it by
default. (You can still open it with other Activities that support
the MIME type). This would be a good default behavior for Sugar, in
my opinion.
James Simmons
On Thu, Oct 21, 2010 at 5:26 AM, Bernie Innocenti wrote:
> From my experience with first-time Sugar users in Mozambique, I've come
> up with a list of UI changes that would help:
>
> 1) EASY: kill the name picker that pops up when quitting
> activities. Nobody ever uses it, it's just annoying and confusing
> for new users who don't know how to dismiss it. Maybe one day
> someone will come out with a less intrusive UI for the same purpose,
> but for the time being we're much better off without anything.
>
> 2) EASY: kill the "Mute" function on the volume icon in the frame.
> I can't think of a useful use-case for it, and children often
> manage to turn on muting by simply clicking on the speaker icon
> (which is a lame UI, btw). If we remove this feature, we have to
> unconditionally unmute on startup!
>
> 3) MEDIUM: Figure out why so many control panels require restarting
> Sugar, and fix them not to. Because we use GConf for settings,
> we should be able to setup callbacks to be invoked on any change.
>
> Removing existing features is always hard in free software, as there's
> always some user who advocates in favor of keeping them. As consumers,
> it's hard for us to cope with the sense of "loss", even if the feature
> had no practical value for us.
>
> If we can't get these proposals approved upstream, perhaps we can make
> them configurable. IMHO, it sucks to add a knob every time we fail to
> find consensus, but it's still a little better than maintaining off-tree
> patches.
>
> --
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
