<br><br><div class="gmail_quote">On Jan 2, 2008 5:35 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 class="Ih2E3d">> > 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<br>> > interface of the activity itself.<br>><br>> The whole point of a modal dialog box is that there are only 2 ways out, OK<br>

> and Cancel. This lets the program not apply the changes until you press OK -<br>> like the 'save' command. But there is always another way out - killing the<br>> activity from the user view. Sometimes it would be more kid-friendly to keep

<br>> changes as soon as they happen. If we do this, there's no reason to hide the<br>> frame.<br><br></div>That's a good point.  Here again, though, changing some preferences<br>may result in more invasive changes to the interface, non-trivial

<br>computation to apply, or changes to the structure of the activity in<br>such a way that they aren't undoable.  All of these things are reasons<br>that an activity may want a strictly modal interface.</blockquote><div>

<br>Agreed. I said, 'sometimes'. I think that it is better to stay non-modal if possible. (For the last of your cases, changes to activity structure, eg email settings or ftp server or something, an autosaving dropdown/autocomplete list of previously-used settings is a way to provide undo without overloading the 'undo' command. Invasive changes to the interface should not be opaque - there should be some visible way to realize what is going on, or even a cue to changing the preferences back. And as for nontrivial computation, it is at least theoretically possible to save the settings in real time but apply them later. So I think that the modal-necessary cases still exist, but are rare exceptions.)

<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<br>> 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>> > 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>> ><br>> ><br>><br>> Oh yeah? So where's the spec? Or do you want me to write one?<br><br></div>There is no spec yet.  There is a ticket outlining some thoughts on<br>

the subject: <a href="http://dev.laptop.org/ticket/1310" target="_blank">http://dev.laptop.org/ticket/1310</a></blockquote><div><br>Interesting - you're considering taking over the rotate key...<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<a href="http://dev.laptop.org/ticket/1310" target="_blank"></a><br><div class="Ih2E3d"><br>> > 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

> > Handheld mode buttons, and therefore hope to focus on a consistent > > system by which activities can identify and map these buttons to a > > core set of functions relevant to the activity.

> > > > 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.

<br>> (The exception to my rule would be a media player, which wants 3: ff, rev,<br>> and play/stop)<br><br></div>I only provided one or two, but I imagine that most activities will<br>use them all.  Read my proposal for Handheld mode in Browse for a more

<br>complete understanding of the type of interface I was envisioning:<br><a href="http://wiki.laptop.org/go/Browse#Handheld_Mode" target="_blank">http://wiki.laptop.org/go/Browse#Handheld_Mode</a>.  In this paradigm, the

buttons retain their pairings when needed, and they can have both instant and hold states (as modifiers which reveal an overlay menu which can be navigated via the directional buttons).</blockquote><div> A lot of good ideas there, of course. I think we can come to a good compromise between my issues (more across-activity-consistency and complete-access, including sugar) and yours (in-activity applicability and usability).

<br><br>One basic idea of yours is to double the buttons by providing both press functionality and hold functionality (with hold often a context menu related to press). That is obviously applicable in my scheme too.<br><br>

With this in mind, here's a look at your browse scheme vs. mine applied to browsing.<br><br>up/down/left/right: you scroll with up/down and select links with left/right; I select links with both. But notice that the two are not actually as seperate as it would appear. Selecting links can cause scrolling and vice versa. So in my scheme, a click selects links. If that is a small distance vertically, then a hold would be ONE page down/up; if it is a larger distance (maximum one page), then a hold would be continuous finer scrolling. (side to side would wrap, and a hold would scroll)

select link: you have that as east, I'd use north (select control). Same functionality. TOC: you have that as east hold, I'd have it in repeated east hold (see below). back(/switch tabs nav overlay on hold): you have west, I'd have south (app-defined). Same functionality.

<br><br>panning overlay: your use of south. Might be nice, but not necessary.<br><br>Share link to here/share link overlay: your use of north. In mine, it would be either in the toolbar or in back-button-then-N-hold (a context menu for the link, which would also include 'open in new tab', though the tab list would autoclean like the journal, but that's another story)

What would I do with W and E: W hold: move focus 'out': get out of menu (note that in your scheme all context menus/ nav overlays need an explicit exit option because there's no button for out), get out of text box, get toolbar (you could include the shared links bar too on this level - you have two dimensional navigation after all), get frame, in that order.

W press: app-specific 'out', 'away', or 'back' option. In Browse, maybe zoom out? (available for rew on a media player) E hold: opposite of W hold. When you get down to the context-menu-level, it would be the TOC menu which you have in E hold.

<br>E press: zoom in.<br><br>I hope this is all clear. As you can see, the differences are less than one might imagine.</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></div>I think offering only one button to the activity is extremely<br>limiting.  I personally think it would be better to allow activities<br>to cater to Handheld mode by providing meaningful mappings that

<br>provide access to a core set of functionality. </blockquote><div><br>OK, using your great click/hold idea, the buttons available to an app are now 4-6, depending on how you count: E and W press for in and out, S press and S hold completely free (if used in opposition to N "do", it would be "undo"; but for camera, it would be 'take picture'), and maybe I can count N hold (context menu) and even N press (select) as being app-specific. 

Remember that if your main window doesn't have buttons inside it, you can use N press (Select control) for what you will (abiword might use it to sticky the shift key and turn the cursor into an I-bar, for instance). You also have more freedom with the up/down/left/right then too (in Abiword, holding them could page down/side scroll).

<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Setting this up<br>needn't require a lot of extra work, as this will likely amount to

setting up an alternate key binding for an action that is offered elsewhere in the UI.</blockquote><div> Not too much work: Granted. But there will always be apps which are incompletely sugarized, we want that to cover as much ground as possible. It would be great to be able to make a sugarizing wrapper that could make a generic GTK app look like sugar.

<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></div>If the arrow keys only jump through controls, then there is no way to

scroll naturally.  Consider Read:  how do I both scroll (or page) up/down/left/right and also navigate the controls? </blockquote><div> When the focus is on the document, the arrow keys scroll. (The links or buttons within the PDF are inaccessible). To jump through controls, put the focus on the toolbar (which hides otherwise anyway) by holding W. This is not even a special case, it is the natural behaviour; controls INSIDE a document, like Browse, are the special case.

<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> And, even if I can<br>get there, I'll spend half my time cycling through a bunch of controls

<br>which may not be of use to me in handheld mode at all, just to get to<br>the few that are.</blockquote><div> </div><div>A well-sugarized activity could hide inapplicable controls. A poorly-sugarized one could just take the hit. 

<br><br>Jameson<br></div></div><br>