Re: [Sugar-devel] [Design] ColorButton
Added to [[The undiscoverable]]. On Thu, Sep 10, 2009 at 3:54 AM, Simon Schampijer wrote: > Hi, > > currently the ColorButton is not fully clear in it's behavior (see > http://dev.sugarlabs.org/ticket/388). Click outside the palette to close > it etc. The problem in the bug is that clicking outside the palette but in the editing area deselects any selected text without applying the color first. A workaround is to select text, select color, click anywhere on the toolbar. I added this in a comment on the bug. > Benjamin suggested to have an ok/cancel button to make the end > of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 I assume that you mean something like the palette controls in Paint. (Screenshot attached.) Would we want to unify these palettes? If Write can apply the color before deselecting the text, or without deselecting the text, users will have a much easier time. But that may not be what users want. Should clicking outside the box mean OK or Cancel? I consider it fundamental to UI design that clicking to get focus in a window or remove it from a dialogue box should not trigger any action in the window being activated. > Do others agree? Other thoughts? Do we have any way to ask the children's opinion on such design issues? > Thanks, > Simon > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://earthtreasury.org/ <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
Aleksey Lim writes: > Another option is that picker should contain only predefined colors > (and maybe one custom) by default and having click-to-close behaviour. > Then if users want to make(change) custom color, they click "add.." > (or so) button and palette opens right panel and click on predefined > color will just change custom color. Here are two ideas that would be interesting to test with users who lack the expectation that a proper selector is defined by Microsoft and/or Adobe. The first is simply a colorful square that you click on. The trouble is that most methods of mapping the 3-D RGB space onto a 2-D square are really awful. Consider a 3-D space-filling curve in a 64*64*64 color cube. Use that to map 0x4 colors onto a 1-D space. Now consider a 2-D space-filling curve in a 512*512 square. Use that to map the 1-D space onto a 2-D image. The result is that you can cover the RGB space nicely, with similar colors mostly together. This should be precomputed. Also note that the 64*64*64 would ideally have the spacing adjusted for gamma; try 1.0 and 1.8 for gamma. The second is an iterative selector with a notion of "current" color. The selector displays color patches that are visually related to the current color. Each time you click on a patch, it becomes current. This lets the user walk his way through the color space, allowing access to all colors without the need to understand color spaces. The user just picks the closest color of those available until he is happy with the current color. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On 12 Sep 2009, at 18:46, Benjamin Berg wrote: > On Thu, 2009-09-10 at 18:37 +0100, Gary C Martin wrote: >> Is it possible to emit the colour change event as soon as a colour is >> clicked? Or, perhaps emit as soon as the mouse leaves the palette >> area? > > The palette change signal is emitted as soon as the palette is closed > currently (notify:color is emitted continuously when the color is > modified). > The idea of emitting the signal slightly earlier, ie. when the mouse > leaves the palette, sounds like a good solution to me. It would > prevent > the issue where one clicks outside the palette and the selection is > gone > before the color-changed signal is fired. +1, yep that's the use case that's causing us problems currently in Write. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On Thu, 2009-09-10 at 18:37 +0100, Gary C Martin wrote: > Is it possible to emit the colour change event as soon as a colour is > clicked? Or, perhaps emit as soon as the mouse leaves the palette area? The palette change signal is emitted as soon as the palette is closed currently (notify:color is emitted continuously when the color is modified). The idea of emitting the signal slightly earlier, ie. when the mouse leaves the palette, sounds like a good solution to me. It would prevent the issue where one clicks outside the palette and the selection is gone before the color-changed signal is fired. Benjamin signature.asc Description: This is a digitally signed message part ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
2009/9/12 Gary C Martin : > On 12 Sep 2009, at 16:34, Eduardo H. Silva wrote: > >> 2009/9/11 Gary C Martin : >>> >>> On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: >>> Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. >>> >>> No, down arrows indicate the new lockable secondary toolbars (one click >>> to >>> lock open, one click to lock closed, hover for temporary quick use like a >>> palette). Locking open secondary toolbars resizes the activity canvas >>> area, >>> normal toolbar palettes do not. >>> >>> FWIW: it has been agreed (I think) that any icons that have _NO_ default >>> primary function (i.e. they just hold palettes) should instantly, and >>> fully >>> expose on a single left click (as they already do for a single right >>> click). >>> As their primary function is to display their palette. Maybe we can solve >>> this for 0.88. This would solve things like providing instant feedback on >>> buddy icons, such as accessing the large self buddy icon in the home view >>> for getting to settings, shutdown etc. >> >> But shouldn't something be done visually to differentiate those icons >> which open palettes when clicked, from those which act their primary >> action? The user won't know beforehand what will the result of >> clicking be otherwise. > > > Yes, I do acknowledge this point, unfortunately all the visual 'cures' I've > seen mentioned or tried to think up so far are worse than the 'illness'. The > Sugar UI usage of icons with a primary action vs. no primary action would > seem to be about 50/50, so any visual treatment would have to look good on > ~50% of all icons you see. For the new toolbar lock open/closed 'v' shape, > it requires almost all those icons to be re-adjusted/designed from scratch > with that extra empty space required below. > > I guess I'd try to argue for better icon design to start with, so that the > author made sure they clearly distinguished icons for single click actions, > from icons exposing a palette of actions. Good point. The color button in Write is a good example of that. > Could I ask you indicate some example cases where you see potential > confusion? Perhaps we can improve their icon designs. To be honest I don't have a use case to show, perhaps it's just a potential problem that doesn't manifest itself. Eduardo > Regards, > --Gary > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On 12 Sep 2009, at 16:34, Eduardo H. Silva wrote: > 2009/9/11 Gary C Martin : >> On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: >> >>> Should the toolbar icon for the colors palette have a down arrow >>> like >>> with the other toolbar button icons? After all, it doesn't execute a >>> primary action of its pallete when clicking, instead it reveals its >>> palette. >> >> No, down arrows indicate the new lockable secondary toolbars (one >> click to >> lock open, one click to lock closed, hover for temporary quick use >> like a >> palette). Locking open secondary toolbars resizes the activity >> canvas area, >> normal toolbar palettes do not. >> >> FWIW: it has been agreed (I think) that any icons that have _NO_ >> default >> primary function (i.e. they just hold palettes) should instantly, >> and fully >> expose on a single left click (as they already do for a single >> right click). >> As their primary function is to display their palette. Maybe we can >> solve >> this for 0.88. This would solve things like providing instant >> feedback on >> buddy icons, such as accessing the large self buddy icon in the >> home view >> for getting to settings, shutdown etc. > > But shouldn't something be done visually to differentiate those icons > which open palettes when clicked, from those which act their primary > action? The user won't know beforehand what will the result of > clicking be otherwise. Yes, I do acknowledge this point, unfortunately all the visual 'cures' I've seen mentioned or tried to think up so far are worse than the 'illness'. The Sugar UI usage of icons with a primary action vs. no primary action would seem to be about 50/50, so any visual treatment would have to look good on ~50% of all icons you see. For the new toolbar lock open/closed 'v' shape, it requires almost all those icons to be re-adjusted/designed from scratch with that extra empty space required below. I guess I'd try to argue for better icon design to start with, so that the author made sure they clearly distinguished icons for single click actions, from icons exposing a palette of actions. Could I ask you indicate some example cases where you see potential confusion? Perhaps we can improve their icon designs. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
Or I might be nit-picking... Eduardo 2009/9/12 Eduardo H. Silva : > 2009/9/11 Gary C Martin : >> On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: >> >>> Should the toolbar icon for the colors palette have a down arrow like >>> with the other toolbar button icons? After all, it doesn't execute a >>> primary action of its pallete when clicking, instead it reveals its >>> palette. >> >> No, down arrows indicate the new lockable secondary toolbars (one click to >> lock open, one click to lock closed, hover for temporary quick use like a >> palette). Locking open secondary toolbars resizes the activity canvas area, >> normal toolbar palettes do not. >> >> FWIW: it has been agreed (I think) that any icons that have _NO_ default >> primary function (i.e. they just hold palettes) should instantly, and fully >> expose on a single left click (as they already do for a single right click). >> As their primary function is to display their palette. Maybe we can solve >> this for 0.88. This would solve things like providing instant feedback on >> buddy icons, such as accessing the large self buddy icon in the home view >> for getting to settings, shutdown etc. > > But shouldn't something be done visually to differentiate those icons > which open palettes when clicked, from those which act their primary > action? The user won't know beforehand what will the result of > clicking be otherwise. > > Eduardo > >> >> Regards, >> --Gary >> >>> Eduardo >>> >>> 2009/9/10 Gary C Martin : On 10 Sep 2009, at 12:01, Aleksey Lim wrote: > On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: >> >> Hi, >> >> currently the ColorButton is not fully clear in it's behavior (see >> http://dev.sugarlabs.org/ticket/388). Click outside the palette to >> close >> it etc. Benjamin suggested to have an ok/cancel button to make the end >> of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 >> >> Do others agree? Other thoughts? > > Another option is that picker should contain only predefined > colors(and maybe one custom) by default and having > click-to-close behaviour. Then if users want to make(change) custom > color, they click "add.."(or so) button and palette opens right panel > and click on predefined color will just change custom color. > > btw having select-to-close behavior(at least by default) we will keep > things consistent, e.g. to select suboptions from palette menus, user > needs only one click. Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like (no other palettes use this behaviour). The click a colour to dismiss, with the addition of a 'custom colour' icon seems more natural, but looses a current nice feature where by you can pick a preset colour, see the sliders move, and then adjust them if you want to tweak. It also seems a little odd seeing both the toolbar icon and the custom icon changing colour at same time (see attachment below), though I guess in this case the toolbar icon could only change once you make a choice (and as you move a cursor around a document with colours). Anyway, all this makes me think that solving the issue by emitting colour change events early (i.e. not just when palette closes) would be a cleaner solution (more like a bug fix for a current unintended behaviour rather than redesigning an already good UI to avoid it). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
2009/9/11 Gary C Martin : > On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: > >> Should the toolbar icon for the colors palette have a down arrow like >> with the other toolbar button icons? After all, it doesn't execute a >> primary action of its pallete when clicking, instead it reveals its >> palette. > > No, down arrows indicate the new lockable secondary toolbars (one click to > lock open, one click to lock closed, hover for temporary quick use like a > palette). Locking open secondary toolbars resizes the activity canvas area, > normal toolbar palettes do not. > > FWIW: it has been agreed (I think) that any icons that have _NO_ default > primary function (i.e. they just hold palettes) should instantly, and fully > expose on a single left click (as they already do for a single right click). > As their primary function is to display their palette. Maybe we can solve > this for 0.88. This would solve things like providing instant feedback on > buddy icons, such as accessing the large self buddy icon in the home view > for getting to settings, shutdown etc. But shouldn't something be done visually to differentiate those icons which open palettes when clicked, from those which act their primary action? The user won't know beforehand what will the result of clicking be otherwise. Eduardo > > Regards, > --Gary > >> Eduardo >> >> 2009/9/10 Gary C Martin : >>> >>> On 10 Sep 2009, at 12:01, Aleksey Lim wrote: >>> On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: > > Hi, > > currently the ColorButton is not fully clear in it's behavior (see > http://dev.sugarlabs.org/ticket/388). Click outside the palette to > close > it etc. Benjamin suggested to have an ok/cancel button to make the end > of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 > > Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click "add.."(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. >>> >>> Is it possible to emit the colour change event as soon as a colour is >>> clicked? Or, perhaps emit as soon as the mouse leaves the palette area? >>> >>> I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like >>> (no other palettes use this behaviour). The click a colour to dismiss, >>> with >>> the addition of a 'custom colour' icon seems more natural, but looses a >>> current nice feature where by you can pick a preset colour, see the >>> sliders >>> move, and then adjust them if you want to tweak. It also seems a little >>> odd >>> seeing both the toolbar icon and the custom icon changing colour at same >>> time (see attachment below), though I guess in this case the toolbar icon >>> could only change once you make a choice (and as you move a cursor around >>> a >>> document with colours). >>> >>> Anyway, all this makes me think that solving the issue by emitting colour >>> change events early (i.e. not just when palette closes) would be a >>> cleaner >>> solution (more like a bug fix for a current unintended behaviour rather >>> than >>> redesigning an already good UI to avoid it). >>> >>> Regards, >>> --Gary >>> >>> >>> >>> >>> >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote: > Should the toolbar icon for the colors palette have a down arrow like > with the other toolbar button icons? After all, it doesn't execute a > primary action of its pallete when clicking, instead it reveals its > palette. No, down arrows indicate the new lockable secondary toolbars (one click to lock open, one click to lock closed, hover for temporary quick use like a palette). Locking open secondary toolbars resizes the activity canvas area, normal toolbar palettes do not. FWIW: it has been agreed (I think) that any icons that have _NO_ default primary function (i.e. they just hold palettes) should instantly, and fully expose on a single left click (as they already do for a single right click). As their primary function is to display their palette. Maybe we can solve this for 0.88. This would solve things like providing instant feedback on buddy icons, such as accessing the large self buddy icon in the home view for getting to settings, shutdown etc. Regards, --Gary > Eduardo > > 2009/9/10 Gary C Martin : >> On 10 Sep 2009, at 12:01, Aleksey Lim wrote: >> >>> On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/ 388#comment:7 Do others agree? Other thoughts? >>> >>> Another option is that picker should contain only predefined >>> colors(and maybe one custom) by default and having >>> click-to-close behaviour. Then if users want to make(change) custom >>> color, they click "add.."(or so) button and palette opens right >>> panel >>> and click on predefined color will just change custom color. >>> >>> btw having select-to-close behavior(at least by default) we will >>> keep >>> things consistent, e.g. to select suboptions from palette menus, >>> user >>> needs only one click. >> >> Is it possible to emit the colour change event as soon as a colour is >> clicked? Or, perhaps emit as soon as the mouse leaves the palette >> area? >> >> I tried some quick mockups, the OK/Cancel doesn't feel very Sugar >> UI like >> (no other palettes use this behaviour). The click a colour to >> dismiss, with >> the addition of a 'custom colour' icon seems more natural, but >> looses a >> current nice feature where by you can pick a preset colour, see the >> sliders >> move, and then adjust them if you want to tweak. It also seems a >> little odd >> seeing both the toolbar icon and the custom icon changing colour at >> same >> time (see attachment below), though I guess in this case the >> toolbar icon >> could only change once you make a choice (and as you move a cursor >> around a >> document with colours). >> >> Anyway, all this makes me think that solving the issue by emitting >> colour >> change events early (i.e. not just when palette closes) would be a >> cleaner >> solution (more like a bug fix for a current unintended behaviour >> rather than >> redesigning an already good UI to avoid it). >> >> Regards, >> --Gary >> >> >> >> >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
Should the toolbar icon for the colors palette have a down arrow like with the other toolbar button icons? After all, it doesn't execute a primary action of its pallete when clicking, instead it reveals its palette. Eduardo 2009/9/10 Gary C Martin : > On 10 Sep 2009, at 12:01, Aleksey Lim wrote: > >> On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: >>> >>> Hi, >>> >>> currently the ColorButton is not fully clear in it's behavior (see >>> http://dev.sugarlabs.org/ticket/388). Click outside the palette to close >>> it etc. Benjamin suggested to have an ok/cancel button to make the end >>> of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 >>> >>> Do others agree? Other thoughts? >> >> Another option is that picker should contain only predefined >> colors(and maybe one custom) by default and having >> click-to-close behaviour. Then if users want to make(change) custom >> color, they click "add.."(or so) button and palette opens right panel >> and click on predefined color will just change custom color. >> >> btw having select-to-close behavior(at least by default) we will keep >> things consistent, e.g. to select suboptions from palette menus, user >> needs only one click. > > Is it possible to emit the colour change event as soon as a colour is > clicked? Or, perhaps emit as soon as the mouse leaves the palette area? > > I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like > (no other palettes use this behaviour). The click a colour to dismiss, with > the addition of a 'custom colour' icon seems more natural, but looses a > current nice feature where by you can pick a preset colour, see the sliders > move, and then adjust them if you want to tweak. It also seems a little odd > seeing both the toolbar icon and the custom icon changing colour at same > time (see attachment below), though I guess in this case the toolbar icon > could only change once you make a choice (and as you move a cursor around a > document with colours). > > Anyway, all this makes me think that solving the issue by emitting colour > change events early (i.e. not just when palette closes) would be a cleaner > solution (more like a bug fix for a current unintended behaviour rather than > redesigning an already good UI to avoid it). > > Regards, > --Gary > > > > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On 10 Sep 2009, at 12:01, Aleksey Lim wrote: On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click "add.."(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. Is it possible to emit the colour change event as soon as a colour is clicked? Or, perhaps emit as soon as the mouse leaves the palette area? I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like (no other palettes use this behaviour). The click a colour to dismiss, with the addition of a 'custom colour' icon seems more natural, but looses a current nice feature where by you can pick a preset colour, see the sliders move, and then adjust them if you want to tweak. It also seems a little odd seeing both the toolbar icon and the custom icon changing colour at same time (see attachment below), though I guess in this case the toolbar icon could only change once you make a choice (and as you move a cursor around a document with colours). Anyway, all this makes me think that solving the issue by emitting colour change events early (i.e. not just when palette closes) would be a cleaner solution (more like a bug fix for a current unintended behaviour rather than redesigning an already good UI to avoid it). Regards, --Gary <> ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote: > Hi, > > currently the ColorButton is not fully clear in it's behavior (see > http://dev.sugarlabs.org/ticket/388). Click outside the palette to close > it etc. Benjamin suggested to have an ok/cancel button to make the end > of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 > > Do others agree? Other thoughts? Another option is that picker should contain only predefined colors(and maybe one custom) by default and having click-to-close behaviour. Then if users want to make(change) custom color, they click "add.."(or so) button and palette opens right panel and click on predefined color will just change custom color. btw having select-to-close behavior(at least by default) we will keep things consistent, e.g. to select suboptions from palette menus, user needs only one click. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Design] ColorButton
Hi, currently the ColorButton is not fully clear in it's behavior (see http://dev.sugarlabs.org/ticket/388). Click outside the palette to close it etc. Benjamin suggested to have an ok/cancel button to make the end of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7 Do others agree? Other thoughts? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel