experiencing unexpected OLPC behavior from a misplaced click

[Eben Eliason]

On Sat, Jul 19, 2008 at 2:25 PM, Mikus Grinbergs <mikus at bga.com> wrote:
>
> But here is a case where I did not wait long enough for the OLPC to
> draw a pop-up palette, and did not make sure that the cursor was
> correctly positioned on the appropriate entry in that palette,
> before I 'clicked'.  In other words, it was __I__ who misbehaved.
>
> It is my intention to *not* write a ticket on this.  Aside from the
> __user's__ behavior needing to be corrected, I'm not sure what else
> would be "ticketable" ??
>

One of the core principles of usability in design is that it's never the
__user's__ fault, as much as they might think it is.  Bad design is usually
the reason that user's make incorrect decisions/actions.  We have an
interface-design component, which you could file a ticket for in order to
alert us of a problem with the experience of using Sugar.  If, on the other
hand, you think it's strictly an issue in the time it takes to draw the
palette, then perhaps we should be working to optimize that code path some.
 Specific examples of particularly slow behavior give us places to dive in
for profiling.


>
> It might help impatient users if palettes (e.g., in the Journal
> screen) were 'instantaneous' instead of 'slow' --  but I imagine the
> graphics speed is established by the OLPC processing capability (low
> power draw is imperative) and the overall Sugar GUI 'Look_And_Feel'
> design -- and can't be changed.  I see nothing in this particular
> situation for which writing a ticket would improve matters.
>

That said, do you indeed mean that the palette was drawn slowly, or simply
that the customary delay on revealing the primary/secondary palettes is too
long?  These are two very different things.  Of note, you can now (almost
everywhere...soon truly everywhere...) right-click on a button/object to
instantly reveal it's full palette, just like us with "standard desktop"
experience are used to doing to invoke contextual menus.  This trick might
help in either case.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080719/c948012c/attachment.html>