Talk:OLPC Human Interface Guidelines/The Sugar Interface: Difference between revisions
No edit summary |
|||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
==Directional pad and game keys locations== |
|||
ordellar |
|||
If the directional and controller buttons were at the top (as opposed to the bottom) they would be easily accessible when the laptops are held vertically, which would be very useful for the hand-held mode. Given the rotation of the screen, they would be optimal for both left and right handers. It's crucial that the buttons remap when the screen rotates (eg. the triangle becomes right -instead of up- when in portrait layout with the bottom of the screen near the controller buttons). |
If the directional and controller buttons were at the top (as opposed to the bottom) they would be easily accessible when the laptops are held vertically, which would be very useful for the hand-held mode. Given the rotation of the screen, they would be optimal for both left and right handers. It's crucial that the buttons remap when the screen rotates (eg. the triangle becomes right -instead of up- when in portrait layout with the bottom of the screen near the controller buttons). |
||
== Trackpad: tap for mouse click? == |
|||
Is there any provision to configure the trackpad to register a tap as a left mouse click? --[[User:IanOsgood|IanOsgood]] 13:45, 30 December 2007 (EST) |
|||
== View scrolling == |
|||
The Sugar scroll bars are quite narrow, which is welcome for maximizing the subject matter/infrastructure ratio; however, that feature makes them a more difficult target for grabbing the slider. I find that scrolling with the directional pad is a wonderful alternative, but one that is not consistently supported. (It works in Browse, but in Terminal, it scrolls the input buffer. There I'd be happy with the arrow keys for the buffer and the pad for the console.) |
|||
If it isn't already proposed, I would like to suggest that all activities attempt to use the directional pad to support view scrolling, and perhaps the game keys for page up, page down scrolling (page left, page right, with book page metaphors) when those hardware controls are not used for more activity intrinsic functions. |
|||
For those that prefer not to move their hands from the keyboard & trackpad, I believe that the 'hand' keys will eventually enable some scrolling from the trackpad, but don't know the status of that feature --[[User:FGrose|FGrose]] 15:59, 19 March 2008 (EDT) |
|||
:(from devel maillist, 24 March 2008) I think we should discuss the alternatives we have here, including forgetting about it and redesigning the UI to take into account the lack of scroll key support. [http://dev.laptop.org/ticket/447 Trac ticket 447] --Tomeu |
|||
::Please note also that our current design for the resistive trackpad input requires the grab key. If we remove the capability completely, we'll have to rethink those interactions from scratch as well. -[[User:Eben|Eben]] |
|||
Latest revision as of 18:20, 24 March 2008
Directional pad and game keys locations
If the directional and controller buttons were at the top (as opposed to the bottom) they would be easily accessible when the laptops are held vertically, which would be very useful for the hand-held mode. Given the rotation of the screen, they would be optimal for both left and right handers. It's crucial that the buttons remap when the screen rotates (eg. the triangle becomes right -instead of up- when in portrait layout with the bottom of the screen near the controller buttons).
Trackpad: tap for mouse click?
Is there any provision to configure the trackpad to register a tap as a left mouse click? --IanOsgood 13:45, 30 December 2007 (EST)
View scrolling
The Sugar scroll bars are quite narrow, which is welcome for maximizing the subject matter/infrastructure ratio; however, that feature makes them a more difficult target for grabbing the slider. I find that scrolling with the directional pad is a wonderful alternative, but one that is not consistently supported. (It works in Browse, but in Terminal, it scrolls the input buffer. There I'd be happy with the arrow keys for the buffer and the pad for the console.)
If it isn't already proposed, I would like to suggest that all activities attempt to use the directional pad to support view scrolling, and perhaps the game keys for page up, page down scrolling (page left, page right, with book page metaphors) when those hardware controls are not used for more activity intrinsic functions.
For those that prefer not to move their hands from the keyboard & trackpad, I believe that the 'hand' keys will eventually enable some scrolling from the trackpad, but don't know the status of that feature --FGrose 15:59, 19 March 2008 (EDT)
- (from devel maillist, 24 March 2008) I think we should discuss the alternatives we have here, including forgetting about it and redesigning the UI to take into account the lack of scroll key support. Trac ticket 447 --Tomeu
- Please note also that our current design for the resistive trackpad input requires the grab key. If we remove the capability completely, we'll have to rethink those interactions from scratch as well. -Eben