New button styles (With mockup images)

[madprof]

Hi Karim,

Adding per-type colour is relatively simple:

Code: Select all

	switch(but->type) {
	case BUT:
		but->col= BUTSALMON;
		break;
	case SLI:
	case NUMSLI:
		but->col= BUTPURPLE;
		break;
	case TOG: 
	case TOGR: 
	case ICONTOG: 
	case TOGN:
	case TOG3:
		but->col= BUTGREEN;
		break;
	case NUM:
		but->col= BUTGREY;
		break;
	case TEX:
		but->col= BUTYELLOW;
		break;
	default:
		but->col= block->col;
	}

Add this in source/blender/src/interface.c in ui_def_but, instead of the line which reads

Code: Select all

but->col= block->col;

. I tried this out just now, and although the idea is extremely good, it looks rather odd (tuhopuu2 + above code):

http://www.madprof.net/working/dark-col.png (Dark Colours)
http://www.madprof.net/working/norm-col.png (Normal Colours)

I don't know if the "oddness" is just me, and I would get used to it, or if it would be "fixable" easily (making some special buttons not default-coloured).

It is a facinating topic to look into though.

Dan

[Karim]

Nice!

I believe that there are a couple of things here contributing to the "oddness" but the main issue is that by selectively coloring different button types, you've gone and directly emphasized the terribly disorganized nature of the Blender button interface

What I mean here is different shapes & sizes of buttons that do different things in different ways piled willy-nilly all over the window. The Blender interface will remain visually noisy to some degree until the physical organization of the controls is addressed.

I still think it's a good idea, but some of the visual clash might be solved if the colors were generally more similar (ie All of the same hue, but different Val, or all similar Value but different Hue). THe User would still get the visual cue that a green button (or whatever) will act a certain way all the time.

Also, different-but-similar button types ought to have more similar colors. For example, Radio-Toggles like the "5":"8":"11":"16" buttons are more similar in action to a straight-Toggle button like "OSA" than to "Picker" buttons like "Targa ..." ... so the colors ought to reflect this similarity.

[Fred_Pyo]

This might be a little off the current of conversation, but,
how will these buttons look in a smaller resolution?

[wavk]

Got to love what can be done with a few simple gradients! And then I see LightWave wants to drop it's utter cool classy gradient buttons in favor of blender style, pop in the eye buttons for version 8. Keep up the work, I see good images.

[Rhs_CG]

Broken your work is amazing. On the issue of the arrows, perhaps making the arrows a lighter color, than when the cursor is placed over the button would be useful.

BTW, where can I download your latest build?

[Carnivore]

Hi,

I've read through this topic and I thought I would share my 2 cents.

1. Broken, your interface looks fantastic
2. I really dislike the number fields, though. They're too dark and seem to be pushed in buttons. Why not have them look like regular buttons with arrows or make them in a light shade of some color that would not disturb the over-all look?
3. Landis, your idea for the interface looks great for a game or a website. You've clearly got a good eye for combining colors and design. But, for a effective and easy-to-use interface, the design surpasses the functionality. I, for one, would like to have some color in the generally-already-so-grey 3D world.

Thank you for taking the time to read another one of my poointless posts.[/list]

[jd-multi]

Cool layout buttons, is there already a blender release with those buttons. Did you tell this to the devs, thery really have to add that layout in blender, and make a place where you can select some layouts, because some blender users don't want to use another layout, so they can easely switch layouts, or select the old one. Or is someone planning to release blender 2.29 or 2.30 with this layout?

BTW, Landis, where did you get the Blender font?

[hanzo]

jd-multi: do you mean this, highly workable 2.28 latest release of broken's GUI? http://reblended.com/www/broken/blender ... 030824.zip

[jd-multi]

I tried the app in that zip but it gives me an error: "This application has failed to start because SDL.dll was not found. Re-installing the application may fiz this problem. ??

[theeth]

Copy both DLLs (SDL and GNU_gettext I think) from your 2.28 instalation in the folder of the new exe.

Martin

[matt_e]

Ok, it's been a while... Time for some replies.

I don't really like the arrows on mouse-over. It defeats the whole point of the changing the GUI! People's justification over changing the GUI was that it was not easy to distiguish the type of buttons. the arrows solve that for those buttons so I'd rather they where there all the time.

You're right. As a midway compromise, right now I've got it with arrows always displayed, but lighter then before so it's not so noisy. The arrows get darker on mouseover. It's a bit hard to get the effect from a static screenshot, but it's a nice subtle feedback when you're moving the mouse around the screen. Gives more of an impression of activity and interactivity, that these arrows mean something and will do something.

Another thing which I'm finding annoying (with the arrow buttons, is that they seem to have much stronger gradient. The background is also too dark to have black text on. I would rather arrows all the time but then have the actual colour and gradient like the regular buttons.

