Thursday, February 11, 2010

Vertical header

The Properties area of Blender 2.5 uses a really nice, flexible layout system for organizing all the options and controls within it. One of the nice things about it is that it adapts to the width of the area, so that if it is too narrow to display everything in two columns, it simply switches to one column.

The narrow UI causes an issue with the header though, which doesn't adapt, and simply hides the header items. This makes it hard to switch property areas when the view is narrow.

A nice way to solve this would be to introduce a vertical header. When the area is too small to effectively show all the header items horizontally, it can move to the side. Luckily, the new UI area system in Blender 2.5 does support this kind of organization.


  1. The buttons on the top (or on the side as you suggest) are basically tabs, why not make them look like tabs?

    A general tab gui widget would be useful for switching between different groups of properties which are related, but do not need to be seen at the same time. Kind of like how the draggable options boxes would merge together in 2.49. But better.

    Or It could be used for multiple window types in the same subdivided window area that can be easily switched between.

  2. This comment has been removed by the author.

  3. Great idea! here's another suggestion, group selection sensitive icons in the header:

  4. Ah, tabs. Yes, that's a possibility, though they tend to look more visually complex. The advantage is that it distinguishes them from settings. They are view level, not a property. The same goes for a few other controls, such as the Material/Texture/Both tabs in the texture preview.

    Gustav: I see where you are going with the grouping there, but I fear it would be more confusing than without. Those look like multiple sets of radio buttons, when they are in fact one. Also, the distinction between per-object settings and per-scene settings is really nonexistent in Blender. Everything is basically just a datablock: scene, world, object, mesh, material, texture etc.

  5. Glad to see you thinking about this. I think the lack of a vertical header has bothered me since 2.43.

  6. "[...]Everything is basically just a datablock: scene, world, object, mesh, material, texture etc. [...]"
    Yeah, but the World datablock has its own textures, doesn't it? The issue is that we have to press "World" button first and then "Texture" to edit Worls's textures; otherwise under "Texture" tab there're last active Object's textures. Now that's confusing...

    Gustav's proposal solves the problem somehow, but I'd divide those buttons different way: [render, scene, world, object] [scene's/world's/object's linked datablocks' properties]. To avoid confusion that Willam's afraid of, maybe those buttons, or at least part of them should get real "tab" look but with clear hierarchy. For instance:

    1. header with Render, Scene, World and Object radio buttons;
    2. the window with tabs (under the header) for the rest of datablocks linked to those in the header

    1. header with Render, Scene, World and Object tabs
    2. some of those tabs (World, Object) contain the second row with tabs for linked datablocks' properties...

  7. Naaah...
    My proposal is a step back...
    This would lead us to repeating "World" and "Object" buttons the way we had in pre-2.5 Blender.

  8. a great idea, as long as blender doesn't try to choose for us.
    basically, four options, top, bottom, left, and right.

  9. jendrezych: The workflow for texturing is confusing in Blender, I agree.

    In the short term I think adding back simple tabs in the texture properties for world/material/brush would be better than what we have now.

    On the longer term though, I think it will continue to be confusing as long as we use the same old texture stack concept. The texture stack is pretty stupid because:

    *Not all values are available for texture influencing
    *The textures add on top of the parameters instead of replacing them
    *it's indirect. You have to remember the value and then go to textures to set it
    *It's really hard to do advanced stuff like masking
    *There's a lot of jumping back and forth between materials and textures

    So IMO the textures are quite a deep problem in Blender. Hopefully it can be tackled with the forthcoming shading refactor.

    The solution could involve using nodes at a more fundamental level compared to the current system, with some nice presets or UI layer that still makes it fast to set up. Needs thought.

  10. ton can make this in minutes...? : )

  11. That's good idea about vertical header. Then empty space beneath (or above) the header icons could
    be used for some custom buttons.

  12. Regarding suggestion about tabs, they should be included, at least as an option, so we can have more flexibility in building custom interface.

    I created a quick mocup of tabbed rendering functions.

    Render buttons are always visible and all other render functions and options are one click away

  13. I like this idea... alot. It's simple, functional, and fixes a "feature" that is currently annoying the $#!t out of me.

    If this were a slashdot democracy - I'd "+1 Innovative" :)

  14. Tabs work for me.

    When I first started playing around with Blender I found the Buttons window very confusing. I couldn't create a comfortable mental model of it.

    In Blender you could change any window into every other type of window and in the Buttons window there seemed conceptually to exist a second set of windows using an unrelated method for switching (the buttons).

  15. I like this proposal, and it certainly has some precident in Blender, as you can already move the header to the top or bottom. There would be some details to work out, though.

    A) What do you do for headers that include non-square items, like the pulldown menus that are in most headers? Turn them sideways? (Actually, I wouldn't mind that; of course, I would still expect the pull-downs to pop up a vertical menu.)

    B) How do you solve the problem of a window that is too narrow and too short to effectively show the header?

    Now, I'm very much in favour of this proposal, and I could see myself using it, but this second problem makes me question whether this is really a comprehensive solution to the problem you're trying to solve.

    A more comprehensive solution, I think, would be to allow variable-height headers that wrap when the window is too narrow. Then it would act much like the tabs (there's that word again) in a large property window. (For instance, if you open the Screen Resolution dialogue in Windows and press 'Advanced Settings', you'll probably see two rows of tabs.)

  16. -- and in the Buttons window there seemed conceptually to exist a second set of windows using an unrelated method for switching (the buttons). --

    Yes, and that's how Header buttons are functioning (it seems to me).
    I was more for a classical tabbed creation (and visually predictable) like in Blender 2.4.
    With all of the advantages that 2.5 UI has to offer.

  17. Rick Yorgason:

    This proposal was only intended for the Properties header. It's true that other headers sometimes also hide content when there's not enough space, and that going vertical doesn't really help in those cases, as you point out.

    Taller headers with wrapping content were actually implemented in an earlier version of 2.5, but it never seemed to work reliably. Perhaps something along those lines, implemented in a more robust way, would be a good general solution.

    The only issue this have for the Properties would be that it would need to break up the radio buttons into multiple rows which is potentially a little confusing and visually more noisy. Anything is better than just hiding the remaining items though ;)

  18. I'm pretty much in agreement with you; having two rows in the header would be slightly noisy, which is why it would be nice to have the option to switch to a vertical header in those cases :)

    I also see why your proposal was only intended for use with the properties header; I can't really think of any other window that would benefit from a vertical header. The primary benefit to making it work generally would be consistency; it would make the feature would be easier to document, and easier for the users to discover.

    Given the options of:

    a) allow the properties header to move to the side,
    b) allow the rest of the headers to move to the side, or
    c) allow headers to wrap,

    I'd prefer that all options were implemented. However, your proposal (a) would be the one I'd appreciate the most :)

  19. Please implement this ie. do it rather than talk about it.
    I requested this vertical header in the 2.5 dev thread at blenderartists ages ago.
    I would like it to be an option to be like this all the time not only for narrow width.
    Its much more mouse efficient to move from the 3d window across the header to the panels.
    Big Fan

  20. Maybe it would be more consistent to have something like this.

  21. 1.
    Nice ideia!
    Horizontal header used to work well with a horizontal panel like it was in 2.4x.
    But with when we have changed the panel orientation we should rethink about the header too. I like the vertical header, buttons look easier to switch from a mouse in the 3d viewport.

    I still thinking that the corner slashes could have a better design in headers and in the tabs they are useless because you can drag the tab from all its top corner.
    here is what I'm proposing:

    And finally I think we need to spend a bit more work in the tool shelf to improve it.
    All tools are displayed once but you need to scroll down to see the last tools and there is some tools that could be in the tool shelf maybe.
    Toolshelf could have more tools but each group displayed separately.
    Here is an example of this organization.
    It's Vectorworks interface.

    Anyway, the 2.5 is amazing! Great work.

  22. Glad to see you thinking about this. I think the lack of a vertical header has bothered me since 2.31a.

  23. Scrolling left/right icons, if icons hidden? Move mouse to right from over last icon scrolls the icons to the left and vica versa once the icons have initially been scrolled. A small triangle either end, initially just on the right, to indicate scrollability.

  24. You can scroll the icons with , this is counter-intuitive though, as one expects some kind of indication. Unfortunately repetition makes a UI seem so, which then forms part of a users personal intepretation of user-friendliness/ease-of-use and often leads to dissention amongst users of different OSs, instead of imperical study of number of clicks needed, mouse distance travelled etc.

  25. You can scroll the icons by hovering and mouse scroll wheel... Sorry inadvertent html markup!