[IAEP] For Sugar Everywhere, Google-ize!

[Gary Martin]

On 17 Feb 2011, at 14:46, "C. Scott Ananian" <cscott at cscott.net> wrote:

> On Thu, Feb 17, 2011 at 8:18 AM, Gary Martin <garycmartin at googlemail.com> wrote:
> On 16 Feb 2011, at 20:35, "C. Scott Ananian" <cscott at cscott.net> wrote:
> 
>> On Wed, Feb 16, 2011 at 3:26 PM, Christian Bryant <christianabryant at linux.com> wrote:
>> I'm curious, is there a comprehensive requirements and/or design
>> document for Sugar against which the recommendation is measured?  I'd
>> be curious to see a "gap analysis" that supports the argument to not
>> use Python.  If nothing else, I'd vote for a solid wiki page that can
>> properly frame the idea, and the pros and cons.
>> 
>> I would also be interested in seeing an thorough experience report from someone who has attempted to use Sugar on a touchscreen device.  We already know that several major features (such as the frame and hover menus) fail completely.
> 
> FWIW neither of those are particularly challenging design cases. The frame could be triggered by a hardware button, and the 'touch & hold' interaction will work just great for the hover menu case.
> 
> This is an encouraging report.  "Touch and hold" isn't discoverable, though (you end up clicking on the button when all you wanted to do was see the drop down) and in general sugar uses a lot of hover interaction to help kids find what the active parts of the UI are.  This doesn't work on touchscreens.

If 'touch and hold' becomes the UI interaction that's currently covered by right clicking or cursor hover and loiter, it would be useful to introduce this technique at an early stage, much like Apple did with their 'swipe to open' UI switches. Imagine when the tablet is first powered up, or unlocked* from a screen powered off state — the user is presented with a large central button UI 'touch and hold to unlock' that when touched rotates to an unlocked position with a satisfying unlock click feedback. If released too early the button rotates back to its locked state and a 5-10 sec before a screen off power saving sleep is triggered.

* feel free to swap lock/unlock metaphor for sleep/wake metaphor, was just musing, actually could make a real cute wake up button with a subtle yawn squeak sound

OT there are current Sugar button UI cases I've been hoping to see cleaned up (SL#2517, #2518). We have a number of buttons that only have a hover or right click interaction that should be functioning as well with a left click (pop-up palette where button has no primary action). These do cause confusion as lack of left clicking interaction leads you to believe there are hidden bits of the UI that look like buttons but don't act like them.

> Also, integration of the keyboard is a huge open question.  As detailed at:
>    http://wiki.sugarlabs.org/go/Features/Onscreen_Keyboard
> "One major drawback of an on-screen keyboard is that in its current design, it blocks out a part of the Sugar UI. There's no immediate answer on how to handle this problem."
> 
> Activities would need to be resized to accommodate the keyboard, at the very least.

The trick here is not to resize/reflow anything, just translate the activity window vertically (and partially off screen) so that the text input area cursor always appears in the letterbox space still visible above the keyboard. 

> I think there's a big difference between "I tried it, and it sorta worked" and "I tried it, and it was a great experience".  Is it realistic to think that Sugar can be a "great experience" on a touch device with only minor tweaks here and there?  Or are we going to miss out on the exhilarating "direct interaction" feeling possible with a tablet and just produce a device that will frustrate and confuse kids?

I don't think there are insurmountable Sugar UI issues, though I do worry some of the upstream components we rely on may be bottlenecks, but that's just because I'm not up to speed with where Fedora, GTK, X, et al are with regard to multi touch. Also worth mentioning that smooth, fast visual feedback is critical, especially in scroll views, so good HW accelerated gfx drivers are even more important (fingers crossed for alpha compositing and maybe some 3d for simple transitions — wouldn't it be great to flip over an Activity window to edit its datastore details/tags view on the back).

--Gary

>   --scott
> 
> -- 
>                          ( http://cscott.net/ )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20110217/9c56ec7c/attachment.html>