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 AB 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
On Thu, Apr 3, 2008 at 5:13 AM, Wade Brainerd [EMAIL PROTECTED] wrote: I wonder if the differences between Sugar and a regular window manager aren't so severe that it might be worth offering a simple desktop environment which runs within Sugar as a Activity? You would download and launch this Activity, and its interface would be a regular Linux desktop. It would support multiple windows, a taskbar, a start menu, etc. (I'm using Windows terms here). You could install and launch regular GTK+ applications in it, and they would not need to be sugarized at all. The GTK theme used by the Desktop would still match Sugar of course. If we did this, we would not be stuck with trying to shoehorn third party applications into a UI they were not designed for (one toplevel window, no menus) and would conceivably be able to launch any Linux app assuming the needed libraries were installed. I'm not an X windows expert, but does this sound like possible way to solve this issue? Someone wrapped Xephyr in an activity, so you get something similar to the Classic environment in OSX. You could run a full gnome or a single application inside that activity. But then the application would run in a different X server and wouldn't be able to copy paste, drag and drop, wouldn't be able to use hw acceleration, etc. Anyway, the problem here are not accidental incompatibilities as would be trying to run a KDE app in a GNOME-only installation. It was decided to part from the traditional desktop scheme because we aimed to offer a system that supports education, not office work. And I don't think that we should try to shoe-horn applications into activities. If an application's architecture separates the controller from the view and thus can expose a simple view component without controller stuff, then it's a relatively easy effort to wrap that view inside a widget and provide python bindings. Thus kids can modify and adapt all the python code around that black box immediately after receiving the XO. Regardless of that, I can understand how current application authors may feel frustrated by the additional effort required to port apps to activities, and of course welcome any contribution to make that easier. Apart from the debate of being easier or not to port apps with one or another architecture, I would like to point out the fact that if the project reaches its goals for the next year, there should be more developers for our platform than for Maemo or even the whole GNOME. So it's not like we are Apple, we'd have a much bigger potential in the not so long term. Also, GNOME apps are currently encouraged to provide those embeddable view widgets, as today do Abiword, Evince, Mozilla,... because of the GNOME Mobile initiative. Heard that someone was working on that for Gnumeric and I'd bet wouldn't be that hard for Inkscape. My point is that reusing all that code inside proper activities is not so hard, there are just too little hands yet. Please don't interpret my words as an opposition to increase compatibility with existing applications, take it as one more point of view on the problem. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs
On Thu, Apr 3, 2008 at 3:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Perhaps, in the intervening decade, first-world computer users have convinced themselves that they cannot adapt, but they are wrong. Humans are very adaptable. A teacher who has learned one version of Sugar will not have to spend more than a few days or hours with the new version before understanding it. I'm sure they can adapt, but they need to be motivated to do so. What could happen if we don't make sure these changes are well-received? I think that's Gregorio's message. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs
Let me ad that these changes are motivated from feedback in the field. What we are trying to change are precisely the things that people are finding confusing or difficult. Let me further add that very little teacher training has in fact taken place. What we have instead concentrated on is working with teachers on how to best leverage to tool to enhance learning inside and outside of the classroom. The very features of the new interface are designed to facilitate more collaboration, which is *the* distinguishing feature of Sugar. -walter On Thu, Apr 3, 2008 at 9:59 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Apr 3, 2008 at 3:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Perhaps, in the intervening decade, first-world computer users have convinced themselves that they cannot adapt, but they are wrong. Humans are very adaptable. A teacher who has learned one version of Sugar will not have to spend more than a few days or hours with the new version before understanding it. I'm sure they can adapt, but they need to be motivated to do so. What could happen if we don't make sure these changes are well-received? I think that's Gregorio's message. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [sugar] Mini-Conference Proposal: Toolbars Tabs
Hi All, I'm not opposed to changing the GUI at the OS level. I can think of a dozen suggestions starting with that annoying hot corners thing. I also love a whole bunch of the design elements. All I'm saying is that any change comes at a cost. A cost paid by the teachers, students and people who train more than the developers. The cost also increases with time. I want to make sure you take that in to consideration. I'm not talking about the time OLPC has spent training people. I'm talking about the time sys admins and technicians have spent training teachers in country. Dozens of people spent days doing teacher training in Uruguay and they said it took several days of training for the teachers to start feeling comfortable with the XO. I believe new teams of volunteers in Uruguay have recently been expanding the training. Nepal also started teacher training and they reported that it's a key variable to their success. I think I heard that Peru has started training a few hundred teachers too. I'm not sure about other deployments. If the teachers and trainers know what the changes are, they want them and are not concerned about having to re-learn or re-train, then its fine with me. My point is to keep the users in the loop. If you dictate changes without user input that doesn't foster collaboration and empowerment. Sounds like you have the users in the loop and you're covered. Great! You definitely did a lot of things right in the first pass. I'm sure you'll nail it again in the next revision. My only suggestion is that once you have a new design, you show it to some teachers and trainers before you lock it down. Even better give them a range of options and see which works best for them. There's a technical, economic, cultural, urban - rural, north - south divide that we have to span here. That comes to the fore in the GUI more than anywhere else (except maybe available actvities). Let's not lose our chance to make the design process a two way collaboration which bridges that divide. Thanks, Greg S -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Walter Bender Sent: Thursday, April 03, 2008 10:07 AM To: Tomeu Vizoso; [EMAIL PROTECTED]; devel@lists.laptop.org; Greg Smith (gregmsmi) Subject: Re: [sugar] Mini-Conference Proposal: Toolbars Tabs Let me ad that these changes are motivated from feedback in the field. What we are trying to change are precisely the things that people are finding confusing or difficult. Let me further add that very little teacher training has in fact taken place. What we have instead concentrated on is working with teachers on how to best leverage to tool to enhance learning inside and outside of the classroom. The very features of the new interface are designed to facilitate more collaboration, which is *the* distinguishing feature of Sugar. -walter On Thu, Apr 3, 2008 at 9:59 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Thu, Apr 3, 2008 at 3:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Perhaps, in the intervening decade, first-world computer users haveconvinced themselves that they cannot adapt, but they are wrong. Humansare very adaptable. A teacher who has learned one version of Sugar willnot have to spend more than a few days or hours with the new versionbefore understanding it. I'm sure they can adapt, but they need to be motivated to do so. What could happen if we don't make sure these changes are well-received? I think that's Gregorio's message. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
re: [sugar] Mini-Conference Proposal: Toolbars Tabs
Greg Smith wrote: I'm not opposed to changing the GUI at the OS level. I can think of a dozen suggestions starting with that annoying hot corners thing. I also love a whole bunch of the design elements. All I'm saying is that any change comes at a cost. A cost paid by the teachers, students and people who train more than the developers. The cost also increases with time. I want to make sure you take that in to consideration. Walter Bender wrote: Let me further add that very little teacher training has in fact taken place. What we have instead concentrated on is working with teachers on how to best leverage to tool to enhance learning inside and outside of the classroom. Here in Nepal we have put a ton of effort into teacher training. This has been constructivist training where we introduce the features of the XO, the teachers work together in peer-to-peer interaction, then the teachers gave us their feedback and suggestions. Our teacher training may be very small in scale compared to other OLPC deployments, but our team here in Nepal has put a lot of heart and soul into it. I simply ask that OLPC and the conference participants very carefully consider large-scale changes. -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs
The win-win is when this piece of Greg's advice is followed: ...Just make sure its not a surprise to existing users. Also make sure they are bought in, understand the benefit and are ready to make the move. ... Greg Smith (gregmsmi) Thu, 03 Apr 2008 06:24:10 -0700 And Bryan seems to have the perfect environment to engage the teachers in a preview/review of the contemplated improvements and fulfill the suggestion: ...This has been constructivist training where we introduce the features of the XO, the teachers work together in peer-to-peer interaction, then the teachers gave us their feedback and suggestions. ... Bryan Berry Thu, 03 Apr 2008 20:46:22 -0700 OLPC is really making history with all your great work! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
On Wed, Mar 26, 2008 at 12:39 AM, Albert Cahalan [EMAIL PROTECTED] wrote: Eben Eliason writes: 1. Toolbar buttons use icons instead of text as an identifier. Beyond Just to throw another dog into this fight, I've recently been very concerned with making legacy applications work as well as possible in the sugar environment. They will likely always be second-class citizens, as they weren't originally designed for kids, may be overly complex, etc, but it's clear that the limited developer resources at OLPC don't have time to (for example) develop a full-fledged kid-friendly video- and sound-editing application, yet that's the next thing that kids want to do when given Record. There are some very nice programs out there in linux land, we'd like to make using them reasonably *possible*. Eventually, of course, we'd like to see a (for example) inkscape port which emphasized UI simplicity, kid-friendliness, and the rest of the Sugar guidelines, but at the moment we're stuck using inkscape as is. Could someone with some experience with GTK/Gnome themes comment briefly on how reasonable it would be to create a theme to make legacy applications look as much as possible like our old sugar and new sugar proposal? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
On Wed, 2008-04-02 at 13:27 -0400, C. Scott Ananian wrote: On Wed, Mar 26, 2008 at 12:39 AM, Albert Cahalan [EMAIL PROTECTED] wrote: Eben Eliason writes: 1. Toolbar buttons use icons instead of text as an identifier. Beyond Just to throw another dog into this fight, I've recently been very concerned with making legacy applications work as well as possible in the sugar environment. They will likely always be second-class citizens, as they weren't originally designed for kids, may be overly complex, etc, but it's clear that the limited developer resources at OLPC don't have time to (for example) develop a full-fledged kid-friendly video- and sound-editing application, yet that's the next thing that kids want to do when given Record. There are some very nice programs out there in linux land, we'd like to make using them reasonably *possible*. Eventually, of course, we'd like to see a (for example) inkscape port which emphasized UI simplicity, kid-friendliness, and the rest of the Sugar guidelines, but at the moment we're stuck using inkscape as is. As the parent of a 13 and 10 year old, I know that they both want things beyond what we can currently give them with Sugarized applications Could someone with some experience with GTK/Gnome themes comment briefly on how reasonable it would be to create a theme to make legacy applications look as much as possible like our old sugar and new sugar proposal? Heh... Our theme is just a GTK theme Lots of things just work. This isn't rocket science... We can make it so, if we decide to - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
I wonder if the differences between Sugar and a regular window manager aren't so severe that it might be worth offering a simple desktop environment which runs within Sugar as a Activity? You would download and launch this Activity, and its interface would be a regular Linux desktop. It would support multiple windows, a taskbar, a start menu, etc. (I'm using Windows terms here). You could install and launch regular GTK+ applications in it, and they would not need to be sugarized at all. The GTK theme used by the Desktop would still match Sugar of course. If we did this, we would not be stuck with trying to shoehorn third party applications into a UI they were not designed for (one toplevel window, no menus) and would conceivably be able to launch any Linux app assuming the needed libraries were installed. I'm not an X windows expert, but does this sound like possible way to solve this issue? Best, Wade On Wed, Apr 2, 2008 at 5:38 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 7:27 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Could someone with some experience with GTK/Gnome themes comment briefly on how reasonable it would be to create a theme to make legacy applications look as much as possible like our old sugar and new sugar proposal? The look of each single toolbar (color, spacing, icon size etc) is dictated by the theme, so the styles should be already consistent. Sugar is basically taking one or more standard gtk toolbars and grouping them together. Though the sugar design uses multiple toolbars as a substitute of menus in standard gtk applications. And there is not much we can do about that kind of incompatibility (which is fine, perhaps). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 pgp3ZDyy3e6lC.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars Tabs (or lack thereof)
Eben Eliason writes: 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. I hope you don't mean to suggest eliminating the text. Reading should be encouraged, not banished. Tux Paint, a program commonly used by kids who are many years younger than school age, is full of text. It is all localized. We deal with problems (text being cut off, etc.) as they happen. Putting text labels on everything is an excellent way to encourage reading. It is very sad that the hardware isn't covered in labels, but at least the hardware has a bit of an excuse. (logistics) Software has no such excuse; every icon needs text. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
