Comments on: GUI: Colored Buttons - Attributes vs Styles
I like deep GUIs.
What do I mean by that? Here's an example: I like the Apple iphone. In fact,
for the most part, the iphone looks and feels like the kinds of apps I prefer to design. But, maybe that's just my Amiga Computer background leaking out.
By deep GUI, I mean a graphical interface that provides additional
information via visual hints or clues.
For example, in the image below, which button looks more like a delete
action will take place:
The color of the button is not critical to its operation. It's just a
visual aid, much like the syntax coloring you see in a good code editor.
It is what I call a significant visual clue because we as humans
recognize color quite well. It differentiates the button as something
special. If I had just changed the rounding at the corners it would not
be as effective.
IMO, it's silly to ignore this color dimension of our human preceptive
abilities. (If we were cats, then it would be fine.) We should use it - wisely, of course.
Now, assuming that we can change the color of a button, how do we
indicate this in the GUI?
This question is not as trivial as it seems. In R2 VID and in the
default button style of new R3 GUI, you can write:
button "Delete" maroon
That's how I got the button for the image above.
But, some of you strictly-by-the-book GUI experts will recognize that I've
violated an important rule. I've broken the abstraction barrier. In the
line above, I added a visual attribute (maroon) to an abstract concept
(button). It would be like using the B tag in HTML to stress a word. Oh no! It's verboten! Although... a whole lot of people do it... because it's convenient.
You may ask, is that a good practice? My answer would be that it depends
on your application. If you're writing a tiny reblet for some quick project
or to give away to friends on the net, I'd say: no problem. But, if you're
designing a commercial application for an important client, I'd advise for
you to be more disciplined.
More disciplined? What do I mean?
Well, quite simply, you can easily abstract the above into a new style (our GUI subclass) of button.
Which can be defined as easily as:
button-critical: button [
facets: [area-color: maroon]
The advantage is that now all of your critical buttons will be the same
color and you can easily modify all of them in one place, the style
You might have another button defined for Cancel that gives you a
different color indication, and would be written as:
And also, this kind of button need not even contain text, because the
text would be included in its definition.
button-cancel: button [
facets: [area-color: gray]
In conclusion, I think that a good design allows both methods. For the
quick app, users can throw in the color. For more serious apps, define
the style. Just like defining a function, it's easy, and will save you
I don't really understand the difference. From your description and relation to HTML world it seems like using HTML vs CSS. But it is imo not like that. It is like using inline CSS vs stylesheet CSS in one place, so I find your description not beeing accurate (if I understand the problem correctly).
Does not just 'button "Delete" maroon' change the same facet, namely 'area-color here?
What I am more interested to know is, how is a button text being rendered. From docs there is no implication in stylesheet, how internal gobs are combined, rendered. So far we can see the only method of rendering being done via a draw block. So is button being a compound style combining text, and separate drawing? Or is it hardcoded text type gob over drawed block?
It may not matter for quick, throw-away apps, but it'd be good if VID3 encouraged the colour-coded habit from the start. And if VID3 is going to allow global style-sheets of some kind, the critical colours need to part of that too. So needs to be a default part of VID, not just something programmers should consider including with each app they write.|
Speaking about coloured buttons reminds me of something I had difficulty doing in the past. Will VID3 apply the lemma of "doing simple things in simple ways" by enabling me to change the colour of an EXISTING button without hassle? I had no trouble changing the text of an existing button, for example, but the colour was a different kettle of fish. (Or perhaps if I understood the coding structures shown above by Carl adequately, perhaps it turns out to be a silly question?)|
I'm not sure, but I guess it will be done just by changing the facets/area-color value.
It's true, that with R2 it is a litle bit tricky, as the color of buttons is hardcoded in effects:
view layout [
b1: btn "test" 80 red
b2: btn "change" 80 [
b1/effect/('colorize): random 255.255.255
remember there are lots of color blind folks in the world, who might want something other than "red" to tell them its a critical function.|
you all know im mad an=bout GUi's and makeing simple front ends etc, and carl as right about colour, however perhaps someone should also mention sound in the human condition too, DO we need a AUI defined or do we think about including it in the GUI sections ?
im thinking a simple click or Mp3 sound file as you mouse over or direction key onto the button your interested in making prime for that other additional information via Audio hints or clues too.
we dont have a "this is amiga speaking" say/speak device in rebol3 do we, but audio is also good for the visually impared market place and there are countrys that stipulate their official govt websites and apps be open and available for use to these disabilitys too....
Here here! Or should I say: Hear hear!...
Humans try stuff until they find things that work. Then they generalize. That's how we learn. REBOL VID allowed us to try stuff with the ability to put it in a style sheet when we discovered things that work. I use REBOL precisely because it allows me to think and learn in a human way. That's why we need to be able to change the color of a button by adding "maroon", and we need to be able to define local styles. When we get something that works we'll generalize it.
There isn't any reason a commercial developer can't discipline themselves to put everything in a style sheet and generalize all the attributes during development. But I'll bet nearly everybody uses the local styles and local attributes until they've decided what works for the design. Come on folks...fess up!
I just love the Stylize system. I haven't yet explored it in detail - but have done things like the button example. The power of this will be seen when building menus, toolbars, status bars etc. to reflect a particular look and feel. Of course I am assuming this is all possible. Hope someone can post some examples of these things ;-)|
Post a Comment:
You can post a comment here. Keep it on-topic.