On Tue, Mar 25, 2008 at 12:41 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 25 Mar 2008, at 15:47, Eben Eliason wrote: > > Taking these concerns to heart, I'd like to propose an alternate to > > the tabbed toolbar design which attempts to address these new concerns > > with the current design, again making some tradeoffs but hopefully > > coming out on top in the end. The core component of the new approach > > is the introduction of the "toolbar button", which you can see mockups > > of at http://wiki.laptop.org/go/Designs/Toolbars. There is no text > > with the mockups yet, but I'll add it later. In the meantime, please > > consider the following advantages: > > Yes, I do like the idea a lot. > > The main issue I see not covered in your list (and it's quite a > whopper), is that the extra tool-bar strip shifts the top of the main > activity canvas down, resizing it in the process. Problems: > > 1) As you mouse over, the main canvas content will jerk up and down > like a pneumatic road drill.
This is a valid point, and one that does indeed pose some technical challenges, as there doesn't really seem to be any reasonable way around it in the design. It is, technically, the problem which by definition this design creates by attempting to use screen space only when necessary. I see one possible tweak to the design which could minimize the invasiveness of this dilemma. Consider http://wiki.laptop.org/go/Designs/Toolbars#06. In this slide, we see the toolbar in a "preview" mode; it hasn't yet been locked into place by clicking on the toolbar button. I have two things to say about this mode, the first of which was initially intended but not made evident, and the second which addresses your concern to some extent: 1. While in this preview mode, the toolbar and it's elements will remain fully operational, as though this toolbar were simply a palette. (In fact, it's design, in black, helps to indicate this relationship. This means that, should I desire to copy something, I could reveal the preview of the edit toolbar, move to the copy button, click it, and then go back to working without ever toggling to toolbar on. Once the cursor left the toolbar area, the preview would go away. 2. It almost comes naturally from outlining the above idea that the toolbar *should* be overlaid above the canvas while in preview mode. Only when locking it into place as a permanent fixture of the UI would it turn toolbar-gray and shift the content of the activity. While not solving the technical problems that go along with reflowing the UI, it would prevent the "jackhammer" effect you mention, instead only causing layout changes upon explicit click. > 2) The window resize is going to trigger the contained widgets to > redraw/re-scale/re-align. This may be fine for a trivial activity with > minimal UI complexity, but if any of those widgets require some > processing to regenerate their visual appearance or content flow... > ouch. Following the above approach, we can minimize the hit this causes. > 3) Activity developers should already be using flexible layouts to > cope with potential screen rotations, however the added potential for > a reduction in main canvas size will add to the UI design/testing > complexity, with designers making a little less use of the space by > default so they leave some vertical space to prevent things getting > cropped. Here I'd have to say that, despite the knowledge that all activities will run fullscreen, we should try to avoid developing to a particular piece of hardware (and it's resolution). Most applications out there in general are designed to support natural reflow of UI elements based upon the window size. We too should aim, in general, to produce GUIs this robust, in which case the change shouldn't be much of a problem. In the worst case, some activities which have particular needs can surmount this by rendering their "static" area in a larger region with 40px of padding at top and bottom, though I suspect (and hope) that most won't have to resort to such a tactic. - Eben _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel