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
2009/9/11 Gary C Martin g...@garycmartin.com: 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 g...@garycmartin.com: 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
Or I might be nit-picking... Eduardo 2009/9/12 Eduardo H. Silva hoboprim...@gmail.com: 2009/9/11 Gary C Martin g...@garycmartin.com: 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 g...@garycmartin.com: 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 12 Sep 2009, at 16:34, Eduardo H. Silva wrote: 2009/9/11 Gary C Martin g...@garycmartin.com: 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
2009/9/12 Gary C Martin g...@garycmartin.com: On 12 Sep 2009, at 16:34, Eduardo H. Silva wrote: 2009/9/11 Gary C Martin g...@garycmartin.com: 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 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
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
[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
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
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 inline: colour_picker_mockup.png ___ 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 g...@garycmartin.com: 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 g...@garycmartin.com: 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
