looks like we're running in circles here ;)
http://lists.blender.org/pipermail/bf-blender-cvs/2011-January/033472.html

Another example:

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,

more exemples

@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.

@Tillmann Schütz (Ionarn) I think those would play very nicely with @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):

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):

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.

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.