Design Team/Proposals/Touchscreen: Difference between revisions

(3 intermediate revisions by 2 users not shown)

Line 1:

===Touchscreen Support===

Line 36:

Line 38:

|OK

|nice to have them optimized to be touchable

|size/spacing of buttons and menus needs to be optimised for finger sized ~~input~~

|size/spacing of buttons and menus needs to be optimised for finger sized interaction

|-

|hpane/vpane separator theme

|OK

|nice to have them optimized to be touchable

|size menus needs to be optimised for finger sized interaction

|-

|Screen resolution

Line 48:

Line 55:

|hide keyboard hints from touch only UI

|-

|Scrolling ~~views~~

|Scrolling a zoomed paint/drawing view

|n/a

|two finger drag to pan/scroll canvas

Line 63:

Line 70:

|...

|}

= Other =

[CSA: adding here some issues which aren't in the above table, not sure how they fit in]

; Keyboard hints: show different keyboards for numeric, URL, or free-text input. (For example, TurtleArt wouldn't show the full keyboard when it just needs you to enter a number.)

; Hover palettes: might need to be offset more from finger location to be useable on touchscreen (so that the finger doesn't cover up the palette when it pops up)

; Drag to scroll: I prototyped this with "drag from top" / "drag from bottom" to scroll, it wasn't so bad. Simply mapping two-finger scroll to mouse scroll buttons gets you pretty far, although there are some focus issues to deal with -- it should first focus the element under the scroll start location, and *then* send it mouse scroll wheel events

; Slide to switch zoom levels: just requires binding F12,F13 etc to "zoom out" and "zoom in", so olpc-kbdshim can emit the proper function key instead of trying to remember what zoom level it is in.

; Uniform support for "mouseover" events: perhaps "swiping down" from a button will reveal its mouseover tool tips, for example. This is a bit of a hack, but it might make all the existing sugar activities which rely on mouseover more usable.

@@ Line 1: / Line 1: @@
+{{Dated}}
 ===Touchscreen Support===
@@ Line 36: / Line 38: @@
 |OK
 |nice to have them optimized to be touchable
-|size/spacing of buttons and menus needs to be optimised for finger sized input
+|size/spacing of buttons and menus needs to be optimised for finger sized interaction
+|-
+|hpane/vpane separator theme
+|OK
+|nice to have them optimized to be touchable
+|size menus needs to be optimised for finger sized interaction
 |-
 |Screen resolution
@@ Line 48: / Line 55: @@
 |hide keyboard hints from touch only UI
 |-
-|Scrolling views
+|Scrolling a zoomed paint/drawing view
 |n/a
 |two finger drag to pan/scroll canvas
@@ Line 63: / Line 70: @@
 |...
 |}
+= Other =
+ [CSA: adding here some issues which aren't in the above table, not sure how they fit in]
+; Keyboard hints: show different keyboards for numeric, URL, or free-text input. (For example, TurtleArt wouldn't show the full keyboard when it just needs you to enter a number.)
+; Hover palettes: might need to be offset more from finger location to be useable on touchscreen (so that the finger doesn't cover up the palette when it pops up)
+; Drag to scroll: I prototyped this with "drag from top" / "drag from bottom" to scroll, it wasn't so bad.  Simply mapping two-finger scroll to mouse scroll buttons gets you pretty far, although there are some focus issues to deal with -- it should first focus the element under the scroll start location, and *then* send it mouse scroll wheel events
+; Slide to switch zoom levels: just requires binding F12,F13 etc to "zoom out" and "zoom in", so olpc-kbdshim can emit the proper function key instead of trying to remember what zoom level it is in.
+; Uniform support for "mouseover" events: perhaps "swiping down" from a button will reveal its mouseover tool tips, for example.  This is a bit of a hack, but it might make all the existing sugar activities which rely on mouseover more usable.