Panels Redesign
Open, NormalPublic

Description

Creation approved by Jonathan Williamson

Blender has a flexible panel system that allows for quick rearrangement of the UI.

Problems

Any flexible system has its problems, and Blender is no exception

  • Design does not promote its features
    • Header functions to minimize, not drag
    • Dragging is controlled by a small widget
  • Panels aren't distinctly separated from background
    • Panels blend into each other as well as the background
  • Despite underlying organization, seems disorganized

Positives

  • Very uncluttered
  • Sleek appearance
  • Simple

Proposal

Hopefully combine the best of both worlds

  1. Draw the panels with a header and body background by default, rather than a divider
    • Keep the current default as an option (just not the default option), for older users who like it the way it is
  2. Increase the drag area to the nearly all of the header (minus the collapse icon, of course)

Working Concept

Diff (widget-on-enter code from @Julian Eisel (Severin)):


Theme (to make the panels pop!):

Goals

  • Maintain the uncluttered aspect of the original panels
  • Improve drag functionality and clarity
  • Design an aesthetically 'clean' interface
  • Put Blender's Interface a step in the right direction!

Examples

Most of these have well-defined headers and body sections, so It seems apparent it is the way to go.
Some were pulled from my last patch comments, so I don't know if they're the artists dream situation, just examples...

@Paweł Łyczkowski (plyczkowski)

@Pablo Vazquez (venomgfx)

@Antony Riakiotakis (psy-fi)

@Blake Stacks (blakenator)

(current attached diff/xml theme)

Thanks to @Julian Eisel (Severin) for the code help for the diff!

Details

Type
Design

Another example:

This uses a bit of a different approach but integrates nicely into the rest of Blender's GUI.

The drag area vs the panel open/close area

I think best would be to leave most space of the panel header for the open/close interaction as this is a much more common operation than reordering panels. However we could still increase the size of the drag area a bit and add a mouse hover feedback to the icons.


@Blake Stacks (blakenator), btw you don't need to add a xml-theme, you can also change theme values in init_userdef_do_versions(void) (source/blender/editors/interface/resources.c), which is another inevitable file for UI coding

@Julian Eisel (Severin), how do you do the corner-rounding?

Here's an updated example diff,

, no xml now. I don't know if it's the right way to do it, but it's a stab.
Also, the collapsing is a more used part of the ui, but I think the idea behind the panels should be more focused on their singularity and portability. Their portability is more difficult to emphasize in other ways than the clear triangle icon of the collapse functionality. I do agree that the minimize area should be increased, but of how much I am not sure.

@Albert (wevon) I think unless the whole UI team agrees, we should keep the blender style, but your concept would be cool looking!

Here's the updated prototype:

IMO it still seems a bit cluttered. Anyone have any ideas? Even bad ideas are better than no ideas!

I have an idea. How about dividing the header between the collapse icon and the text? While I'm not too fond of the cluttering effect, it would delineate the different functions much better than what we have currently.

Accidentally pushed post too early :P
Here's a mockup:

Or maybe conversely with the drag icon...

Personally, I prefer the previous version

Just a suggestion for all of these mockups. Try to simplify the panel down to it's bare components and determine precisely how it works, what does what, and so on before ever touching the actual design. It's very easy to get caught up in UI design and forget about the key functionality :)

In this case, before a design can be finalized, we need solid proposals for how the panel functionality changes (if at all), particularly with regards to the open/close arrow, the header, and the drag widget.

A good practice in UI design is to explicitly keep all design out of it until the functionality is determined. This is where you'll see a lot of professional UI designers only working in pen and pencil for the first stages. When polished design elements are added we often become biased towards or against the design and can longer evaluate the functionality well.

Hey,

I just want to throw in some ideas for the general design we could think about.
My main idea is to better distinguish the panels from each other and to simplify the the whole interface like shown in design proposals from other users.

I would like to hear some opinions of you. Maybe some ideas can be merged or some other ideas develop during discussions.

Bright version

Dark version

@Tillmann Schütz (Ionarn) I think those would play very nicely with @Pablo Vazquez (venomgfx)'s widget redesign, but IMO it still needs some indicator that it can be dragged. I have taken the last week to think about this issue, and have come up with this idea (many similarities to yours):


And some not pinned:

(Pay no attention to the colors in the mockup, those are just for emphasis)

Notes:
  • This design places the functions by most used (most used function first):
    1. Collapsing (whose click area extends to the end of the text)
    2. Dragging
    3. Pinning
  • The dot on the right would be the pin area (should still have the pin icon, not a circle, when pinned, this is just a pre-vis).
  • Pinning should be more thoroughly implemented in the UI to provide
    • improved consistency in the interface
    • improved functionality
  • The drag widget would hide when the mouse is not in the header

What do you think?

@Tillmann Schütz (Ionarn) , I really like the clean look of your mockup, but @Jonathan Williamson (carter2422) has requested that design specific discussion be kept for later; could be as part of T38037

@Blake Stacks (blakenator) , some thoughts on your suggestions:
I'm not sure about the drag area following the text for two reasons:

  1. the text can actually run off the area border when the panels are in a narrow format- thus leaving no drag area

2.the drag-able area would change from panel to panel, making it confusing when rearranging multiple panels.I would rather just see a consistent drag area- perhaps the two areas could be assigned by dynamic percentage(like 60% toggle / 40 percent drag).

Also there was a pretty strong consensus against adding the pin icon to the toolbar panels, mainly for the reason that the amount of use it gets doesn't justify the clutter it brings to the interface.It ended up in the drop down menu , which I think is a good compromise.

@Warren Bahler (russcript), now that you've said that, I agree that the pin icons take up excess space, but they should still be implemented similarly across all panels.
Also, the percentage would still lead to an overflow issue when the region is too small in the same circumstance as before. We could clamp the width of the drag panel to a minimum though, and that would lead to a never-disappearing interface...

Also, the percentage would still lead to an overflow issue when the region is too small

not if it scaled dynamically with the exposed panel width - I have no idea if this is possible though

also I'm not sure what a pinning a panel does in a normal (non tabbed)context like the properties editor; stay on top?

the right click menu could be utilized to expose some other "hidden" commands as well, like "Collapse all ", and "Expand all": currently except in the toolbar its just an empty menu.

@Warren Bahler (russcript), what do you think about just adding a minimum size, because even with the percentage (which can easily be done btw), we can have extreme situations where you end up with just one or two dots.

We could make the dots align to the right of the panel and go left, with the width dynamically changing with a set minimum like this (blue highlighted one):


My concern with this design is that it is off balance in the sense of having a large icon on the left and none on the right; we are an art program, so we should still follow the rules of art. :P

Also, in essence, the properties panel already has tabs, they just look different.To answer you question: yes, panels would stay on top.

Wow, again I pushed submit too early...
@Warren Bahler (russcript) I do agree with your 'hidden' functions statement though.

Now I see what you mean,what I had in mind was just a static sized widget which would overlay the text when necessary, like in the example; but would represent the larger drag area. exactly like the toggle icon represents the entire toggle area.This keeps things cleaner, but there would be no visual division between the two target areas.

I just realized this: any indicator splitting the panel header would have run-off problems if the text overlaps the drag area; how would you separate two overlapping areas?

Maybe the solution lies in truncating the text with ellipsis...

The text would already be unreadable after a certain point, and this is pretty much the standard in other applications anyway, so this way we could keep a constant spacing between the drag area and collapse area.


If we do it right, the space itself could be the divisor. Or, on the mouse entering the header, we could highlight the drag area slightly:

I personally like the combination better, and if we take the middle (mean, average) color between the header and body, we could get just the right amount of emphasis.

Personally I think the text really shouldn't have anything to do with the functionality, it's just a label. The respective drag and toggle areas should be independent of text, because of the obvious reasons that you just pointed out - the areas would change size depending on the length of the text.

I think a simple right aligned widget like in the task example is the cleanest and simplest way to communicate the drag area, but increasing the area some would make it easier to grab.