On 17 Feb 2011, at 14:46, "C. Scott Ananian" <[email protected]> wrote:

> On Thu, Feb 17, 2011 at 8:18 AM, Gary Martin <[email protected]> 
> wrote:
> On 16 Feb 2011, at 20:35, "C. Scott Ananian" <[email protected]> wrote:
> 
>> On Wed, Feb 16, 2011 at 3:26 PM, Christian Bryant 
>> <[email protected]> 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/ )
_______________________________________________
IAEP -- It's An Education Project (not a laptop project!)
[email protected]
http://lists.sugarlabs.org/listinfo/iaep

Reply via email to