Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
On 5 Apr 2008, at 16:44, Tomeu Vizoso wrote: > What if on rollover would appear a normal palette with all the buttons > that would be in the subtoolbar? This palette would have an option for > pinning it, and that would mean inserting a subtoolbar between the > toolbar and the canvas like in the mockups. > > Benefits: > > - palettes don't disturb the layout of the underlying window, > - existing UI component, > - buttons are grouped closer to the main button, requiring less > mouse travel, > - buttons are in an area not as thin, making easier to move the mouse > without going out (thus hiding the palette), > - we could keep the toolbar label. > > Thoughts? Hmmm, a regular palette pop-up will often end up being way too tall, with the (usual) screen orientation a full row of buttons would not fit. And it gets messy when the buttons are not simple square icons, say like in Write where font size is represented by two element (an icon and a pop-up size list), or the font family picker (a wide pop-up text list). Trying to arrange these vertically in a pallet is going to fill up a good chunk of the display with mainly empty black space padding. After much musing, I think Eben's designs at http://wiki.laptop.org/go/Designs/Toolbars are a good compromise, but they would need to (as mentioned by another list member): A) On mouse hover over a tab button, float the new toolbar over the existing activity canvas (obscuring some content), and not moving/ resizing the activity canvas area. B) A click on a tab icon would lock it in place (pinning), and than cause the main canvas to reflow/resize. Sub toolbar buttons still get to have their mouse over textual hints, but the top level tab buttons have none – I know this is an issue for some folks... I guess, and it's a flakey guess, with the above A&B alteration, you could; during hover state A, show an extra horizontal strip with the tab name below the new toolbar strip; then after click state B, you'd just insert the new toolbar strip and loose the extra text row to save space. Does anyone build working prototypes of these kind'a interactions? makes all the difference (usually a pretty instant, yuck or fine reaction). Would be quick to do, Eben is that me I hear you volunteering?? Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
What if on rollover would appear a normal palette with all the buttons that would be in the subtoolbar? This palette would have an option for pinning it, and that would mean inserting a subtoolbar between the toolbar and the canvas like in the mockups. Benefits: - palettes don't disturb the layout of the underlying window, - existing UI component, - buttons are grouped closer to the main button, requiring less mouse travel, - buttons are in an area not as thin, making easier to move the mouse without going out (thus hiding the palette), - we could keep the toolbar label. Thoughts? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
On Tue, Mar 25, 2008 at 8:30 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > 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). Hmmm. That sounds impossible. Your examples show that with that layout (and a wide URL/Title widget) we are limited to 2 toolbar icons, 3 if we shrink the icons. So the app will be designed to have 3 toolbars, because the 4th will force a "reflow" to the next row that will be horrendously wasteful. For these kinds of reasons, in real life we all optimise UIs for actual screen sizes. Doesn't make me happy, but it's one of the constraints that hurts the most, so the best UIs are extensively tweaked to make the most of the limited resource. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
On Tue, Mar 25, 2008 at 4:20 PM, Nate Ridderman <[EMAIL PROTECTED]> wrote: > Eben, > > By no means do I consider myself a user interface expert, but I have a few > comments. > > In general, I agree that this proposal is better for localization and may > take up less screen real estate. Would there still be default buttons to > share, keep, and/or stop the activity? I believe it's important to have an > easy way to stop the current activity, but maybe you have this accounted for > elsewhere in the frame redesign. I haven't had a chance to build and test > Tomeu's branches yet. It looked like activities could be stopped from the > frame, but no preference was given to the current activity. I'm not sure if > this is convenient enough. If a stop button is required, and perhaps a share > button and a keep button, this will eat up space and require most activities > to use a secondary toolbar. Thanks for bringing this up. This is a secondary issue that we've been tackling in conjunction with the new toolbar designs. The main reason that I don't see that it must be solved in conjunction with this proposal is because, in the worst case, we can add an "activity toolbar button" at the far left of the primary toolbar which contains within it a place to keep, stop, name, tag, etc, just as we have now. On the other hand, we have been contemplating the possibility of removing this required element, instead attaching this functionality to the palettes for the running activities in the top of the Frame. This change would come with another, which would attempt to improve titling/tagging/describing of activities by gently prompting for some or all of this info *only* when a) the activity instance in question is "new" (was just started from scratch) and b) it hasn't yet been titled in another manner. It's uncertain if this prompt would come as a non-modal alert when starting the instance (which has the advantage of giving something a title before it gets shared on the mesh), or as a modal alert when stopping the activity it is hasn't yet been named. In both instances, it would happen before an entry with a non-meaningful title wound up in the Journal. Thoughts are welcome on these issues as well. > Another concern would be porting an activity like Calculate that has > numerous tabs of text based buttons. It's reasonable to create graphical > icons for the tabs (Edit, Algebra, Trig, Booleans, Constants, Format) but > not for some of the actual buttons (sin, cos, tan, asin, acos, atan, sinh, > cosh, tanh) Are you proposing that all text should be removed from the > toolbar or is it acceptable to have some text based icons? If text based > icons are allowed, do we need the option of localizing them? I'm not sure, > for example, how trigonometric functions are represented in other languages. Well, referencing the original mockups for calculate (and I think the more recent versions of the actual activity), you'll see that I actually did use "text" buttons, though they were in a more graphical forms than plain text. I think that this will be fine in some instances, on a case by case basis. Calculate is one such example, since "sin" and "cos" are more distinguishable than an image of a sin wave with the phase shifted by PI/2. Additionally, clicking these buttons actually inserts the text shown on them into the calculation, so using text makes sense. I don't think, however, that resorting to simple text-only buttons as a fallback is really something we should be too willing to accept on this platform, which explicitly aims to provide strong iconic visual cues for everything in the interface. Localization of icons is another point, and one that isn't necessarily exclusive to icons containing text. It is, however, a simple thing to do, as the path to the icon within the bundle can simply be localized in the normal fashion. > Finally, this requires someone with good graphical design skills to create > icons for complex activities that can't just reuse the template icons. My > point is that it's easy for programmers to create text based buttons, but > graphical ones will require more (and a different kind of) work. This is a fair observation, and one we've known would be hard for some. We hope that as an open source project there will be many people (occasionally myself included) willing to offer up this type of assistance when needed. We do also hope to have a pretty good collection of stock icons eventually. Finally, knowing that this would be a point of some difficulty, I created a python script for assisting in the creation of proper sugar icons, and a wiki page with a tutorial (not quite complete yet). You can find more info here: http://wiki.laptop.org/go/Making_Sugar_Icons. Thanks for the feedback! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
Eben wrote > Toolbar buttons use icons instead of text as an identifier. When I looked at http://wiki.laptop.org/go/Designs/Toolbars, there were no mock-ups there yet. So I'm not sure if you are referring to the (e.g., menu-bar) button which goes from the activity to a toolbar, or to a button which itself sits on a toolbar. Speaking for myself, "language" is more natural to me than "visual imagination". [I'm reminded of the story about older-generation people, who saw '?' signs in railway terminals, but had no idea what they meant.] An icon without text will be meaningful __once the user learns what that icon signifies__. A button supplying text will be meaningful to anyone who knows the language. You should not do away with text for those buttons which themselves sit on a toolbar. [Text names are NOT superfluous - if icons are to be primary in the UI, please supply "helper" text on roll-over.] mikus p.s. > Rather than residing in a secondary region solely for tabs, toolbar > buttons are first class citizens in toolbars; when clicked, they > reveal a second tier toolbar beneath the first, visually attached to > the toolbar button. I already commented in the wiki under Designs/Activity_Management that a similar 'tiering' scheme would be useful for organizing Activity icons (interchange your term "toolbar button" with my term "tab"). There are getting to be so many "draw pictures" Activities that in my opinion they ought to be organized into a secondary tier. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
On Tue, Mar 25, 2008 at 04:41:58PM +, Gary C Martin wrote: > > 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. I'm far from a UI designer, so I can't believe I'm about to say this, but if shifting is the issue, and the un-shifted (original toolbar upon/within which the new toolbar button is situated) cannot be used at the same time as the extra toolbar strip, then one solution would be to obscure the (temporarily unusable) original toolbar strip with the extra toolbar strip. A bit like Apple's Sheets (Document Modal Dialogs)[1], but only modal w.r.t. to the original toolbar. But I'm so far out of my depth I'm getting a nosebleed... > Regards, > Gary Martin 1. http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_7.html#//apple_ref/doc/uid/2961-CJECBHJE pgpUvdw4CeHPu.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
Eben, By no means do I consider myself a user interface expert, but I have a few comments. In general, I agree that this proposal is better for localization and may take up less screen real estate. Would there still be default buttons to share, keep, and/or stop the activity? I believe it's important to have an easy way to stop the current activity, but maybe you have this accounted for elsewhere in the frame redesign. I haven't had a chance to build and test Tomeu's branches yet. It looked like activities could be stopped from the frame, but no preference was given to the current activity. I'm not sure if this is convenient enough. If a stop button is required, and perhaps a share button and a keep button, this will eat up space and require most activities to use a secondary toolbar. Another concern would be porting an activity like Calculate that has numerous tabs of text based buttons. It's reasonable to create graphical icons for the tabs (Edit, Algebra, Trig, Booleans, Constants, Format) but not for some of the actual buttons (sin, cos, tan, asin, acos, atan, sinh, cosh, tanh) Are you proposing that all text should be removed from the toolbar or is it acceptable to have some text based icons? If text based icons are allowed, do we need the option of localizing them? I'm not sure, for example, how trigonometric functions are represented in other languages. Finally, this requires someone with good graphical design skills to create icons for complex activities that can't just reuse the template icons. My point is that it's easy for programmers to create text based buttons, but graphical ones will require more (and a different kind of) work. Thanks, Nate On Tue, Mar 25, 2008 at 10:47 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > A lot of thought has gone into the present tabbed toolbar design, with > goals of balancing valuable screen real estate with extensibility of > the design. Still, we've come to find some drawbacks with the current > design, including the sole use of text (which is secondary to icons in > the rest of the UI), the smaller height of the buttons which can make > them harder for children to click on, and the fact that, despite the > smaller height which was designed to save screen real estate, many > activities with few tabs may find them to be wasteful of space. > > 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: > > 1. Toolbar buttons use icons instead of text as an identifier. Beyond > the icon, we depend on the content of the toolbar to help define the > tab, with a textual name being superfluous. This makes localization > easier (well, free) and prevents text from being cut off in due to > translation. Toolbar buttons will reveal their toolbars temporarily on > rollover, as palettes do, allowing one to preview the content of a > toolbar without toggling it on, for discovery. OLPC will include > icons for a handful of common secondary toolbars in artwork for > developers to use. > > 2. Toolbar buttons are the size and shape of other buttons in the UI, > giving them a larger target area and making them easier to click on. > > 3. Rather than residing in a secondary region solely for tabs, toolbar > buttons are first class citizens in toolbars; when clicked, they > reveal a second tier toolbar beneath the first, visually attached to > the toolbar button. For activities that have few toolbars, this > offers the advantage of providing space for a "basic control set" in > the main toolbar, in addition to several auxiliary toolbars which can > be shown in conjunction with the primary toolbar, only when needed. > > 4. When a given activity needs only a few toolbars, this design saves > screen space during normal use of the activity. A good example is > Browse, which needs some basic edit and view controls to remain > available, but certainly not at all times during normal use. Here we > save space for the content by eliminating the "tab bar". This is a > tradeoff, though: advanced activities with many tabs may require the > primary toolbar to contain solely toolbar buttons, with the second > tier toolbar becoming the place where all the actual controls live. > In these cases, we lose a small amount of screen space (30px, > vertically, to be exact). > > 5. As a slight upside to the aforementioned tradeoff, the iconic > design of the toolbar buttons allows for up to twice as many toolbars > as the previous design, providing more extensibility in activities > that really need the space. Naturally, w
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
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. 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. 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. Can't see a practical solution to this just now, the only other option seems to be to have the revealed tool-bar strip appear over the activity, but that would cause even more UI issues as parts of activity real-estate get obscured. I guess (1) is the UI design flaw, (2) and (3) are technical issues that would need to be resolved and/or require developers to redesign their activities (other than just adding some pretty SVGs to their old tabs). Regards, Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
A lot of thought has gone into the present tabbed toolbar design, with goals of balancing valuable screen real estate with extensibility of the design. Still, we've come to find some drawbacks with the current design, including the sole use of text (which is secondary to icons in the rest of the UI), the smaller height of the buttons which can make them harder for children to click on, and the fact that, despite the smaller height which was designed to save screen real estate, many activities with few tabs may find them to be wasteful of space. 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: 1. Toolbar buttons use icons instead of text as an identifier. Beyond the icon, we depend on the content of the toolbar to help define the tab, with a textual name being superfluous. This makes localization easier (well, free) and prevents text from being cut off in due to translation. Toolbar buttons will reveal their toolbars temporarily on rollover, as palettes do, allowing one to preview the content of a toolbar without toggling it on, for discovery. OLPC will include icons for a handful of common secondary toolbars in artwork for developers to use. 2. Toolbar buttons are the size and shape of other buttons in the UI, giving them a larger target area and making them easier to click on. 3. Rather than residing in a secondary region solely for tabs, toolbar buttons are first class citizens in toolbars; when clicked, they reveal a second tier toolbar beneath the first, visually attached to the toolbar button. For activities that have few toolbars, this offers the advantage of providing space for a "basic control set" in the main toolbar, in addition to several auxiliary toolbars which can be shown in conjunction with the primary toolbar, only when needed. 4. When a given activity needs only a few toolbars, this design saves screen space during normal use of the activity. A good example is Browse, which needs some basic edit and view controls to remain available, but certainly not at all times during normal use. Here we save space for the content by eliminating the "tab bar". This is a tradeoff, though: advanced activities with many tabs may require the primary toolbar to contain solely toolbar buttons, with the second tier toolbar becoming the place where all the actual controls live. In these cases, we lose a small amount of screen space (30px, vertically, to be exact). 5. As a slight upside to the aforementioned tradeoff, the iconic design of the toolbar buttons allows for up to twice as many toolbars as the previous design, providing more extensibility in activities that really need the space. Naturally, we expect the majority of activities to be in the class which actually benefits from (4), having only a few toolbars, and the HIG will still recommend against bloat. Nonetheless, we think that the added extensibility is a plus. As this is an issue that effects every developer, I think that the mini-conference provides a fine opportunity to expose these ideas and discuss the pros and cons of the approach to come to a final decision on our direction. Thanks! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
