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 ___ 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
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
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
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 > 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
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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Smith (gregmsmi) wrote: | Thousands of hours of teacher training have already gone in to the | current XO deployments. Any dramatic change to the look and feel of the | GUI will largely negate that. I strongly disagree; indeed, I feel precisely the opposite. The classic case is the arrival of Windows 95. Windows 95 used a completely different GUI metaphor from Windows 3.1 (the preceding version). Absolutely everything was entirely different: the multitasking metaphor, the launch metaphor, the nature of the window management, the desktop metaphor... all completely new. The interface bore no resemblance to the previous version. Windows 95 sold millions of copies, and was a breakthrough sales leader for Microsoft. I heard endless glowing reviews of the interface. I never heard anyone complain that they had to relearn everything. In part, this was because the applications had not changed greatly. The same would be true in our case: redesigning Sugar does not change which Activities it runs. 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 strongly encourage the Sugar team to choose a "legacy free" philosophy. ~ The user interface should be improved whenever it is possible to do so. Changes to the underlying system that break existing Activities should not be avoided either; the Activity developers will make the necessary changes, as we have been doing all along. Ultimately, this is a moot point. Major changes to Sugar, even after the current redesign, are necessary, and they are coming. They include pervasive chat, bulletin boards, buddy groups, new datastore, and other major improvements. I look forward to their implementation. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9N+PUJT6e6HFtqQRAn30AJsGBwK0Z7XX9FAOtn6jGalwErAijwCfd44h atdVnK5vx3a4h+kE7TlFLOs= =CMVg -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs
Hi All, I can't make the mini-conference, but I do want to make one comment on this subject. Thousands of hours of teacher training have already gone in to the current XO deployments. Any dramatic change to the look and feel of the GUI will largely negate that. Its already very costly to make a big change to look and feel. Of course, as time goes by more teachers get trained and its even more costly. My suggestion is to only make a major change once. Make it fully backward compatible or optional if possible. Check with the deployments before you do it and make sure they agree its needed and worth the re-training effort. If a couple of hundred classes are just getting comfortable with the XO, a change may make them they feel totally lost. That will negatively affect user satisfaction, even if the new design has a lot of benefits. I understand the need to make it easier to include new applications and to expand the developer base. Maybe now is the time to do that. 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. Do that before you commit any real work to the new look and feel. Having a great kid and teacher friendly GUI has enormous value. Get that right and the whole project will be more successful. That challenge is that once you pick a strategy its very hard to change. So spend extra time up front ensuring it's a winner the first time you roll it out. HTHs. I look forward to notes from the conference. Thanks, Greg S ___ 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 3:10 PM, Wade Brainerd <[EMAIL PROTECTED]> wrote: > On Thu, Apr 3, 2008 at 3:09 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > 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. > > This is true for "core" applications, but I think there is value to > considering those "extra" applications in the Linux world that might > have some use to students, say some obscure math program or video > editing tool. Absolutely, I just wanted to remember that, one day, OLPC will be the biggest linux "desktop" deployment, and will be like that for several years. That will allow (and force) us to set the rules. Of course, several things need to happen until that day comes, and compatibility with already written software is one of those. 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 3:09 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > 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. I agree completely! I have tried to shoe-horn applications into Sugar (that's how we started Colors!) but it did not go well. I have also taken the time to properly build applications in Sugar and the result has been worth it. But it's important to understand that much of the complexity of today's desktop applications is in the user interface design, and so it's not a simple thing to just "wrap a new one" for Sugar even if the code is already well organized. I'm also concerned with advanced users (even kids) who are not application developers and are limited to installing libraries, but might not want to have to reflash with Ubuntu just to access something like wxMaxima. Providing a functional embedded desktop environment would be a great stopgap measure to eliminate these complaints while the activity library is filled in. I'm just not sure about what would be needed to make it work "well". Full Gnome inside an Activity is probably too heavy, but is there some stripped down version that could be used? > 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. This is true for "core" applications, but I think there is value to considering those "extra" applications in the Linux world that might have some use to students, say some obscure math program or video editing tool. Best, Wade ___ 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 (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 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
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)
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)
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
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)
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 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 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)
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel