Update UI Widget Style #38037
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
45 Participants
Pablo Vazquez
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#38037
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The UI styling and widgets currently in Blender were designed in 2006 for the upcoming 2.5 refresh. While it has served us well for a while, it's clear that many areas don't work optimally. The current widget designs look work ok when viewed individually, but when many of them are put together the overall impression is crowded and busy.
The Issue:
Goals:
Proposed changes:
Implementation:
These changes require both changes to the widget drawing code and the default theme.
Simplified widget example:
Full simplified widget set:
Example (Render Properties):
With alternate, single column layout:
Changed status to: 'Open'
Added subscriber: @billrey
Update widgetsto Update UI Widget StyleAdded subscriber: @NGMAT
Added subscriber: @ThomasDinges
I like the rollover style for the number buttons, this would fix a current problem too.
Since the alignment of Text in number buttons, I sometimes click on the value to manually edit it, but hit the arrow instead. So separating this more visually would be good.
Regarding the more flat style, I like these, but probably it would be cool to have a quick hack patch to see the result in action first.
Added subscriber: @RainerTrummer
Added subscriber: @JonathanWilliamson
Added subscriber: @BartekMoniewski
as a user, this "clean" style appeals to me, and looks less clunky, so I approve. This is obviously personal preference though. To me its easier on the eye, and small things like this make working in the software a little more appealing and fun.
Added subscribers: @PawelLyczkowski-1, @WarrenBahler
I fully agree that this improves the current "3D" look, and makes a much more relaxing interface.
something similar has been proposed in this mockup by the talented @PawelLyczkowski-1:
https://developer.blender.org/file/data/752dnj363knvysbskedq/PHID-FILE-247yzz3oqf5xbcxnf5ay/mockup02_06_nodesc.png
@WarrenBahler: right, that's a fairly good example of how the UI can become calmer going in this direction
Added subscriber: @ideasman42
Re: Many widgets don't give proper feedback when hovering the cursor
Totally agree this is important, but its orthogonal - we can have better UI feedback with/without different style button drawing.
Added subscriber: @jta
Hmmm....just FYI, a lot of us Southern California people use the emboss with certain themes. It's probably from our familiarity with commercial/professional tools that use this look. Not that this is an idea stopper but be advised it may be a groan generator if it is taken away. ; )
Added subscriber: @ionarn
@ideasman42: Yes that's true. They are not necessarily related. I could split this up to get two tasks instead?
Added subscriber: @tychota
Well sometimes we still need a border. For instance in User Pref>WindowsBackgroundColor, without border it would be plain grey in and outside.
Else i reaaly like this flat ui idea.
@billrey - re: splitting up proposals.
If we're going to make large UI changes to the UI we could make them first and add extra highlights after.
I'd consider highlights as general improvements that can be added any time (probably theres not much disagreement here?).
If it looks like the new theme wont make it for 2.70 then it could be worth to split up the proposal to make the changes to highlights first.
@billrey - Quite like how this looks but I have big concerns about actual usability. This design need a lot of work before implementation.
Colors:
Due to only 2 colors used for items most of them look too similar. In menu button and action button only real difference is small black arrow. Theoretically text placement is different but we must mind interface scaling, so if button will be narrow enough text placement will look the same in those buttons. Also "One" and "Three" option buttons looks exactly the same as Action button. Slider with label set to 0% will be very quite similar to Menu button.
Currently blender use many colors and different draw style for items and they are very easy to distinguish. I think two colors are not sufficient to achieve that. We can leave fancy gradients and different draw styles but we need to introduce few more colors to keep current clarity.
Gaps:
Next thing is gap between items. Most of buttons in blender interface are grouped and aligned to each other. We can distinguish them because of button borders. If there will be no border or any gap items will fuse into one wall of text. Try to recreate current 3dview toolbar in style you proposed and you will see that. In flat design items shapes are recognizable mostly because of contrast with background or contrast of item themeselves. Many applications use very bright or very dark backgrounds and a lot of space between items. This of course will not work with blender and its against your proposal to calm down interface.
Thus I suggest to consider to keep the borders. Simple, without emboss effect, just subtle darker lines. Its the matter of carefully tweaked color theme. Some interfaces regarded as flat design use borders too.
I think there is many scenarios when this design will not work well at current stage. You didn't include many item types and arrangement of them in your mockup.
There are textboxes, lists, inactive items, gradient ramps and many more. Items can be aligned vertically and horizontally. This things have to be designed too. I made few screens that shows most of the item types and placement scenarios. We can use it as template for next mockups.
@tychota: Agreed, the border makes sense for colour swatches.
@ideasman42: Ok, will split it up
Ok, I split up the task. Hovering to hide/reveal information is here:
https://developer.blender.org/T38070
Added subscriber: @marcog
Personally, ultra-flat style isn't going to make things clearer. Agree gradients and strong embossing now are too intrusive, but a sort of mobile app design style is not the best solution for a complex and rich GUI such as Blender.
Subtle embossing is still a powerful way to group/divide contents, without worrying about changing background shade of grey for each tab and panel for example.
To summarize, extremely simplifying going flat all over the UI, doesn't mean is more readable and cleaner, it might become the opposite because the eye doesn't see any hierarchy, everything is on the same level and unsplitted.
I agree with @marcog. This have to be designed well on mockups first.
Before changing drawing method of interface I propose to do something with current tools. New theme without gradients ant with darker colors will be fine for now. There is task for this here: #37419
Added subscriber: @JoseMariaRichardsonRebellodeAndrade
@marcog @BartekMoniewski @billrey
The mockup made by @PawelLyczkowski-1 is pretty good (see above, in one of the comments by @WarrenBahler ). The divisions are pretty clear. I prefer the arrow in a light grey than in a darker grey, because I think it's important that it's easy to see if it is an expandable menu button or not.
Added subscriber: @NicholasBenge
Here are some examples of the difference seen in context.
With the current layout:
With the simplified, clarified layout:
I maybe miss something here, but how is a "simplified" layout better, which takes 2x the space? We have a scrolling problem already.
Added subscriber: @karja
Hi,
I am not a fan of this style and personally i see no point to put effort in this UI-aspect.
To me it seems that now every UI-area runs into danger, please hold on here.
Sry, i find it very unappealing like this.
@ThomasDinges:
This is not directly related to this topic, but I'll answer your question:
Basically, it's a tradeoff. In the extreme, we could also put every control on Blender on the screen at the same time (no scrolling!) but that doesn't make it faster, because then you have to spend lots of time hunting with the eye to find the right control.
It's an extreme example, and I know that's not what you propose, but just to illustrate the fact that putting maximum amount of controls on the screen at the same time does not necessarily make things faster. It takes a long time to mentally process confusing and complicated layouts.
With a more organised approach, users can drill down, open a panel and quickly scan through the controls if they are clearly laid out. Also, a layout like this means the properties can become narrower, saving space that can be used to make the users content larger (e.g. 3D View can take up more proportional space). In the end the UI should defer to the content.
Another benefit of using a single column is this: Because labels are always on the left, and values always on the right, it means it's much easier for the eye to scan down the list of settings.
In a more concrete example, the current 'Dimensions' panel consists of two groups of controls, size controls and frame range controls. These could be in the same panel, but then there should be some sort of divider:
But since we already have a system for panels, we might as well split it up.
As for scrolling, there are several things we could do:
Anyway, we can discuss this further somewhere else, perhaps in a different design task.
@billrey The rearranging would be a great step in improving readability, as would be the calmer style.
I wouldn't remove the embossing completely though. It's an intensive graphical element, and we see in current GUI what it does when used in excess, but in provides a way to signify importance. For instance - window edges are more important than panel edges. Embossing could be a way to signify that.
And it's currently a bit oversimplified - there's no way of knowing which field is a slider (if 50% would be 100%), and which is a value input field (1910px).
@karja
We can't really do anything with such an information (the personal taste of a single user). You could instead point to something using arguments - "the flat style is worse than the embossed style because...".
Removed subscriber: @karja
@PawelLyczkowski-1: yes, you are right that some controls become almost indistinguishable.
It's the opposite approach of the controls that I put together for 2.5, where the focus was very heavily on distinguishing the various types of controls.
Since then I've come to realise that that was far too great a distinction. A menu is not really so different from a number field. One just gives a list of items, the other allows one to input values. They are both settings, on the same conceptual 'layer' in the UI. Clearly there should be some distinction (e.g. some arrow for the menu), but I don't think it makes sense to dress it up to shout 'look at me! I'm a menu!' :)
What I think is more important to put distinction upon is the various areas, to make them easier to tell apart, and things like the toolbar, to have a way to display tools in a clean list.
On emphasis:
There are several places where we need emphasis on controls. Things like the highlighted Render Image / Render Animation buttons. I think we can use colour or styling to put emphasis on important controls like this. Another example is the Open/Save buttons in the File Browser. This is not really emphasis on the type of control, but an emphasis on specific important controls or hierarchies. This way we can lead the eye of the user to the right places in a much more controlled way.
There could either be a way to override the widget style for these cases, or even better a way to flag a control to be emphasised, which then gets a special widget styling (different colour, for example)
About the percentage sliders:
I see your point. The idea is to make it like a number field that's half-missing, and that fills itself up when the percentage increases. When it's at 100%, it does look like other number fields. I'm not sure that's bad though? Currently the large difference in design for number fields vs sliders makes it look like they are very different things. Really, they are no so different, just that one describes a value that's relative. But I can see the argument that if it's at 100%, you might attempt to click arrows to increase/decrease, even though there are no such arrows in percentage fields (there could be, though?)
This is an interesting discussion though, how to communicate the difference between controls in a subtle way.
Perhaps an approach could be to create a separate branch for some of these related things (rollovers, widget styles, layout, placement of tool settings in a top-bar redesign etc), where we can then more calmly implement changes across many areas, and then when there's a good, meaningful uniformity and sensibility we can merge it back.
Figured out a way to make the radio buttons control clearer. It's now easier to see which is the selected item, using the same concept of 'empty widget' for the options that are not selected
Added subscriber: @karja
Ok, for me:
For me its the opposite of a calm interface. Text is usually dark on white, so i would not reverse that completely.
Currently my eyes have many problems with the contrast of this design.
The real difference i can see are darker and lighter areas, which can be changed via themes.
In my opinion, this design is a bit too niggling to the current style.
The handling for entry fields or buttons are worse an improvement, the suggestions are nice.
But it not needs to be a change right away for everything at once. Hope you understand what i want to say.
So for a good comparison to see benefits i would like to see the same color scheme as it is now.
I think its otherwise a matter of personal preference with color-themes.
@karja:
Ok, I'm trying to distill your points.
1: Yes, these examples are with darker colours. As you say, it's somewhat unrelated, but there are some clear benefits of darker UI's for graphics apps. A fair bit of research has gone into this over the years that suggest this. The darkness of controls and panels is also there to suggest a meaningful hierarchy vs the brighter panel headers. Everything could also be brighter though and still work, but that also means more light shining in the face of artists. But again, it's somewhat of a different task to change the colours.
2: That's related to the darkness. Once you cross a threshold of darkness, brighter text then becomes more legible, because you can get more contrast that way. If the entire UI is brighter, then we can use dark text.
3 Not quite sure what you mean here. I did think of putting some borders between the controls, like so:
Though not sure it's really needed. But it's worth considering doing this.
4: The removal of the arrows is meant to be because they should get hidden when the cursor is not over the control, as outlined in this task:
https://developer.blender.org/T38070
The nice thing about this is that we can then remove the cluttering arrows when not needed, but then display much more granular and useful feedback when you are hovering over the control.
I also thought about doing the same thing with menus (hiding the arrow when the cursor is not over a menu), but I think the arrow is needed in this case to communicate the fact that it's a menu.
Hey, I like the flat design.
But with a bit shadow you can give menus much more depth. So you can see that the dimensions menu is the "header" above it's settings Resolution, Frame Range, etc.
Hi all, I spent most of the day building @billrey 's proposed changes into @BartekMoniewski 's template. This is what I came up with:
And the svg here -->
Sidenote: I think that this task should be deicated to revising the proposed 'flat' theme, and that any UI reconfigurations (moving around buttons and such) should be moved to a seperate task. This would help focus the discussion and force us to look at the interface as a whole, instead of little sections.
Feel free to edit the svg to reflect your revisions :)
EDIT: just refreshed my page and saw that @billrey changed his concept, and added a bunch of stuff. This mockup is based on his last concept..
Well I find blue buttons's disturbing. Why not making them grey, with a border or a shadow to highlight them. The font need to be a little bit bolder to readable. Else i found it perfect.
@billrey - I think you make mockups only on smart portion of interface and we don't see how this changes affect other areas. I'm afraid this design by its current stage will not work good when we have full-sized menus.
You must bear in mind python addons. People build interfaces out of many item types and arrange them in different ways. Currently all this items are easily recognizable because of colors and divided enough by outlines to distinguish each other. Everything fit nice now. In design you propose there will be many cases when all of items will fuse into one wall of text because of lack of any borders and distinction between items.
Here is popular addon caled Oscurant tools. We can envision how it will look with proposed design.
I find single column a huge usability regression. Scrolling is big problem right now and it will be twice bigger then. ;) Not everything can be super simple in program with that amount of features.
But there is another unfortunate thing about your design - Repeating pattern.
Year ago I made my own toolset in zbrush and at first all my buttons was same size. I was thinking this uniformity will be clear and simple but I was wrong. Once I started sculpting I find that I have to search for a specific text in wall of same sized buttons. Something similar happen in your design, not as strong feeling like list of 15 same size buttons but it dangerously goes to this.
The key is diversity. We read button texts when we learn but after we know that is what we search for them by visual landmarks. We unconsciously know that framerate menu is under 2 big bright boxes with 3 rows of value sliders and next to 2 another sliders. Icons helps this very much. I don't know if in blender it was intentional design decision as in few other programs but it works great. Problems starts when we got similar looking areas like Vertex groups and UV channels, we have to read what is what, but in this case fortunately icons look different.
One column of labels and another for similar looking buttons look clear but it got much less landmarks to find something.
@NicholasBenge - Great work! I will comment this tomorrow.
So I modified the mockup based on @billrey 's revisions, here it is:
And the new svg -->
I think that the new concept looks a little more refined, but it lacks that strong contrast the first concept had. Still unsure what I like the best.
Added subscriber: @jonim8or
@ionarn: Interesting, I totally have a different view: I think that the contrast between the header and the contents it belongs too is too sharp. (it seems the headers are totally detatched from their content).
I would suggest a gradient between the header and its contents (I 've added the option to your mockup)
BTW in all three mockups I'm a but puzzled by the blue buttons: It seems to me there should be a separator between that and the first header
Added subscriber: @lsscpp
Added subscriber: @michaelknubben
I'm still really interested in exploring this design by blenderartists.org member Harley:
http://www.hacheson.com/files/Articles/Blender%20UI/Properties%20Panels/index.wiki
This coupled with the flat graphics could look really good.
From Harley's page, there's also this article:
http://www.hacheson.com/files/Articles/Blender%20UI/Editors%20Menu/index.wiki
Ties into this, but probably should become a new topic.
Claiming this one to slowly start exploring. I've begun experimenting with the widget draw code, so this will be fun to tackle.
@JonathanWilliamson I think the most promising idea here so far is the cleaned up layout of the panel buttons and other content in this mockup:
It removes the daunting mess that the Properties window is at the moment, making it less intimidating, easier to search through, and generally more pleasing to the eye.
The con here is that it will stretch content vertically, which means it may be necessary to introduce tabs to certain sections? Like Render, Material and Texture.
Changing the GUI style - I think no mockup provided a perfect solution as of yet, so it may be wise not to rush it.
Added subscriber: @Januz
I was just going to open a task for this when I stumbled on this, I don't know how I missed it before :)
I made a proof of concept patch for making the UI flat:
flat-theme-proof.patch
It doesn't have any options though, it just flats out.
My proposal was to add some new options to themes:
In User Inteface:
I believe the UI holds fine without the bevel effects, but I can see some people still wanting them for different reasons. It's more of a matter of taste, and taste is what themes are for.
About the mockups:
@Januz
Can you also post a screenshot?
Added subscriber: @bat3a
it has just small changes! i don't know what is flat in that.
I'd love to see this happening especially the one jonim8or modified with shadows only.
@PawelLyczkowski-1 Sure, here's a screen with the modo theme.
@bat3a Sorry I wasn't clear about the patch. It only removes the highlights (or bevel effect), it's not a full theme.
@Januz , that looks great, +1 for adding options instead of removing them.
perhaps you could post a screen shot with a more "flattened" theme ? this would make the comparison easier.
I've attached a theme that should work well for this, but overall; I think we should probably retain some outlining and imbossing. removing all of these elements like I did in this theme makes it necessary to use more color contrast to distinguish areas, which adds distraction in its own right.shadeless_theme.xml
@WarrenBahler Here's your theme with the patch, looks pretty neat.
Added subscriber: @leandro_cavalheiro
@ januz, it does rather..
If you can get that patch included for 2.71 it pretty much completes the task.Almost every other suggestion here can be accomplished with the theme options we have already.
Then we'd just have to implement a new default theme once the UI team OK's it.
Great work !
flat design doesn't mean just no bevel, there are many things that combined makes it look a good flat design (rollovers ... ), there is coding to be done, even the slightest color change make it right or wrong.
adding flat style icons to previous mockup:
Hiho,
I think at first we have to decide what we really want to have. And I don't mean questions like "how should the icons look like?" or "a ui with a bevels/gradients or not".
I think we should ask other questions: "What are our special targets with the new Blender ui?", "Should the ui enable us to handle it very fast or do we want more clearity?" and for sure some more questions.
Before we change the ui we need to be sure, that the decisions suits our needs.
And one more note: There is a difference between the ui look and the ui design. We should differenciate both very carefully.
The correct order seams to be:
But hey, I am a blender user and not a programmer. I don't know if I'm right with my sentences.
Oh, and sorry for my poor english. :)
Ionarn
@WarrenBahler, thanks but we still need to add the options
@bat3a agreed, but I don't think we should be focusing on flat looks only. The new widget designs should work with any theme settings.
@ionarn Those are some valid points. Some of those questions are answered in the guidelines .
I did some tweaks on @billrey's mockup
SVG file:
Here's an example built with @NicholasBenge's mockup:
(No layout changes from current Blender)
SVG file:
Added subscriber: @MikhailRachinskiy
Is there a deadline for this task?
Added subscriber: @JulianEisel
I offer myself to help out on the coding side. Feel free to poke me when some decisions have been made :)
Added subscriber: @mont29
Added subscriber: @Genome36
Added subscriber: @YorikvanHavre
Added subscriber: @pablovazquez
Okay @venomgfx is working on more mockups for this, based on @billrey's mockups above. He will present his mockups soon.
Added subscriber: @liquidape
Added subscriber: @niewinny
maybe it's good time to think about replacing/redesigning our direction OpenGL light widgets which are far from perfect. Or just use simple Azimuth, Elevation sliders instead. At least it can be thought on next meeting
Let's stay on topic. The OpenGL light widgets could use some love but that's for a different task. It's in no way related to this task.
Added subscriber: @AditiaA.Pratama
This comment was removed by @ionarn
Added subscriber: @gandalf3
I personally like having the low-contrast borders between joined sliders, like in this example: https://developer.blender.org/T38037#56
@gandalf3: It's not useful to only know what you like or not.
Because everyone has a different taste for good design and looks on it with different perspectives, reasons are needed to be able to get to a common consensus via discussions.
From just looking at the mockup images, I find it a bit difficult to quickly determine which parts of the sliders do what.
It might be different using it in real time though.
Added subscriber: @manuelmuzzurru
hello
i try to propost design see my draw:
i'm not sure for space of font, but color clear...?
i can try again for fix it if it's needed or not ok?
Added subscriber: @Lapineige
Added subscriber: @Wildlux
i like this style minimalist.
Not sure about this. We already have issues with vertical scrolling and this looks approx 3 tiles taller than actual interface.
No clear distinction between value bars can be misleading.
Added subscriber: @zeauro
I don't understand why nobody reminds it.
Clean interface with one setting per line was already tried in 2.5X.
It was rejected by users because it is unworkable. Vertical scrolling is necessary at each setting change.
Of course, it looks better and it is more welcoming. But we need to able to work with blender.
It is not a problem in Cycles Interface because nobody is using Properties Editor for Cycles Material creation ; we are using nodes for that.
Cycles Panel used in Properties Editor like Settings panel, Ray Visibility, Cycles Hair are using 2 columns.
I am not against one column of settings in a Panel at condition that Properties Editor is not limited of display of one colum of panels.
We have two columns of settings in panels because of that restriction of one column of panels.
Panels readability problem is not related to panel widgets it is related to Properties Editor limitation.
Work is needed on Properties Area if you want a cool panels look.
hello
@Wildlux
it's base idea from precedent posts, ok?
@BartekMoniewski
i did 3 tiles, because i try design look, it's can working vertical scrolling, if mode to horizontal i will add new design look, after i will send ok?
but for now it's base idea for design look ok?
nothing to choose ok?
hello
Added subscriber: @Baron_Von_Ledger
Well, it's in a random spot, but here's my two cents. I personally think that the clean interface would help Blender. Removing all the bevels and gradients makes for a cleaner, and therefore easier to read, interface. While there will still be the problem of defining different areas and making sure that it isn't too minimalist, I think it's a step in the right direction. I'm sure there will be some users that will scream bloody murder, but change happens. And heck, you could even make it optional.
hello
i try fix look design but i'm not sure if my look design is suitable...
i'm not sure and depend from you ok? :-)
this is vertical, open box
this is vertical, close box
this is horizontal, open box
this is horizontal, close box
the box = group, this is very important for new user entry else new user will not accessible or unlike to learn for new software 3d "blender"..
for user expert is not problem, and fast for my/your eyes and relax for moving eyes (important, for avoid fatigue/stress to my/your eyes).
what do you think this?
:-)
hello
i forget to add information, see my picture:
read my message in picture..
I totally agree with the style with less gratients, more flater but with some highlight on important buttons or progress bar. That's a good thing, the interface is less eye catching as this, but not completely masked.
@manuelmuzzurru : your proposal is a very good idea, I was thinking that there was a problem with this style before, what you made can realy make the panels more readable.
But as @zeauro say before, the actual one column style is a productivity killer. On this picture showed above (sorry i don't know how to use images), on the current 2 column style, you can see (header excepted) 22 buttons.
On the new, 17. And as you can see, it takes more place on screen (there is a difference of 1 header size), but all the options are not here. No AA option, so it will take even more place !
Ok 1 column is more readable, but always force users to scroll more and more, to loose their time using the interface.
You can gain a few time by making the UI cleaner (but you will mainly gain in comfort), but the main priority is artist's productivity !
The tabs in the toolbar was made to avoid scrolling, to save time for users, and not to be nice.
Please keep that in mind. Thanks.
More densely populated GUI does not equal better productivity. I would argue that organization and readability are more important. Toolbar was improved with better organization - creating categories and bundling stuff together. It's already done with the Properties window, but it has too big categories still (mostly Render and Object), so the buttons must be dense, or they will be too long.
In this case I would consider this talk by Brecht - https://www.youtube.com/watch?v=ziPLNUfm7KA In there (4:09) he mentions how certain sections are occupying screen space, while being accessed rarely.
I would consider Render, Render Layers, Scene and World settings to be accessed less often than Object settings for instance. In this case it would be good to consider moving them out of the Properties, placing them under a single button invoking a popup, while simultaneously dividing Render settings into smaller categories, to remedy it's current bloat. Same with Object settings. This would also make Object properties the leftmost and main category (currently it is a bit lost among other, and has low discoverability).
No longer having such long categories would make it possible to rearrange the buttons to make them more readable, and avoid this kind of cramming - https://dl.dropboxusercontent.com/s/hm363wr0goo7yyy/shot_140903_104520.png?dl=0
I do not just say: a dense GUI is better.
I mean that a 1 column GUI will imply a very long list of buttons and values, located vertically, and as a result a lots a scrolling.
But as Brecht said and as you said, better organisation is the key.
In the previous release, lots of small changes has been made to the UI, lots of moves of small buttons and values.
In any case I remember, that greatly improved the UI (while keeping the 2 columns design).
The challenge is to find the good organisation of all that stuff. In your image, the Time Remapping is rarely used, but where can we move that ?
I agree with you about the Object Settings, because Render Layers, Scene and World settings are not accessed so much.
But not for the Render Settings: for instance, I use them more often than Object settings.
You can split panels into smaller ones. You will have to click more to open and close more panels to see them. It is an illusion to think that it is a lot different than scrolling. It will not solve my problem.
Actual panels represents a grouping that make sense.
Of course, Blender will continue to evolve and it is an obligation to periodically rethink organization by splitting panels, rethinking grouping and suppressing outdated options.
But I am talking about a basic thing to have a more clean organized UI.
It is to let one Properties Editor be able to display more panels at a time; instead of being forced to open 2 unsynchronized Properties Editors in the same screen .
You can be an illustrator and need display of render setting, materials, object settings, object data. Or you can be an animator and need display of armature and bones settings and physics.
There is no ideal organization. It depends of use. Splitting panels can make sense if we continue to group them by their action.
But trying to create a hierarchy between more used and less used options does not make sense for all uses.
Zooming out is not sufficient if we are stucked to one column.
There is a real need to display more settings while keeping actual panel grouping that have a readable sense.
I have no doubt that being able to split Properties Editor Tabs would help. I propose a visual one that does not require thinking work.
I am septical that a reorganization of settings grouping into more panels would be sufficient or pertinent.
Please use proper naming - a panel is for instance Dimensions, under a Render tab/category, in the Properties editor, and I haven't mentioned splitting panels at all.
You've got a point. I can see cases when a user needs constant access to the Render, World, Scene and Render Layers properties. In this case some Properties window categories need some splitting, just as you said, because they became a bit bloated.
Though I don't see a case where somebody's workflow would require constant access to the Display settings, as in the 3d View's Properties sidebar. A popup with settings, that doesn't cover the whole 3dView/is draggable, would work better there. But if there are such cases, please provide examples.
in my opinion....
http://i57.tinypic.com/2cxvjwz.jpg
Can we move this discussion to a seperate task? By which I mean any discussion that isn't about the flat style, and by 'we' I mean 'someone from the UI team' :D
I think some really good points are being made, and it'd be nice if there was an official task where these were the main course.
Done.
So, from now on, please post mockups and proposals that relate to the organization of the GUI here - https://developer.blender.org/T41700
In 2.5x original idea, 3d View's Properties sidebar should only contain Display settings.
But in practice, we know that it is not the case.
Transform panel, 3D Cursor panel,Transform Orientations Panel, Item Panel are not relative to display settings.
While modeling, if you do an intense use of crease or bevel edges; you need an access to Transform panel in edit mode to control fading of such effects.
While modeling with precision, you constantly verify measurements in Transform panel and adjust 3D Cursor Location.
You activate/deactivate length display.
While working with curves, you need access to same panel to control radius on several segments.
If you use Grease Pencil for modeling, you need an access to "Drawing settings" and "Convert" buttons.
Need to show/hide curves handles or normals is not a Viewport display user preference. It is something that you would need when working with curves or cleaning mesh for 3D printing.
With future split normals modifier, it would be more used for rendering.
While cleaning a mesh for 3D printing, you constantly switch Mesh Analysis display type to verify that a change did not alter what was OK.
While rigging, you have access to bone head, tail,radius, roll and enveloppe in Transform Panel in edit mode.
And when switching to Pose Mode, you have access to bone locks.
It is more efficient using this sidebar while rigging than being visual disturbed by Bone Tab changes in Properties Editor at mode switch.
Skeleton Sketching Panel is also an edit armature tool that is equal to use of grease pencil for modeling.
In some cases, a popup implies new shortcuts , new pies for what are actually checkboxes . In other cases like checking numerical values, a popup would be upsetting.
And in other cases, Panel represents a coherent grouping of actions and properties that make sense. And a splitting of this assembly would probably have none.
And some workflows could benefit to use two columns.
Do you find satisfying to have Slots Tab in same column that Brushes Tab while painting ?
Or was it better to have Texture Layer Manager addon in the other column ?
I'm not saying to move the panels you mentioned into such popup (Not the whole sidebar). Just the display settings - View, Display, Shading, Mesh Display, Background Images.
I actually don't like the idea of tools in the left sidebar, properties in the right one. Partially because it just doesn't work - we have a mix of properties/options and tools in both sidebars as a result. Possible solutions include:
I am sorry for my irrelevant previous post. I think it would work very well for Display, Mesh Display and Shading panels. I have more doubts about other panels that are containing values or name fields to set-up more than one at a time.
I am annoyed when I change a value and move mouse to type and then, have to recall popup to complete settings changes.
To set a view lens or view clipping , a action to confirm popup closing would be welcomed.
I think there are too many settings and buttons per background image to contain several of them in a popup that does not take too much space.
yes to more customization.
yes. But , IMO, it is something to limit to display panels.
yes. Floating panels would be appreciated for more frequently used panels. What panel is frequently used and what is not is a question of subjectivity ?
So, dockable ones is an answer that offers customizability.
isn't this discussion supposed to be happening in https://developer.blender.org/T41700 ?
anyway, I agree with moving display settings and some other properties to header popup's, but I think tabs in the properties panel would also resolve a lot of the mess. The nice thing about tabs is that the different modes could activate relevant tabs in the properties panel as well, so for instance in the texture paint mode, an additional "Paint Properties" tab could appear to make space for things like texture slots,brush palettes,as well as color palettes.
This would intuitive and more like a normal paint program, as well as a better workflow than squeezing everything (including properties) into the tool panel.
this way, the relevant properties would be displayed only when useful, but will disappear when not needed.
@WarrenBahler It is. Can someone move these past few comments there?
Added subscriber: @JosephPoole
Is there any way we could download this?
Like to test or anything?
@JosephPoole I think these are all still mockups
Ah well, guess we can't rush awesomeness.
Added subscriber: @natecraddock
Added subscriber: @t.ask
I think the current UI is quite good and flexible. Implementing all those UI elements is to much effort in one direction. Just making Embos globaly editable with alpha value would be a copmpromize without loosing current flexibility. It shouldn't be so difficult to implement and theme designers can then decide on flat or embos designs.
@t.ask : Don't forget this isn't blenderartists.org, this is an official UI design task that the UI team is discussing here for an issue that they feel is worth their time.
That we're allowed to join in is I think great, but I'd refrain from essentially saying it's wasted effort.
The emboss theme setting has already been branched off here #42228 and now we can focus on discussing updating the rest of the widget style in here.
@michaelknubben If an issue is worth the development time, and how much development time, is a legit debatable topic, and since @t.ask provided arguments along with his opinion, I see nothing wrong with his comment.
His comments, to my mind, read like 'I like what we have, and changing it would be too much effort'. Which I suppose as an opinion is fine, but it comes across as dismissive of the work done, after over a hundred posts in here.
Most of all, it doesn't help that the errors in the post make it seem like a minimum of time and effort was spent on it. Both Chrome and Firefox spellcheck by default.
I don't want to derail the conversation with this, mind. It was just an observation, carry on.
And don't forget that in this proposal there are some improvements that are actually not possible to make with theme, like the "important button", with this blue color, that improves a lot the readability.
@michaelknubben Whoo, wait wait... I didn't say "wasted time".. what I think is, that most of the current mockup goals can be reached by adding some UI editing properties:
Actually, I wrote a wall of text to explain more. Reading it now, I'm not certain that it's beneficial to post it.
Added subscriber: @laurasirco
Removed subscriber: @laurasirco
Added subscriber: @Terrance8d
If I may chip in my 2 cents here, I think that this design is a good design, with several flaws. Don't get me wrong, I'm open to change, unlike some other Blender users. First, the good parts:
And now, the bad.
I hope my opinion helps a little bit.
Added subscriber: @Takanu
Added subscriber: @Blendify
Wow this looks amazing. This could really change blender. I looks very new and looks like a lot of new software. If we do change the UI this much we should save it for a major release such as Blender 2.80. This is similar to the big change in Blender 2.50
Can I see a image of the node editor with some nodes and some links
Added subscriber: @MikePan
Added subscriber: @hirokamatsuiko
This comment was removed by @hirokamatsuiko
Hi @hirokamatsuiko.
What do you mean about the "Auto Collapse Fonction" ?
About the color highlight, if I understand well you want the to be user-defined ? (if true, that's fine)
IMHO it's a good idea, because quite often we use the same panel together, like Sampling, Volume Sampling, ...
That can make the panel somewhat more visual. And it's less annoying (in the sense too much attractive to the eye) than having the whole panel header colorized.
.
This comment was removed by @hirokamatsuiko
But there is actually something similar in Blender: If you Ctrl+Click (ok, that shortcut is not really well know), you will open a panel and close all others.
And you can close a panel really fast with the A key.
This comment was removed by @hirokamatsuiko
It's Ctrl + LMB.
I don't know what you mean about Zbrush, do you have an example ?
Maybe a option to switch betwenn the classical behavior and an "auto-toggle" behavior can be useful...
This comment was removed by @hirokamatsuiko
1° image:
I'm not sure to understand well what you mean.
But actually some add-ons let you add some menu without any python knowledge. About removing, I think it's not possible without changing the (python) source code.
And that's not that hard to do in python, there is enough tutorials for you ;-)
But it's off-topic.
No need of another Blender to do that, that the goal of the add-ons, to be (re)enabeled.
About the color highlight, I think it's better and easier (and faster) to have it directly on the panel (for exemple with a RMB, like for the tabs' pinning tool).
2° image:
About the cut of the properties header into 3*4 buttons, I think tere is no real need, the icons are there do to see the difference, and that will take a bit more space...
My first thought when I saw the drag-and-drop thing was: the icons are in a precise and logical order, no need to change that.
But maybe some people may need to change that.
But as you will always see all the icons, I can't see any interest. Can you explain it to me ?
Apart from that, is anyone tried to benchmark the time needed to draw the UI with and without any emboss, shadow (and so on), as some kind of performance comparison between "flat" and shaded theme ?
It can be interesting to know if there is a realgain.
This comment was removed by @hirokamatsuiko
Warning: this task suffers scope-creep
If you want to discuss larger changes for how to improve the UI/layout, we should probably have a separate task for that.
This is becoming a "discuss everything UI" task, which covers too broad an area, me (and probably other UI devs) don't have time to go over every suggestion, so this becomes another endless thread of discussion where nothing happens.
Suggest if any dev has time to work on larger UI changes, they start a new task for that, otherwise we restrict this thread to discuss basic style changes. (at least within the scope of the original task)
Changed status from 'Open' to: 'Archived'
Closing this task,
If a developer is actually going to work on it, we can re-open.
For now @billrey is not active or responding to design comments, and developers are not responding to feedback.
The discussion is going off topic - this is not really helping our design process and its more like a long forum thread.
Bottom line, if someone is able to work on this task, they can re-open.
Removed subscribers: @NGMAT, @ThomasDinges, @RainerTrummer, @JonathanWilliamson, @BartekMoniewski, @PawelLyczkowski-1, @WarrenBahler, @jta, @ionarn, @tychota, @marcog, @JoseMariaRichardsonRebellodeAndrade, @NicholasBenge, @karja, @jonim8or, @lsscpp, @michaelknubben, @Januz, @bat3a, @leandro_cavalheiro, @MikhailRachinskiy, @JulianEisel, @mont29, @Genome36, @YorikvanHavre, @pablovazquez, @liquidape, @niewinny, @AditiaA.Pratama, @gandalf3, @manuelmuzzurru, @Lapineige, @Wildlux, @zeauro, @Baron_Von_Ledger, @JosephPoole, @natecraddock, @t.ask, @Terrance8d, @Takanu, @Blendify, @MikePan, @hirokamatsuiko
Added subscriber: @michaelknubben
I agree, but I'd suggest moderation as an alternative to a warning.
Hirokamatsuiko is just using this as a place for his (unrelated) feature requests, so in the interest of readability you might consider deleting his posts.
This isn't an open forum, so I think we can place higher demands on what's accepted and what isn't.
@michaelknubben, If a developer was actively working on this or at least planning to work on it and responding to feedback, this could stay open.
Archiving is simply stating that this topic is on-hold unless someone plans to work on it.
I understand, I was only suggesting we'd clean this up.
I think everything that's been written here in 2015 could be deleted without losing much of value, and the reason I suggest it is that I think it would actually make this a clearer read for when this gets picked up again in the future.
edit: and by 'we', I mean 'someone with more power than me' :D
Added subscriber: @hirokamatsuiko
my sincere apologies
im just confused where to place and did not read before i just found about wiki where people send ui proposals
again sorry for being off topic