object style minibar
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
Basically fill and stroke get their own square areas, and stroke is a thick outline rather than a solid box. That way it's immediately clear which is which.
The boxes are divided diagonally -- the upper right side of each box is the paint with full opacity, and the lower left side is the paint with the actual opacity, over a checkerboard.
The absence of a fill or stroke would be represented by the traditional red-on-white slash, and probably unset by a question mark or something (to match the fill and stroke dialog). I think I'd also like to see the traditional red-and-white slash in the fill and stroke dialog as well...
There's a mock-up attached.
Comments/critiques?
-mental
I like that idea!
actually I was thinking about filing an RFE about this before and drew some svgs like you did, but forgot about it again... This is basically what is done in Adobe software and I believe that many people are used to it.
Thanx for bringing this up!
David
On Sat, 2006-01-07 at 14:02 -0500, MenTaLguY wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
Basically fill and stroke get their own square areas, and stroke is a thick outline rather than a solid box. That way it's immediately clear which is which.
The boxes are divided diagonally -- the upper right side of each box is the paint with full opacity, and the lower left side is the paint with the actual opacity, over a checkerboard.
The absence of a fill or stroke would be represented by the traditional red-on-white slash, and probably unset by a question mark or something (to match the fill and stroke dialog). I think I'd also like to see the traditional red-and-white slash in the fill and stroke dialog as well...
There's a mock-up attached.
Comments/critiques?
-mental
On Jan 7, 2006, at 11:02 AM, MenTaLguY wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
I *think* it's a pretty good tweak that gets some nice functionality squeezed into there. One minor shift might be to inset the fill square slightly so it looks more of the size to fit into the 'stroke' size. To have them logically appear as both parts of the same thing, the size of the 'fill' square should aline to the middle of the 'stroke' square. However, I think that doing something that precise makes it lose esthetically. A slight reduction in the 'fill' square, on the other hand, still seems to make things esthetically pleasing while at the same time conveying extra information more intuitively.
But... the main point, I think, is that it really is a large usability improvement, even if it seems to not be a huge difference.
On Sat, Jan 07, 2006 at 02:45:30PM -0800, Jon A. Cruz wrote:
On Jan 7, 2006, at 11:02 AM, MenTaLguY wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
I *think* it's a pretty good tweak that gets some nice functionality squeezed into there. One minor shift might be to inset the fill square slightly so it looks more of the size to fit into the 'stroke' size. To have them logically appear as both parts of the same thing, the size of the 'fill' square should aline to the middle of the 'stroke' square. However, I think that doing something that precise makes it lose esthetically. A slight reduction in the 'fill' square, on the other hand, still seems to make things esthetically pleasing while at the same time conveying extra information more intuitively.
But... the main point, I think, is that it really is a large usability improvement, even if it seems to not be a huge difference.
Agreed, I was watching a new user playing with Inkscape yesterday, and she kept having to pull up the fill and stroke dialog, make a minor change, close it, look at the drawing, repeat, rinse later... (Finally I couldn't stand it any longer and just grabbed the mouse *grin*) So yeah, more toolbar action for fill and stroke stuff would have profound benefits.
Bryce
On Sat, 2006-01-07 at 15:03 -0800, Bryce Harrington wrote:
Agreed, I was watching a new user playing with Inkscape yesterday, and she kept having to pull up the fill and stroke dialog, make a minor change, close it, look at the drawing, repeat, rinse later... (Finally I couldn't stand it any longer and just grabbed the mouse *grin*) So yeah, more toolbar action for fill and stroke stuff would have profound benefits.
There's really no new functionality in my proposal beyond what bulia's already done; it's just a visual tweak.
-mental
Oh, just one suggestion: The opacity slider should be like the volume slider in Totem or the Volume applet!
David
Hi,
I like your use of square boxes. It is a nice improvement. But I see a few small problems. The visual clue for gradients is a bit difficult to make out, especially for the stroke. Perhaps adding a small 'R' or 'L' in the center may make it more obvious. What do you do for a pattern? A small 'P'? Show a pattern icon? And what about if multiple objects are selected with different fill attributes?
I didn't know that a red-and-white slash were traditional for unset. I was going to suggest adding a slash to the current minibar to indicate that no object is selected so that the minibar could also be used to show the style that would be used for drawing a new object. Perhaps there is another clever way of showing this.
Tav
On Sat, 2006-01-07 at 14:02 -0500, MenTaLguY wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
Basically fill and stroke get their own square areas, and stroke is a thick outline rather than a solid box. That way it's immediately clear which is which.
The boxes are divided diagonally -- the upper right side of each box is the paint with full opacity, and the lower left side is the paint with the actual opacity, over a checkerboard.
The absence of a fill or stroke would be represented by the traditional red-on-white slash, and probably unset by a question mark or something (to match the fill and stroke dialog). I think I'd also like to see the traditional red-and-white slash in the fill and stroke dialog as well...
There's a mock-up attached.
Comments/critiques?
-mental
On Sun, 2006-01-08 at 00:01 +0100, Tavmjong Bah wrote:
I didn't know that a red-and-white slash were traditional for unset.
Well, not for what Inkscape normally means by "unset" -- the red slash means explicitly set to nothing, as opposed to not set to anything in particular.
The latter, "unset", should probably be a question mark or something similar.
-mental
On 1/7/06, MenTaLguY <mental@...3...> wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
I suspect many people will like yours because it's more traditional. But I think I prefer mine, at least for the statusbar. So if I will be unable to convince everyone in the benefits of the current one, I will have to play Scislac and ask for an option.
My reasons:
- Squares have much smaller area than my horizontal-stretched swatches. Even for flat colors, this matters: I can't get the good idea of a color from a tiny swatch. For gradients etc, it's even more important. You can't fit a visually unambiguous gradient display into such a small space. Note that in practice, not all gradients are black-to-white; a lot of them are much subtler, e.g. from dark green to somewhat lighter green. Making out such a gradient in a tiny swatch is outright impossible. That is why I chose to simply say "L Gradient" in such cases, instead of trying to "represent" the gradient in the swatch - not because I was lazy but because it's actually more informative and _faster_ that way. Just a quick glance, and I know what I want to know.
- The square hole for stroke makes it even more visually noisy and more difficult to decypher the display.
- The opacity slider _always_ showing checkerboard is also noisy, plus there's no way to type/look up an opacity value as number. Again, this will result in a lot of frustration along the lines of "is this really 1.0 or maybe 0.99?"
- The diagonal division and the diagonal red line add further visual complexity.
- In your version, fill/stroke are spatially separated horizontally. On a horizontal statusbar filled with other stuff, it makes it harder to quickly distinguish them. The vertical separation as in my variant is faster to get at a glance and more intuitive (fill is closer to the drawing, stroke is more peripheral).
In short, your variant cramps more information, but it makes it much more difficult to get it, and unless you increase the size of the widget significantly compared to the size it currently has, it will be outright frustrating. My version needs just a quick glance, and after some practice, even less than that - by now I can get all I need from it by "peripheral vision", without even looking directly at it. It has become part of my subconscious :)
With your proposal, it requires a good long direct look, and often a mouseover "to make sure it's really what I think it is". With such a basic and always-on indicator, every millisecond counts!
Note that I was thinking about this indicator for years. I started from something very similar to your mockup, but could never force myself to do actual coding for it. It just didn't feel enticing enough. I put it into different parts of the interface, varied size and design, but no go. I just didn't want it to be like that, though I always felt the most urgent and dire need for something to get current style from. Finally I was fed up and said to myself, come on, let's think out of the box. Let's forget what other programs use. What do I REALLY need from it? Most importantly, I want to see the colors, and I want them BIG. Small swatches are useless. But I can't have them big in both dimensions. Will stretching them in one dimension do? That's where I ran into the old (Lauris') color preview widget, crisp and small and simple. I just cleaned it from some cruft such as margins and borders, and fell in love with it immediately. In a few hours, the style indicator was working. By now I consider the design of this indicator a very important advantage of Inkscape's UI.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Oh, forgot a couple things:
- how do you distinguish between None and Unset? It's an important distinction in practice.
- how do you display "nothing selected"?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
Oh, forgot a couple things:
- how do you distinguish between None and Unset? It's an important
distinction in practice.
- how do you display "nothing selected"?
by default in Adobe software, none and unset function in the same way. this works well for the user - the slash (or questionmarks in Illustrator) prompts the user to choose a setting if required, but at the same time makes it clear that nothing is selected. I as a user am happy with none and unset being displayed in the same way.
mC~
On 1/12/06, miriam clinton (iriXx) <iriXx@...569...> wrote:
by default in Adobe software, none and unset function in the same way.
Because there they are the same. But in SVG they are different, and this difference is meaningful.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Thu, 12 Jan 2006, bulia byak wrote:
Date: Thu, 12 Jan 2006 16:53:48 -0400 From: bulia byak <buliabyak@...400...> To: iriXx@...569... Cc: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] object style minibar
On 1/12/06, miriam clinton (iriXx) <iriXx@...569...> wrote:
by default in Adobe software, none and unset function in the same way.
Because there they are the same. But in SVG they are different, and this difference is meaningful.
For what it is worth my old favourite Jasc Webdraw used "None" and "Inherit", which does make sense in terms of styles.
- Alan H.
On Jan 7, 2006, at 4:39 PM, bulia byak wrote:
On 1/7/06, MenTaLguY <mental@...3...> wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
I suspect many people will like yours because it's more traditional. But I think I prefer mine, at least for the statusbar. So if I will be unable to convince everyone in the benefits of the current one, I will have to play Scislac and ask for an option.
Especially for this usage, I definitely have to back Bulia on an option here.
This might also be a good area to look at what is being represented in a logical (versus physical) fashion and try to encapsulate it that way. There's probably an opportunity to begin looking at the functional structure in a new way. A little more on MVC design of the code might be handy, at least as far as the option goes. And we might get something where the size of the area and the complexity of the UI drive the options for what is displayed. Bulia listing out *why* it was he prefers the other layout is a good start for that how to be looking at things.
- Squares have much smaller area than my horizontal-stretched
swatches. Even for flat colors, this matters: I can't get the good idea of a color from a tiny swatch.
I don't actually think your area is way bigger,as for the fill at least. I also don't agree with the idea brought up by Jon to make the fill and the stroke look a little like they fitted into one another. That means unnecessarily losing space.
For gradients etc, it's even more important. You can't fit a visually unambiguous gradient display into such a small space. Note that in practice, not all gradients are black-to-white; a lot of them are much subtler, e.g. from dark green to somewhat lighter green. Making out such a gradient in a tiny swatch is outright impossible. That is why I chose to simply say "L Gradient" in such cases, instead of trying to "represent" the gradient in the swatch - not because I was lazy but because it's actually more informative and _faster_ that way. Just a quick glance, and I know what I want to know.
I do agree: Gradients are hard to see, and there's not need really to display their direction. Still I don't think it's all that important to actually see what the fill and the stroke look like. You can do that on canvas. It's more important that you can easily change them. As for Gradients it would be great to have a tooltip to tell you the name of the used gradient.
- The square hole for stroke makes it even more visually noisy and
more difficult to decypher the display.
Actually I don't agree. I've been using CVS for a while (then switched back to Debian experimental because I couldn't get my font dialogue working) and I found it quite hard to click on the right bar with your way of displaying fill and stroke. Squares are easier to click at! Also I do think that the hole makes it easier to decipher since it visually signals, what we are talking about (stroke) and the user doesn't have to know by location or by reading (you put an F and an S in front of the boxes IIRC).
- The opacity slider _always_ showing checkerboard is also noisy, plus
there's no way to type/look up an opacity value as number. Again, this will result in a lot of frustration along the lines of "is this really 1.0 or maybe 0.99?"
Agreed! So I'd just display a click-able number. When you click you get a slider as for the volume in totem (suggested that in some mail yesterday already).
- The diagonal division and the diagonal red line add further visual
complexity.
It distinctively means "none" to me. It's just what Adobe does. What's the approach of Xara? Checkboards are hard to make out... I like the red dash, but obviously I'm used to it.
- In your version, fill/stroke are spatially separated horizontally.
On a horizontal statusbar filled with other stuff, it makes it harder to quickly distinguish them. The vertical separation as in my variant is faster to get at a glance and more intuitive (fill is closer to the drawing, stroke is more peripheral).
I disagree on this. I think it actually makes it _easier_ because you are trained to distinguish elements horizontally in a statusbar. Als, as said above: it's really important that you can hit them more easily with your mouse. I can't follow your reason about fill being closer to the drawing and stroke more peripheral... it does sound logical, but not intuitive. To me the click-ability of the squares is a very big advantage since I see it as the main reason for this widget to change the fill and stroke by clicking there. This great advantage is stronger than those disadvantages you brought up and which I agree with.
In short, your variant cramps more information, but it makes it much more difficult to get it, and unless you increase the size of the widget significantly compared to the size it currently has, it will be outright frustrating. My version needs just a quick glance, and after some practice, even less than that - by now I can get all I need from it by "peripheral vision", without even looking directly at it. It has become part of my subconscious :)
Well, here is where we differ... I don't think the widget is so much about information but more about interaction.
That's my 0.02 € on this.
David
On Sun, 2006-01-08 at 13:53 +0100, David Christian Berg wrote:
- Squares have much smaller area than my horizontal-stretched
swatches. Even for flat colors, this matters: I can't get the good idea of a color from a tiny swatch.
I don't actually think your area is way bigger,as for the fill at least.
Well, it depends on what you mean by "area". The square may actually be larger in the width*height sense, but the longer shape can have a larger "visual footprint".
For gradients etc, it's even more important. You can't fit a visually unambiguous gradient display into such a small space.
That is a problem I encountered while doing the mockup. Even an unambiguous black-to-white gradient is hard to do without some subtle tricks.
I do agree: Gradients are hard to see, and there's not need really to display their direction.
Once you throw gradient direction in, it's just totally impossible to do in a small space. I wasn't intending to try.
- The square hole for stroke makes it even more visually noisy and
more difficult to decypher the display.
Actually I don't agree. I've been using CVS for a while (then switched back to Debian experimental because I couldn't get my font dialogue working) and I found it quite hard to click on the right bar with your way of displaying fill and stroke. Squares are easier to click at!
That's actually been the main thing driving my experimentation here -- I'm finding the narrow strips to be an extremely difficult mouse target. Out of curiousity, bulia, what resolution do you normally run at?
Also I do think that the hole makes it easier to decipher since it visually signals, what we are talking about (stroke) and the user doesn't have to know by location or by reading (you put an F and an S in front of the boxes IIRC).
I do think it's better when you don't have to use text to explain what something is -- particularly in such a compact area.
But the hole does present problems -- you'll notice I didn't include any examples with stroked radial gradients. I haven't figured out how to make that look right.
I may fall back to using text to indicate gradients, though it's obviously harder to do in a square space like that. Rather than a tooltip showing only the gradient name, though, I think it might be better to include a larger and visually unambiguous representation along with it. It'd require a custom tooltip window, but I think it'd be worth it.
- The opacity slider _always_ showing checkerboard is also noisy, plus
there's no way to type/look up an opacity value as number. Again, this will result in a lot of frustration along the lines of "is this really 1.0 or maybe 0.99?"
Agreed! So I'd just display a click-able number. When you click you get a slider as for the volume in totem (suggested that in some mail yesterday already).
Hmm, maybe. I'm not at all happy with my version of the opacity slider.
- The diagonal division and the diagonal red line add further visual
complexity.
It distinctively means "none" to me. It's just what Adobe does. What's the approach of Xara? Checkboards are hard to make out... I like the red dash, but obviously I'm used to it.
I would've punted on checkerboards, except I think bulia got away with it in the existing widget just fine. So I don't think they're a problem in themselves.
As for the slash, it's not just Adobe, Macromedia's done it forever too. I'd say it's a pretty well-established convention for graphics applications. Admittedly, I don't know about Xara...
As noted elsewhere, I think we should represent "unset" using a question mark, just as we do in Fill and Stroke.
As bulia noted, the conflict between the slash and the diagonal divisions is very visually ugly. Since the diagonal division is not normally apparent (and definitely wouldn't be for "none" or "unset"), the slash and division should at least be going the same direction.
- In your version, fill/stroke are spatially separated horizontally.
On a horizontal statusbar filled with other stuff, it makes it harder to quickly distinguish them.
I don't find this to be the case, myself, especially if they are visually distinct from each other and stand out from the other widgets.
The vertical separation as in my variant is faster to get at a glance and more intuitive (fill is closer to the drawing, stroke is more peripheral).
I'm with David on this one. That's logical, but I don't think someone is ever going to pick up on that unless someone explained it to them.
In short, your variant cramps more information, but it makes it much more difficult to get it, and unless you increase the size of the widget significantly compared to the size it currently has, it will be outright frustrating.
I would almost advocate increasing the size of the existing widget. Given its role as a click target, it's frustratingly small, especially with a tablet, where it's hard to "right click" the stylus without moving the tip a few pixels.
My version needs just a quick glance, and after some practice, even less than that - by now I can get all I need from it by "peripheral vision", without even looking directly at it. It has become part of my subconscious :)
In my experience, that becomes true of anything once you get accustomed to it. Bulia, are you sure this part isn't a "because I'm used to it" thing? :)
Anyway, the main reason I'm doing this is because I'm getting really frustrated trying to use the current widget, and I'm trying to prove to myself that there isn't a better way to do it. I may or may not succeed. :)
I don't plan on implementing anything right now, partly because my ideas aren't fully baked, and partly because I have bigger priorities (keybindings + layer dialog, mainly).
-mental
On 1/8/06, MenTaLguY <mental@...3...> wrote:
Well, it depends on what you mean by "area". The square may actually be larger in the width*height sense, but the longer shape can have a larger "visual footprint".
And easier to click, too. With the stretched swatch, you need to be precise only in one dimension. With a square, you need to be precise (though a bit less precise) in both dimensions.
That's actually been the main thing driving my experimentation here -- I'm finding the narrow strips to be an extremely difficult mouse target. Out of curiousity, bulia, what resolution do you normally run at?
1280x1024, with pen instead of mouse. No problem with aiming at all. However, I would not object to increasing the total height of the statusbar (and maybe running the statusbar tips in two lines, wrapped), with corresponding increase in height of these swatches.
I do think it's better when you don't have to use text to explain what something is -- particularly in such a compact area.
No. This is an example of a very common fallacy. People are taught that "icons are better than words" as if this is the whole truth, even though its applicability is quite limited. Icons are better only when they are few, simple, and obvious, but in many cases you can't achieve some or all of these objectives. Failing to recognize that and insisting on presenting everything "visually" results in UIs overloaded with too complex, cryptic and confusing icons where simple text labels would work much better. You should remember that letters of the alphabet are _images too_, and very special images at that: they have developed for centuries to be immediately and faultlessly recognizable in very small sizes. Few icons can compete with letters for the speed and accuracy of perception.
So, when I see "None" in my indicator, I do not read it; I perceive it as an image, as a whole, and it is _at least_ as fast as the perception of a red diagonal on white. However, compared with the diagonal, "None" has a few advantages: it's more informative for newbies, larger, can never be confused for some exotic gradient, and in general, much more strongly asserts "no fill/stroke" as a separate property that is unlike all other kinds of fill/stroke. Perhaps the most common type of query that I use the indicator for is "whether this object has fill/stroke or not", and from this viewpoint, the difference between "None" and all other fill types (especially color, of course) in my indicator is much stronger and therefore takes less milliseconds to read than the difference between the red diagonal and all other types of stuff that your square swatches can display. The same applies to all other fill/stroke types that I use text labels for, as well as the F/S labels.
I may fall back to using text to indicate gradients, though it's obviously harder to do in a square space like that. Rather than a tooltip showing only the gradient name, though, I think it might be better to include a larger and visually unambiguous representation along with it. It'd require a custom tooltip window, but I think it'd be worth it.
I disagree here as well. I think a large tooltip with an gradient rendition will be very clumsy and awkward.
By the way, my design in principle can show gradients, because there's enough horizontal space for that, and we even have a nice horizontally-stretched widget for that (now used in the gradient tool's toolbar menu). That would be logical, consistent, and much easier to read than in a square swatch. However, I want to display textual labels in that case as well, for the reasons I quoted (such as dark green/light green gradient being hard to tell from flat green color), and the layout of the widget with both gradient display and a label needs some thinking. But I think I'll do it one day.
I would've punted on checkerboards, except I think bulia got away with it in the existing widget just fine. So I don't think they're a problem in themselves.
In existing swatches they are used only for fill/stroke opacities, which are quite rarely used (most of the time, master opacity is much more convenient). In your design, master opacity slider shows checkers _always_ (by the way how will you make it draggable? it looks like it will require a custom widget).
As for the slash, it's not just Adobe, Macromedia's done it forever too. I'd say it's a pretty well-established convention for graphics applications. Admittedly, I don't know about Xara...
Xara has no red slash, but uses just clear checkers in the indicator (i.e. there's no difference between no fill and fully transparent fill). However, for stroke, there's another indicator that shows stroke width, and there it displays "None" for no stroke. That's where I look when I need to find out if an object has a stroke or not.
In short, your variant cramps more information, but it makes it much more difficult to get it, and unless you increase the size of the widget significantly compared to the size it currently has, it will be outright frustrating.
I would almost advocate increasing the size of the existing widget.
And I would not object, see above.
In my experience, that becomes true of anything once you get accustomed to it. Bulia, are you sure this part isn't a "because I'm used to it" thing? :)
Maybe. But I also have other arguments in favor, as you can see :)
I don't plan on implementing anything right now, partly because my ideas aren't fully baked, and partly because I have bigger priorities (keybindings + layer dialog, mainly).
I don't want to sound like I'm trying to talk you off this, but I agree that keybindings and especially the layer dialog are more important, from the viewpoint of Inkscape's general progress.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 1/8/06, MenTaLguY <mental@...3...> wrote:
As for the slash, it's not just Adobe, Macromedia's done it forever too. I'd say it's a pretty well-established convention for graphics applications. Admittedly, I don't know about Xara...
Xara has no red slash, but uses just clear checkers in the indicator (i.e. there's no difference between no fill and fully transparent fill). However, for stroke, there's another indicator that shows stroke width, and there it displays "None" for no stroke. That's where I look when I need to find out if an object has a stroke or not.
This raises a problem: what is 'clear' and what is grey, or the chosen background color of your UI?
I have this problem when using Macromedia Dreamweaver - when selecting text color, the 'default color' is the same grey of my UI as if I had selected #CCCCCC. Big problem if I actually have selected grey, or clicked on the edge of my screen by accident. I'd suggest a variant on the Illustrator questionmarks perhaps?
We should definately avoid a direct copy of the Adobe/Macromedia red slash - both companies have a history of suing each other for these patented UIs. They get away with it by paying each other large sums of money and by one company buying up bits of the other, the way patenting works.
I'd need something to show me the difference between having selected the grey of my UI by mistake, or requiring a grey color, and 'none / unset'. Again, we can't copy the questionmarks that Illustrator uses, but they are useful, particularly when working with multiple selections - Illustrator uses questionmarks for 'unable to display', as opposed to the red slash for 'none set'. I would have no objections to using questionmarks for both options, but I'm curious to investigate how other F/OSS graphics software displays 'none set'. Are we lucky enough to get away with the red slash? Is it universal enough to be freely usable, or is it likely to be yet another tiny bit of patented UI that everyone happens to consider universal simply because Adobe/Macromedia monopolise the field of professional design software?
mC~
On 1/12/06, miriam clinton (iriXx) <iriXx@...569...> wrote:
This raises a problem: what is 'clear' and what is grey, or the chosen background color of your UI?
And this is another reason for using text labels for anything that's not color. Now, I know for sure that if I don't see a text label, it is color, even if it's gray.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
If we are going to make the widget larger I think it should be moved to the toolbar or a seperate bar the same one as a layer widget.
MenTaLguY wrote:
On Sun, 2006-01-08 at 13:53 +0100, David Christian Berg wrote:
- Squares have much smaller area than my horizontal-stretched
swatches. Even for flat colors, this matters: I can't get the good idea of a color from a tiny swatch.
I don't actually think your area is way bigger,as for the fill at least.
Well, it depends on what you mean by "area". The square may actually be larger in the width*height sense, but the longer shape can have a larger "visual footprint".
I have actually found color selection to be one of the more difficult things to work with at present. To start with, it is hard to locate within the UI - I instinctively look to my left or right, or for a dialog at the top to find my color selection, not the bottom of the screen. The other problem is the large footprint of the rectangles, which creates scrolling problems - but it is /very/ nice to be able to see a larger area of color rather than trying to locate a one-pixel selection and /then/ have it displayed (Photoshop/Macromedia/GIMP) or have tiny swatches as per Illustrator. Even Illustrator has to use a popup/pop-out dialog to select Pantone swatches, or the usual color wheel with a larger square for selected previous/new color.
Scrolling through the color selection is at present frustratingly slow, and there seems to be no way to enlarge / flatten the color selection area; even when using Inkscape at full screen, the selection area is the same size. Perhaps this works differently on GTK - at present I'm stuck on my Windows ME and XP boxen (which I like testing on as I'm interested in porting / promoting Free Software to Windows for your everyday user who is a bit nervous as yet of installing GNU/Linux).
One thing I do miss is being able to drag my cursor through shades - again, the one-pixel selection problem, but I'm used to it, and sometimes wish to go ever so slightly more towards cyan / magenta / alpha / whatever...
A seperate popup dialog would be nice imho, with selected background and foreground color displayed somewhere on the main screen as a reminder? (perhaps top of screen, as already exists with the gradient selection; or alternatively, a 'selected foreground/background' swapper as per the main toolbar on Photoshop).
yeah... I know I'm asking a lot here... but its one of the things i've found more cumbersome... a designer won't know where to look for color selection with the present UI, and may well give up before locating it :(...
The speed of scrolling does need to be addressed too.. even on my machine it is strangely slow (I'm working on a P4 2.6Ghz, 512Mb DDR RAM).
mC~
OK... same as before, a lot of my comments here are either old news since the latest builds, or I'm still exploring the interface.... but that raises an issue of its own; is the color selection process intuitive, or still a little cumbersome?
It took me a while to find the resizing options for the swatch squares... nice to have the option to change them at least! I dont know of any other program that offers this, and it certainly is useful. However, the slow scrolling rate remains problematic, as does the inability to drag and resize the color selection area to be able to see more than three or four rows at a time (at least on WinXP). There is also a problem with the drop-down menu on XP - there's a lot of blank space and then the SVG / Web / etc menu and size selection hangs at the bottom of the screen. The top of the menu doesn't actually indicate what it belongs to - it would be nice to have the default selection showing, to indicate 'here is where you can change the size of your swatches'. I imagine this is an issue between Windows / GTK toolkits again, however, I am able to drag my dialog boxes around in Macromedia - one of the nicer features of Fireworks is that you can drag and drop the UI around the screen and customize it, or have the palettes dockable or floating. Now thats me asking a lot... but at the moment it still is hard for a new user to even locate how to select and change color.
I'm happy with the text 'None' for the moment.. but it would look nicer to have a foreground/background graphic to demonstrate 'none' or 'multiple selections' rather than text. However, 'None' doesnt risk Adobe jumping down our throats with a patent suit ;)... and 'N/A' differentiates from 'None'.
Scrolling between colors... yep, found the color wheel option as well. It took a while, but it is still intuitive for me to click on the foreground selection to access the popup dialog. The only problem here is that one can't click on it /before/ drawing - I usually like to make my selection first before working on an area. When Foreground / Background is set to N/A I'm unable to access the color wheel in my dialog box. I imagine this wouldnt be too hard to implement... it would be very much easier to choose color first rather than a random red from the top of the swatch selection and then draw...
In general... everything I was looking for was there, but it took me a while to find it. That's a problem that designers will find off-putting... unfortunately, with our visually rather than verbally-based approach, designers are accustomed to being able to just pick up a piece of software and play with it, and are more likely to throw a manual out the window than to read it ;)... (hence my being slow to find these features, unless they're very new).
mC~
miriam clinton (iriXx) wrote:
MenTaLguY wrote:
On Sun, 2006-01-08 at 13:53 +0100, David Christian Berg wrote:
- Squares have much smaller area than my horizontal-stretched
swatches. Even for flat colors, this matters: I can't get the good idea of a color from a tiny swatch.
I don't actually think your area is way bigger,as for the fill at least.
Well, it depends on what you mean by "area". The square may actually be larger in the width*height sense, but the longer shape can have a larger "visual footprint".
I have actually found color selection to be one of the more difficult things to work with at present. To start with, it is hard to locate within the UI - I instinctively look to my left or right, or for a dialog at the top to find my color selection, not the bottom of the screen. The other problem is the large footprint of the rectangles, which creates scrolling problems - but it is /very/ nice to be able to see a larger area of color rather than trying to locate a one-pixel selection and /then/ have it displayed (Photoshop/Macromedia/GIMP) or have tiny swatches as per Illustrator. Even Illustrator has to use a popup/pop-out dialog to select Pantone swatches, or the usual color wheel with a larger square for selected previous/new color.
Scrolling through the color selection is at present frustratingly slow, and there seems to be no way to enlarge / flatten the color selection area; even when using Inkscape at full screen, the selection area is the same size. Perhaps this works differently on GTK - at present I'm stuck on my Windows ME and XP boxen (which I like testing on as I'm interested in porting / promoting Free Software to Windows for your everyday user who is a bit nervous as yet of installing GNU/Linux).
One thing I do miss is being able to drag my cursor through shades - again, the one-pixel selection problem, but I'm used to it, and sometimes wish to go ever so slightly more towards cyan / magenta / alpha / whatever...
A seperate popup dialog would be nice imho, with selected background and foreground color displayed somewhere on the main screen as a reminder? (perhaps top of screen, as already exists with the gradient selection; or alternatively, a 'selected foreground/background' swapper as per the main toolbar on Photoshop).
yeah... I know I'm asking a lot here... but its one of the things i've found more cumbersome... a designer won't know where to look for color selection with the present UI, and may well give up before locating it :(...
The speed of scrolling does need to be addressed too.. even on my machine it is strangely slow (I'm working on a P4 2.6Ghz, 512Mb DDR RAM).
mC~
On 1/12/06, miriam clinton (iriXx) wrote:
screen. The other problem is the large footprint of the rectangles, which creates scrolling problems - but it is /very/ nice to be able to see a larger area of color rather than trying to locate a one-pixel selection and /then/ have it displayed (Photoshop/Macromedia/GIMP) or have tiny swatches as per Illustrator.
Let's be honest to Photoshop and GIMP - they both have swatches palette :) Even Inkscape has it :)
Alexandre
David Christian Berg wrote:
- The diagonal division and the diagonal red line add further visual
complexity.
It distinctively means "none" to me. It's just what Adobe does.
Agreed - it seems to be a universal language for both 'none' and 'not yet set / unset' both in Adobe and Macromedia products. Designers are accustomed to ignoring the visual appearance of a red line and seeing instead its meaning: 'nothing is there'.
Yet here we might run into a not-so-little problem; that of patenting within the UI. Adobe and Macromedia have a long history of suing one another (even though I understand one is about to be bought up by the other) for using similiar interfaces. Investigating Xara, PaintShopPro and other alternatives might be useful. I'm unable to remember off the top of my head how GIMP displays 'unset / none' - but avoiding copying Adobe/Macromedia's slash box might be wise.
I like the example - although the completely blank boxes were confusing to begin with, they soon became intuitively understandable. Questionmarks are a possibility (Adobe Illustrator uses a series of questionmarks for 'unset' or when selecting multiple areas with different stroke/fill settings).
Which raises another nightmare... how to show 'unable to display' when selecting multiple areas...
mC~
bulia byak wrote:
On 1/7/06, MenTaLguY <mental@...3...> wrote:
I've been pondering the object style minibar, and come up with a variation on the current idea. It's not a huge difference.
I suspect many people will like yours because it's more traditional. But I think I prefer mine, at least for the statusbar. So if I will be unable to convince everyone in the benefits of the current one, I will have to play Scislac and ask for an option.
And why shouldn't you? It's like us retaining the layer selector as an option after we get the layers dialog, which is how it's planned last I heard. My question is, how "dynamic" can we make the status bar? So that it can expand and contract appropriately with optional items.
And for note, if being vocal about wanting to keep existing functionality as an option will be called "playing ScislaC", it probably won't take too many times before it comes across like "he Munson-ed it" from KingPin. (arg I feel that joke will be lost on everyone)
-Josh
On Sunday 8 January 2006 18:53, Joshua A. Andler wrote:
And for note, if being vocal about wanting to keep existing functionality as an option will be called "playing ScislaC", it probably won't take too many times before it comes across like "he Munson-ed it" from KingPin. (arg I feel that joke will be lost on everyone)
It certainly was on me :-)
participants (12)
-
Alan Horkan -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
David Christian Berg -
Jean-François Lemaire -
Jon A. Cruz -
Joshua A. Andler -
Joshua Blocher -
MenTaLguY -
miriam clinton (iriXx) -
Tavmjong Bah