Re: [Inkscape-devel] Mockup for Improvement of Fill and Stroke Dialog
Hi again :)
Okay so after previous feedback, that the comboboxes for the fill type and fill rule were not optimal (i.e. it is quicker to click a button than select something from a combobox), I have ammended the mockups, adding back in the buttons.
I also corrected some padding in places, where I seem to have gone a bit mad with it :)
Please see the two mockups here http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_...
Again I really do welcome feedback, positive or negative :)
On 2011-04-08 12:07, Andrew wrote:
Hi again :)
Okay so after previous feedback, that the comboboxes for the fill type and fill rule were not optimal (i.e. it is quicker to click a button than select something from a combobox), I have ammended the mockups, adding back in the buttons.
I also corrected some padding in places, where I seem to have gone a bit mad with it :)
Please see the two mockups here http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_...
Again I really do welcome feedback, positive or negative :)
Esthetically I prefer the old (non-bevelled) "buttons" for selecting the fill type and rule (the bevels make it look a bit crowded, as there are so many options), but other than that I have no complaints and would absolutely love to see this happen.
On 8/4/11 13:30, Jasper van de Gronde wrote:
On 2011-04-08 12:07, Andrew wrote:
Okay so after previous feedback, that the comboboxes for the fill type and fill rule were not optimal (i.e. it is quicker to click a button than select something from a combobox), I have ammended the mockups, adding back in the buttons.
I also corrected some padding in places, where I seem to have gone a bit mad with it :)
Please see the two mockups here http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_...
Again I really do welcome feedback, positive or negative :)
Esthetically I prefer the old (non-bevelled) "buttons" for selecting the fill type and rule (the bevels make it look a bit crowded, as there are so many options), but other than that I have no complaints and would absolutely love to see this happen.
a) flat buttons 1+ on using flat icons and not 'regular' buttons for the fill/stroke types (I guess it would not be in accordance to the Gnome HIG? ;) ). These types of flat buttons are used in other places of the GUI as well, e.g. in the 'Align & Distribute' dialog.
b) sliders vs spinboxes I'm not sure about removing the sliders for opacity and blur (the extension dialogs recently got a new widget to alternatively display sliders in addition to spinboxes). Many users seem to appreciate sliders if values don't need to be set to precise values but freely adjusted to achieve a visually pleasing result (technical vs artistic drawing?).
c) window decoration Getting rid of the standard GTK Window Bar and replacing it with a custom one: wouldn't this either have to be done for all dockable dialogs (once all or most of them have been made dockable, a feature repeatedly requested by Inkscape users), instead of creating a single exception how a floating dialog (which is docked with default settings) looks? Also, does a custom solution work well with different window managers (and on other platforms, e.g. those which don't use the X11 backend of GTK+)?
d) minimal dialog width Unrelated (since it was not mentioned in the redesign proposal) question (but possibly with some relevance when refactoring dialogs?): What does or should determine the overall minimal (or default) width of the dialog? At the moment the length of the (translated) strings of the labels will considerably affect the minimal or default width, e.g. - the labels of the notebook tabs at the top as seen in this screenshot [1] from the inkscape-devel archives [2] (has improved since) - the labels of the various options in the 'Stroke style' tab Test yourself with e.g. 'German' as UI language: the labels in the 'Stroke style' tab will extend the overall minimal width of the dialog unproportionally IMHO. - names of custom patterns or markers seen e.g. with SVG files created by third-party applications [1] Could this be handled differently in how the dialog is coded, or - with regard to the translations - is it completely up to the translators?
~suv
[1] http://dl.dropbox.com/u/1047321/inkscape/fat_ui.png [2] http://article.gmane.org/gmane.comp.graphics.inkscape.devel/30362 [3] https://bugs.launchpad.net/inkscape/+bug/596842/+attachment/1432106/+files/SequenceFlowDefault.svg
Hi, I like it better than our current dialog, which is visually too crowded.
However, turn the fill type (3) and color model (5) buttons into flat buttons as other suggested and that would be perfect.
One last detail: in the blur slider you put 'px' as units, but I'm not quite sure if those units are given in pixels or % of the size of the blurred object...
Regards.
On 2011-04-08 15:58, Pajarico wrote:
Hi, I like it better than our current dialog, which is visually too crowded.
However, turn the fill type (3) and color model (5) buttons into flat buttons as other suggested and that would be perfect.
One last detail: in the blur slider you put 'px' as units, but I'm not quite sure if those units are given in pixels or % of the size of the blurred object...
Good point. % is more appropriate than px (it is relative to the size of the blurred object). Personally I don't like the current system, as I'm used to thinking in absolute units, but the idea is that objects blurred with the same "percentage" of blur more or less look equally blurry. I think it is currently defined as a percentage of the sum of the width and height of the bounding box or something like that. If you can think of a better way to do this you'd make my day :)
Hi,
Esthetically I prefer the old (non-bevelled) "buttons" for selecting the fill type and rule (the bevels make it look a bit crowded, as there are so many options), but other than that I have no complaints and would absolutely love to see this happen.
a) flat buttons 1+ on using flat icons and not 'regular' buttons for the fill/stroke types (I guess it would not be in accordance to the Gnome HIG? ;) ). These types of flat buttons are used in other places of the GUI as well, e.g. in the 'Align & Distribute' dialog.
However, turn the fill type (3) and color model (5) buttons into flat buttons as other suggested and that would be perfect.
The trouble is with having the buttons with no 'relief' is that it is not immediately obvious what they are (i.e. from a first look, how do I distinguish them from the icons in the bottom left?)
However I totally see your points that having the multiple borders provides too much visual distraction, in fact I agree with you on some level :)
Ideally, I would like to have some like in the image http://bit.ly/gn2q7z , a 'ToggleButtonGroup', alas GTK doesn't have this widget yet, however that is not to say it would be impossible to create :)
I think for the moment then, I shall remove the relief from the buttons, as the collective opinion is currently that, however hopefully in the future this 'ToggleButtonGroup' can become a reality.
b) sliders vs spinboxes I'm not sure about removing the sliders for opacity and blur (the extension dialogs recently got a new widget to alternatively display sliders in addition to spinboxes). Many users seem to appreciate sliders if values don't need to be set to precise values but freely adjusted to achieve a visually pleasing result (technical vs artistic drawing?).
A huge "no" to spinboxes for blur and opacity. They are simply unusable for tablet users. I was going to bring this up anyway, so here goes: several applications, one after another, recently switched to a new type of slider that combines a slider, a label and a spinbox. Among them are GIMP, darktable and Kdenlive. Here is a short demo of the GIMP's one (that triggered others) I did last year: http://vimeo.com/16616760 In fact I'd love our tools options toolbar to use this kind of widget, but I can surely see how it could be great for things like opacity in Fill'n'Stroke dialog as well as well.
I don't have a tablet, I always use a mouse and don't like spinboxes either for Opacity and Blur. My aim are artistic drawings, maybe that's why I prefer them, the visual feedback feels way more natural using sliders.
Okay then I guess we prefer sliders :) On the note of that custom widget GIMP is using, I think that is quite interesting, reminds me (in a good way) of the volume widget iTunes has on the iPad. Whilst I think the ideas behind it are great, I don't think it is a polished as it could be, but definitely something to think about in the future.
One last detail: in the blur slider you put 'px' as units, but I'm not quite sure if those units are given in pixels or % of the size of the blurred object...
Good point. % is more appropriate than px (it is relative to the size of the blurred object). Personally I don't like the current system, as I'm used to thinking in absolute units, but the idea is that objects blurred with the same "percentage" of blur more or less look equally blurry. I think it is currently defined as a percentage of the sum of the width and height of the bounding box or something like that.
I was not entirely sure about this so thanks for bringing it to my attention. I shall change 'px' to '%'.
c) window decoration Getting rid of the standard GTK Window Bar and replacing it with a custom one: wouldn't this either have to be done for all dockable dialogs (once all or most of them have been made dockable, a feature repeatedly requested by Inkscape users), instead of creating a single exception how a floating dialog (which is docked with default settings) looks? Also, does a custom solution work well with different window managers (and on other platforms, e.g. those which don't use the X11 backend of GTK+)?
IIRC, all the dialogs are subclassed from a special dialog object that does all the floating dockable dialog stuff, so changing the code would mean all the dialog would change.
I think because this is would be a slightly larger task, especially testing on other platforms, this could wait until later, with just the improvements to the content of the Fill and Stroke Dialog happening now.
d) minimal dialog width Unrelated (since it was not mentioned in the redesign proposal) question (but possibly with some relevance when refactoring dialogs?): What does or should determine the overall minimal (or default) width of the dialog? At the moment the length of the (translated) strings of the labels will considerably affect the minimal or default width, e.g.
- the labels of the notebook tabs at the top as seen in this screenshot [1] from the inkscape-devel archives [2] (has improved since)
- the labels of the various options in the 'Stroke style' tab Test yourself with e.g. 'German' as UI language: the labels in the 'Stroke style' tab will extend the overall minimal width of the dialog unproportionally IMHO.
- names of custom patterns or markers seen e.g. with SVG files created by third-party applications [1]
Could this be handled differently in how the dialog is coded, or - with regard to the translations - is it completely up to the translators?
Since this does not affect me, I am maybe not the best person to ask about it, however my initial reaction would be to make sure labels are able to be ellipsized, so that they can be shrunk down, and also check the translations are optimal in terms of understanding and size (which I am sure most already are :] )
Thanks for your comments everyone, I shall now create a final draft, based on the stuff above, and then hopefully I will start work on it (however exams are coming up so it may be a while, and I am also trying to get the new OCAL Dialog done XD )
PS: Anyone who hasn't commented yet, please do, there is no deadline as such :)
Cheers,
2011/4/8 Andrew <rugby471@...400...>:
The trouble is with having the buttons with no 'relief' is that it is not immediately obvious what they are (i.e. from a first look, how do I distinguish them from the icons in the bottom left?)
Those buttons are similar to the mode selection in toolbars (e.g. in the tweak tool), so if there is a new widget for this, the toolbar could also benefit.
Ideally, I would like to have some like in the image http://bit.ly/gn2q7z , a 'ToggleButtonGroup', alas GTK doesn't have this widget yet, however that is not to say it would be impossible to create :)
This looks very nice, and the widget part would be simple to do, but I'm not sure how to draw this decoration.
Okay then I guess we prefer sliders :) On the note of that custom widget GIMP is using, I think that is quite interesting, reminds me (in a good way) of the volume widget iTunes has on the iPad. Whilst I think the ideas behind it are great, I don't think it is a polished as it could be, but definitely something to think about in the future.
This "super slider" is very good and we should use it. It's also an opportunity to introduce another important change: some of the sliders should have a logarithmic scale. When blurring, precision is not important when adding a large blur, but essential when adding a small blur. It allows us to cover a larger range of values while keeping the slider useful, which is of particular importance in filters.
Regards, Krzysztof
On Fri, Apr 8, 2011 at 2:07 PM, Andrew wrote:
Please see the two mockups here http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_...
A huge "no" to spinboxes for blur and opacity. They are simply unusable for tablet users. I was going to bring this up anyway, so here goes: several applications, one after another, recently switched to a new type of slider that combines a slider, a label and a spinbox. Among them are GIMP, darktable and Kdenlive. Here is a short demo of the GIMP's one (that triggered others) I did last year:
In fact I'd love our tools options toolbar to use this kind of widget, but I can surely see how it could be great for things like opacity in Fill'n'Stroke dialog as well as well.
Alexandre Prokoudine http://libregraphicsworld.org
2011/4/8 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
A huge "no" to spinboxes for blur and opacity. They are simply unusable for tablet users.
I don't have a tablet, I always use a mouse and don't like spinboxes either for Opacity and Blur. My aim are artistic drawings, maybe that's why I prefer them, the visual feedback feels way more natural using sliders.
Andrew <rugby471@...360...> writes:
Hi again :)
Okay so after previous feedback, that the comboboxes for the fill type and fill rule were not optimal (i.e. it is quicker to click a button than select something from a combobox), I have ammended the mockups, adding back in the buttons.
I also corrected some padding in places, where I seem to have gone a bit mad with it :)
My biggest problem with the current design was that it took too much horizontal space. When using Inkscape on Ubuntu, at least, you get mad spacing and padding everywhere and there's scant little space left for the actual canvas. In that respect, your new desing show little improvement. I'd favor any design that made this dialog less wide.
There's a lot of useless padding in your design, and the bottleneck seems to be the self-intersect button. Move this away from the fill type button row and you could make the dialog narrower. Perhaps it could be moved between the out of gamut warning label and the hex code? Not an ideal place, logically, but it would help with the width issue.
Hi,
My biggest problem with the current design was that it took too much horizontal space. When using Inkscape on Ubuntu, at least, you get mad spacing and padding everywhere and there's scant little space left for the actual canvas. In that respect, your new desing show little improvement. I'd favor any design that made this dialog less wide.
I agree with this, the canvas should have the most screen space, not the chrome.
There's a lot of useless padding in your design,
..I wouldn't agree with this, all the padding is in there for a reason, so elements can easily be distinguished etc.
and the bottleneck seems to be the self-intersect button. Move this away from the fill type button row and you could make the dialog narrower. Perhaps it could be moved between the out of gamut warning label and the hex code? Not an ideal place, logically, but it would help with the width issue.
I should point out that these are only mockups, so the dialog may become narrower when it is actually implemented.
Regarding your suggestion, I don't think this would make any difference. It would just mean the width of the dialog would shrink to the width of the bottom row (with the new intersect buttons in). However that row would now be quite wide, so as well as not really shrinking, the buttons are now in an illogical place.
On 4/9/11, Michael Grosberg wrote:
There's a lot of useless padding in your design, and the bottleneck seems to be the self-intersect button.
Tell me, how often do you open "Stroke Style" tab? :)
Alexandre Prokoudine http://libregraphicsworld.org
On 2011-04-09 17:44, Alexandre Prokoudine wrote:
On 4/9/11, Michael Grosberg wrote:
There's a lot of useless padding in your design, and the bottleneck seems to be the self-intersect button.
Tell me, how often do you open "Stroke Style" tab? :)
Not sure about others, but I certainly open it all the time. I could imagine a layout where it would be separate from fill and stroke, but I think that might be a bit beyond what's currently on the table.
On 4/9/11, Jasper van de Gronde wrote:
There's a lot of useless padding in your design, and the bottleneck seems to be the self-intersect button.
Tell me, how often do you open "Stroke Style" tab? :)
Not sure about others, but I certainly open it all the time. I could imagine a layout where it would be separate from fill and stroke, but I think that might be a bit beyond what's currently on the table.
I was merely referring to the fact that it's the "Stroke Style" tab that makes the dialog so wide due to combination of labels and long-ish comboboxes in a single row. The whole dialog adapts it width to the width of the widest tab's content.
We could actually ditch comboboxes for selecting arrowheads and introduce a widget similar to GIMP's one for various resources like brushes, where a button opens a grid/table selector. If we are going to ever make vector brushes a no-brainer to use, we'll need such widget anyway.
Likewise we could steal dash pattern editor from GIMP (open Edit > Stroke selection, expand "Line style", and you'll see it).
Alexandre Prokoudine http://libregraphicsworld.org
On 9/4/11 22:22, Alexandre Prokoudine wrote:
On 4/9/11, Jasper van de Gronde wrote:
There's a lot of useless padding in your design, and the bottleneck seems to be the self-intersect button.
Tell me, how often do you open "Stroke Style" tab? :)
Not sure about others, but I certainly open it all the time. I could imagine a layout where it would be separate from fill and stroke, but I think that might be a bit beyond what's currently on the table.
I was merely referring to the fact that it's the "Stroke Style" tab that makes the dialog so wide due to combination of labels and long-ish comboboxes in a single row. The whole dialog adapts it width to the width of the widest tab's content.
For a demonstration, download this file (from an unrelated report in the bug tracker): https://bugs.launchpad.net/inkscape/+bug/596842/+attachment/1432106/+files/SequenceFlowDefault.svg open in Inkscape and check the width of the 'Fill & Stroke' dialog...
This is an example for the strings used in the popup lists/comboboxes for the markers (sample file was created by a third-party application), the same can happen with custom patterns, and does happen with different translations which may use longer strings for the labels of the options or notebook tabs.
~suv
On Sat, Apr 9, 2011 at 1:22 PM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
On 4/9/11, Jasper van de Gronde wrote:
There's a lot of useless padding in your design, and the bottleneck
seems
to be the self-intersect button.
Tell me, how often do you open "Stroke Style" tab? :)
Not sure about others, but I certainly open it all the time. I could imagine a layout where it would be separate from fill and stroke, but I think that might be a bit beyond what's currently on the table.
I was merely referring to the fact that it's the "Stroke Style" tab that makes the dialog so wide due to combination of labels and long-ish comboboxes in a single row. The whole dialog adapts it width to the width of the widest tab's content.
I never knew this tab was the offender... good to be aware of. Shows how often *I* open it. ;)
We could actually ditch comboboxes for selecting arrowheads and introduce a widget similar to GIMP's one for various resources like brushes, where a button opens a grid/table selector. If we are going to ever make vector brushes a no-brainer to use, we'll need such widget anyway.
Agreed.
Likewise we could steal dash pattern editor from GIMP (open Edit > Stroke selection, expand "Line style", and you'll see it).
I've never seen that before and I think it's fantastic.
Cheers, Josh
Alexandre Prokoudine <alexandre.prokoudine@...360...> writes:
On 4/9/11, Jasper van de Gronde wrote:
There's a lot of useless padding in your design, and the bottleneck seems to be the self-intersect button.
Tell me, how often do you open "Stroke Style" tab? :)
Not sure about others, but I certainly open it all the time. I could imagine a layout where it would be separate from fill and stroke, but I think that might be a bit beyond what's currently on the table.
I was merely referring to the fact that it's the "Stroke Style" tab that makes the dialog so wide due to combination of labels and long-ish comboboxes in a single row. The whole dialog adapts it width to the width of the widest tab's content.
If that is the case, then it is not apparent to a user. here's a screenshot of the dialog: http://www.booki.cc/inkscape-1/_v/1.0/static/Inkscape-StrokeStyle-strokestyl... There are very long drop-down boxes for markers which coulod be shrunk easily, and plenty of padding to the right of the labels. What specifically in the stroke editor inhibits shrinking? Perhaps it's something that's only apparent in other languages such as German? I know the common wisdom is to keep 33% spare space for German in strings.
Have you thought about switching the position of RGB and HSL tabs? Usability-wise RGB color picker is much harder to use than HSL picker or color wheel, so I'm not sure why it's the default one.
On Fri, Apr 8, 2011 at 12:07 PM, Andrew <rugby471@...400...> wrote:
Hi again :)
Okay so after previous feedback, that the comboboxes for the fill type and fill rule were not optimal (i.e. it is quicker to click a button than select something from a combobox), I have ammended the mockups, adding back in the buttons.
I also corrected some padding in places, where I seem to have gone a bit mad with it :)
Please see the two mockups here http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_...
Again I really do welcome feedback, positive or negative :)
-- Andrew
On 4/12/11, Jarek Foksa wrote:
Have you thought about switching the position of RGB and HSL tabs? Usability-wise RGB color picker is much harder to use than HSL picker or color wheel, so I'm not sure why it's the default one.
In my not so humble opinion the whole approach needs rethinking. Right now the only way to stick to a custom color space is to link to profile in the document and always use the CMS tab. Switching to any other color model without abandoning selected color space is not possible. This is rather silly.
Alexandre Prokoudine http://libregraphicsworld.org
participants (9)
-
Alexandre Prokoudine -
Andrew -
Jarek Foksa -
Jasper van de Gronde -
Josh Andler -
Krzysztof Kosiński -
Michael Grosberg -
Pajarico -
~suv