To solve the arrow problem maybe you could have a smaller flat box on top of the button which represents the text and keeps the text within it.

This is a tricky one. Incidentally, this is a bit similar to what I was thinking of when I first made some early mockups in Photoshop way back in June. One of the things I've been trying to communicate is the non-standard (yet very useful) way that Blender's number fields work.

early mockup:


I haven't pursued with that number field design because there are a number of problems with it. It makes it look like there are 3 individual buttons (which there aren't). To implement it this way, it would take a bit of re-doing the way that the numbuts work so that only clicking on the 'arrow' parts would increase/decrease (which is less functional - fitt's law -> larger targets = easier and faster to hit), and would mislead regarding the 'drag to increase/decrease' functionality. Going to a design like this would mean lesser functionality and efficiency in the buttons, which isn't something I want to be doing. I like the efficient way the current buttons work, I just want to communicate it better.

Anyway, going through my thought process, on one hand, you have number fields in most other UIs, which are basically the same as normal text fields. Enter a value with the keyboard and that's it. These are generally displayed as recessed flat rectangles. On the other hand, there is the interactivity aspect of Blender's buttons which should be communicated too (especially since when you single-left click on a num button, it doesn't edit the value manually, but increase/decrease).

So in the current Blender, you have the number field looking like a normal button, which makes it seem more interactive, yet it doesn't communicate the 'click to increase/decrease' functionality well at all, and it doesn't look like a field that you can edit yourself. However if we go to the other extreme and make it look like a standard flat recessed rectangle, then it doesn't communicate any of the interactivity, and creates incorrect expectations when people click on it and expect to be manually editing the value.

What I've tried to do is create something taking parts of both approaches. It's recessed like normal number fields rather than sticking out on a button, which hopefully gives the impression of an editable value. But at the same time, it's shaded slightly (looking a bit like the buttons) which would hopefully imply interactivity, that it's different to a standard number field. Although it's recessed, it's not to the same extent as a pressed button (dark+white text), so the user is aware that it's not the same as that either. Anyway, in the latest version I've got, I've taken down the contrast of the shading a bit. Perhaps it could be made a little bit lighter - I personally don't have a problem with the way it currently is, but perhaps people with worse eyesight may want a bit more contrast. Feedback? I don't want to make the text white, because then it conflicts with the pressed (activated) buttons.

When I see this sample, I think it looks great (except for the problems mentioned above vis-avis the bf: 0:500 button) But when I had the whole interface in front of me it came across as clutter.

The layout will need to be changed and revised and revised in due time (if I have my way, into something more 'collapsible ' and less cluttered). Right now I'm just looking at the buttons themselves so don't worry

[matt_e]

I have a 1024x768 screen, and there are one or two drawing problems with buttons occasionly, with it not showing the dark outline on buttons (need to zoom in to get them). Probably something to do with using the "+asp" when "asp" is too small to draw a line, or something (I had similar probs in gooey-ui).

Yeah, I've been designing it for 1280x1024 atm. Some sort of rounding errors I guess. That doesn't worry me for now - it can be worked through and solved later. It's best to design first and work towards something that's visually optimal and then work out the technicalities later. Maybe the technical limitations can be solved, or worked around, or maybe compromises have to be made. But I haven't wanted to start the design while working under technical constraints since it's much more limiting, and one can miss out on something really good if one's constantly thinking 'will this work in the software? will this be easy to code?'. It should happen from the point of view of what will be best for the user, rather than what is currently possible or technically easy.

The drop-down arrows on buttons are rather hard to see on 1024x768, and come out looking a bit like a squashed diamond. Could you try just a down-pointing triangle?

I prefer the Mac-style double triangles, because Blender's menus work more like those on Mac OS - they don't just drop straight down like in windows, the menu pops up and extends in both directions (much better! ). On the down pointing menu icons in Windows too, if the menu is close to the bottom of the screen and there is no room to extend down, Windows will extend the menu upwards (against the direction of the arrow). This is not good since it breaks the metaphor of the arrow icon - instead of containing the additional metaphorical meaning of 'something will extend downwards', it becomes just another symbol meaning 'this is the symbol for a menu'. In which case, the metaphor is wasted and the icon may as well be a star, or a smiley face, or whatever. I know that sounds really pedantic, opinionated and nit-picking, but as they say, "the devil's in the details" and the details can make a really big difference to the feeling of comfort and polish when using an interface.

Anyway, if the technicalities of the squashing in the OpenGL drawing can't be solved, perhaps an alternate solution could be to just use an icon, so you could be sure it would be displayed pefectly, pixel-for-pixel. I don't know...

Adding per-type colour is relatively simple:

...

I tried this out just now, and although the idea is extremely good, it looks rather odd (tuhopuu2 + above code)

Mmm, yeah I like this idea too (with a preference to choose between greyscale and coloured buttons). My opinion echoes Karim's here, I can imagine it would be less jarring with a more harmonious set of colours and a less haphazard button layout. I don't know about the idea of splitting up the 'different-yet-similar' buttons into different colours though. If you make it too fine-grained, you start to dilute the visual language and make it seem more like the colours are more random.



Hopefully these last two posts will have addressed some questions that others have had, too. Thanks very much for checking back on this and discussing. So, any responses? Feedback? This process certainly isn't 'finished' yet

[ilac]

As a midway compromise, right now I've got it with arrows always displayed, but lighter then before so it's not so noisy. The arrows get darker on mouseover.

Good idea! Will give proper opinion when I see it in action!

It's recessed like normal number fields rather than sticking out on a button, which hopefully gives the impression of an editable value. But at the same time, it's shaded slightly (looking a bit like the buttons) which would hopefully imply interactivity, that it's different to a standard number field. Although it's recessed, it's not to the same extent as a pressed button (dark+white text), so the user is aware that it's not the same as that either. Anyway, in the latest version I've got, I've taken down the contrast of the shading a bit. Perhaps it could be made a little bit lighter - I personally don't have a problem with the way it currently is, but perhaps people with worse eyesight may want a bit more contrast. Feedback? I don't want to make the text white, because then it conflicts with the pressed (activated) buttons.

WRT the Text Fields, I think it would be a mistake to have white text for text entry fields, because then it will become difficult to distinguish between a text-field and a pushed-in button. As someone else suggested, I think Text fields should be completely flat (no gradient at all) since by your own arguement (which I agree with, BTW) they do not fit in the button metaphor, and don't need the extra "meat."

Thought I'd also quote Karim opinion which I agree with very stongly. I don't think the recessed text fields should have a gradient.

The problem still present is that (imo) there are still several different visual cues per different button and which adds noise! Lightness vs darkness is already a very obvious visual cue, so I wouldn't have a different gradient for the sliders or depressed buttons. After all the button is suppossed to be 'going in' but its not flipping over! So I would suggest working with only one gradient, and then varying the darkeness for pressed/unpressed. (plus the text is white too!)


I see what you mean about having arrow buttons at the end. they do look much nicer though but would decrease in the functionality so no argument there. I'm at a loss. They still don't look right as is. (apart from the inverted gradient problem i mentioned in the paragraph above) it could be because they blend in too much with the background. I'm still for the opinion that they should either look like the non-pressed buttons with the arrows being the key visual cue. They could almost even be like the pressed buttons actually with little white arows. It makes sense, after all these are actually 'constantly pressed don buttons. Its not and issue of is it on, but by how much!

I realise the arrows alone might not be enough visual cue. I'm thinking...

Hmm, we could actually afford to have slightly bigger arows. After all the overlap issue should not be a problem once the interface is reorganised as the size of various butons etc will change accordingly. So something like the blur factor can be wider to accomodate the arrows or even changed to a slider (see below***)


I'm gonna regret saying this but....
I don't like the idea much I think but keeping an open mind...
Oh Bummer.
here goes:

How about having a horizontal gradient on the arrow buttons? Would give feed-back for the 'sliding' issue. (Me currently having horrible flashes of gradients in my mind! ) Still It might work visually because it reflects the function of the buttons. A sort of jog shuttle?




*** BTW had you seen my post to the funboard regarding sliders vs the arrow buttons? I suggest that whenever possible we replace the arrow buttons with siders. This is because the sliders give a visual feedback of the available range, the arrow buttons do not. I noticed this because of the new hardness settings in 2.28. I was suddenly at a loos of how much my setting was, as a number meant nothing when I couldn't see it in context! So whenever possible, I vote for sliders!



On a side note. I've just spent a couple of weeks working on an Avid, and I re-confirm that high gradients are a real nuisance!! What's cool about Avid is that even gradients are customizable so they can be lowered completely! Unfortunatly I'm sharing the set-up with someone who's been there longer than I have (the boss) and he doesn't seem to ever change anything from the default set-ups! So now I keep switching back and forth!

[jd-multi]

Thanks Teeth it works, great layout, but I think the icons for texture, shadow, material buttons, editmode and such things, should also have a redesign they are so ugly and doesn't fit in that new layout, and what's happened to the top menu for opening, saving, reopen last, and scuh things?? I can't find these functions , Btw, I also like, that the view function is chanced into a drop down menu with top, camera and more, great update, they should release blender 2.30 this way.

[Money_YaY!]

hey , can anybody tell me how to code a button to get rid of the borders and edges of the buttons ?