<br><br><div class="gmail_quote">On Jan 2, 2008 2:17 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div><div></div><selections: verb-object or object-verb> </div></blockquote><div><br> ... discussion running on... the next step is example code... not gonna do it next.</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d"><global preferences><br><br></div>Quite true.  I think we'll probably introduce a form of fullscreen<br>"modal dialog" for such a thing.  That is, you press an "account<br>settings" button and get a fullscreen overlay containing all of the

<br>necessary settings, hiding the rest of the interface, including the<br>toolbar itself, to focus the child on the task at hand and eliminate<br>the presence of temporarily insensitive controls which don't respond<br>

and keeping this preferences screen independent from the persistent interface of the activity itself.</blockquote><div> The whole point of a modal dialog box is that there are only 2 ways out, OK and Cancel. This lets the program not apply the changes until you press OK - like the 'save' command. But there is always another way out - killing the activity from the user view. Sometimes it would be more kid-friendly to keep changes as soon as they happen. If we do this, there's no reason to hide the frame.

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br>> > Actually, while the HIG doesn't have too much to say on this yet, it

<br>> > does outline clearly that the UI will transition to fullscreen (no<br>> > toolbars) when in Handheld mode, and the cursor itself will be hidden<br>> > by default.  The shape buttons will then be assigned special functions

> > relevant to the current activity, providing a limited but tailored set > > of functions for the current activity.  The spec for Browse on the > > wiki outlines in detail how this could work.

<br>> ><br>> ><br>><br>> 'Special functions relevant to the current activity' is fancy talk for<br>> 'ad-hoc and obscure'. Some consistency is necessary - even if it's just<br>> cell-phone-like, with an indicator of what the buttons do when you press

<br>> them (a little picture of the four buttons with meaningful text and icons<br>> next to them) which shows up in the corner next to them for a short time<br>> whenever you press one.<br><br></div>Absolutely.  I wouldn't think of advocating this without a simple and

<br>consistent way to view the mapping for the current activity, in some<br>form or another.<br><div class="Ih2E3d"></div></blockquote><div><br>Oh yeah? So where's the spec? Or do you want me to write one? <br><br>(Sorry, I don't mean to imply that everything should be perfectly complete. It is fine to have places in the HIG that say 'we're still writing the spec for this'. But there should be some indication of how the thinking is going.)

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>> I would still advocate for a more comprehensive plan, like the one I began

<br>> to sketch out in the original message included above. It puts the load on<br>> Sugar itself, instead of on the programmer of each individual acivity - an<br>> obvious advantage.<br><br></div>This isn't necessarily so straightforward.  For instance, in the

<br>Record activity the thing you really want to do most is [take a<br>picture]. In browse, you probably want a [follow link/forward] and<br>[back] buttons.  In a game of tic-tac-toe you need a [play piece]<br>button.  I don't think there is a very good generic solution to the

<br>Handheld mode buttons, and therefore hope to focus on a consistent<br>system by which activities can identify and map these buttons to a<br>core set of functions relevant to the activity.<br></blockquote><div><br>Your examples all give one or two default actions. I think this will be typical. Also note that the only case with two - Browse - the two actions can be thought of as movement in opposite directions along the same axis. (The exception to my rule would be a media player, which wants 3: ff, rev, and play/stop)

<br><br>In order to use a set of controls efficiently, I think it takes about 7 buttons. Aside from the main 'do it' button, there are 6 for navigation: the four physical directions and two more directions (in and out) to let you get context menus ('in'), jump out of text fields ('out'), and get out to the toolbar and frame. (I know, you want to hide the toolbar by default. But there's no reason it shouldn't be accessible.) 

That means that there's enough buttons for generalized navigation and ONE activity-related button. It would be nice to have another sometimes but it is enough. The special button can be 'back' for the browser, 'ff' (toggleable using controls to 'rev') for a media player, 'take picture' for the camera, etc. The nav arrows turn pages in a book reader, or, if you REALLY need scrolling, you just have to give up on a dedicated turn backwards button.

Concretely: the arrow keys would navigate a selector between controls, the X key would choose the control with the selector, the square key would pop out of context menus, out of text boxes or other complex controls, out to the toolbar, and out to the frame, in that order (followed by out to user, group, world view??); the check key would go in the opposite direction; and the O key would be activity-specific.

The added benefit of doing things like this, as I mentioned, would be that an activity programmer would need to worry about responding to just ONE extra event, the O key - or none at all if it already does the right thing on 'enter'. Sugar/GTK can handle all the rest.

</div></div><br>