[UI Proposal / discussion] Drag and drop area management

[Arjo]

I have been giving the age old usability issue of Blender a try: the management, splitting and joining of areas.

Because it is very easy to make an uninformed design, I actively try to avoid this by going down the hard route - diving deep into earlier discussions and reading about defined design paradigms and the inner workings of Blender. I’ll try to be as transparent as possible in my knowledge and research on the topic.

Current system

Non-overlapping user interface

The first thing I would like to point out is that having a non-overlapping user interface is ideal. The introduction of workspace tabs also - at least as far as I can tell - satisfies the need for changing editor types often. Having tabs for areas such as implemented in i3 (i3 - ArchWiki) or suggested in Tabs for interface areas and Right-Click Select — Blender Community thus doesn’t seem necessary.

Splitting and joining operations

While the current system for splitting or joining areas works from a technical standpoint, it doesn’t perform well in terms of usability:

• There is no clear communication to the user on how the system works, or that there even is a system in place. This is partially because of the lack of a visual indicator. In Blender 2.79 however, the corners did have those:
  
  In 2.83, the only visual indicator is the cursor changing to a cross:
  
  But even with visual indicators, there is no proper way to communicate the possible functionality of splitting and joining in such a small space.
• Even when the user has found out that the functionality exists, the fact that dragging a corner can perform two widely different tasks can result in this scenario:
  
  
  
  The difference between dragging corners inwards or outwards is very subtle, making it easy to accidentally perform the wrong operation.

The only way to truly understand how to use the functionality is to read the manual: Areas - Blender 4.2 Manual

Even as a relatively experienced Blender user I did the splitting and joining purely on intuition and preferably avoided it altogether.

List of users experiencing issues with splitting and joining:

The above mentioned issues are evident in user questions on different forums. Note that it’s not just absolute beginners having trouble with this.

• interface - How to close view windows? - Blender Stack Exchange
• How to remove added blender windows - Basics & Interface - Blender Artists Community
• https://www.reddit.com/r/blender/comments/37cipd/its_really_a_dumb_question_but_how_do_you_close/
• interface - How to close windows in 2.8? - Blender Stack Exchange
• Closing Split Screens - Basics & Interface - Blender Artists Community
• Closing panels in 2.8 - #5 by Piotr_Adamowicz - Blender Development Discussion - Blender Artists Community
• interface - How do I close unwanted windows? - Blender Stack Exchange
• interface - How to close/open a view panel - Blender Stack Exchange
• interface - split screens in 2.8 - Blender Stack Exchange

There are more instances but I think this serves the point. The main takeaway is that users have a certain action in mind (e.g. “I want a new area” or “I want to close this area”) and they don’t know or can’t be expected to know how to do it.

Relation to other developments

Given that this is a common problem, there is currently effort being put in making area management easier and more fluid:

Screen Operators

Close: 2020-06-22_19-52-44_Trim_Trim Swap: 321 Join: 12 Resize: Resize_additional if someone wants to see the code: https://developer.blender.org/D7993

The following development gets praise, but the issue of discoverability and communication isn’t taken into account.

Proposal

Rearranging areas by dragging

This takes inspiration from the recent development in rearrangement of the modifier stack: New modifier panel and list - #17 by julianeisel

Visual indicator

Adding a visual indicator for draggability to the header part of an area communicates to the user that the area is draggable:

Full window mockups

Size of draggable area inside header

(confusing naming with areas )

1. The most apparent option is to have only the visual indicator as the draggable area .
   

   

2. The actual draggable area of the header could be expanded to all empty space instead of just the visual indicator, making areas with less populated headers easier to drag around, while still providing a fallback for when a header is entirely filled.
   

   

3. Another option is to make buttons in the header area, or in Blender as a whole, only have a click event when the mouse button is released. Right now it invokes a click event on mouse press. That would make the entire header draggable, making it easy to rearrange the areas from any mouse position on the header. However, this would reduce speed of selecting from a drop-down menu or switching between a row of options (e.g. selection add, intersect…)
   

   

Behaviour and appearance during drag

But now comes the real question: how do the areas behave during drag and how does their appearance change? To facilitate this discussion, I identified the following options:

(note that in these mockups I didn’t add the drag indicators)

What happens to the old area position?

1. When the area gets lifted from its original position, this empty space could stay in place until the dragged area is placed.
   
   
2. The empty space could also be filled out immediately when the area gets dragged.
   
   

• Which area fills out the empty space is determined by the subdivision structure.
• To communicate which area fills out the empty space, animating from the initial to the final size of the area would help. This would also result in a decrease in jarringness.

How to communicate the new placement of the area while dragging

(For convenience sake, I use the second option for the old area position in the mockups)

1. The first option is to show a line where the area would be placed. The dragged area would then become transparent to not obstruct this line. This is the approach Adobe programs take.
   
   
   
   
   
2. The second option is to show the preview of the dragged area aligned to the edge of an area. The other areas stay in place - they don’t adapt yet to the new area placement. This is an approach that Unity takes. It could again show the line for increased clarity:
   
   
3. The third option is to have the dragged area actively push the other areas to their final position.
   This could be done instantly, but animations could again communicate the movement of areas better. However, this amount of animations for the user interface could become distracting after prolonged use. The goal is not to create eye candy, but something functional, usable and easily understandable - something that stays out of the way.
   
   
   
   In this third option, it might be a good idea to have the header of the dragged area change appearance. Even though with continuous motion it probably won’t be confusing, having the header change to a slightly lighter colour, or having a border around the window would increase the understanding that it’s an area that is being dragged.

Duplicating an area: an alternative to splitting

With the concept of dragging areas in place, creating a new area is can be implemented as follows:

The user performs the exact same action, but now with holding down the alt / option key on the keyboard. The original area will stay in place and the user is now dragging an exact copy of the duplicated area. Placing this new area is the same as in the method mentioned before.

Closing an area

Closing an area is an alternative to the concept of “joining areas”. It’s the approach that is used by - as far as I can tell - many creative software programs (e.g. Adobe programs, Unity). It also is more in line with the initial thought a user might have: “How do I get rid of this area?”

The easiest option is to add it to the header context menu:

It could also be done by differentiating between the Ctrl + Q shortcut and the Ctrl + W shortcut. Ctrl + Q could then be for quitting the program, and Ctrl + W for closing an area.

Argumentation

• The alt / option key + dragging is commonly used to create a copy of an object in programs as Photoshop, Illustrator, Adobe XD, Pages, macOS Calendar, macOS Preview
• It’s predictable. The difference between dragging a corner inwards and outwards is not evident without reading the manual, so it feels almost as if it chooses randomly whether to join or split. There is no difference in
• Draggability is in line with current developments to make Blender more user friendly, such as in the aforementioned post: New modifier panel and list - #17 by julianeisel
• This system still honours the UI paradigms of a non-overlapping user interface and subdivision structure. (User:ThatAsherGuy/UI Paradigms - Blender Developer Wiki)
• The system takes inspiration from other software, which allows for an increase in familiarity (“Close” entry in the header context menu)
• It can be implemented in increments, slowly building towards a more “intuitive” or discoverable area management system. For example: the so called low fruit would be implementing a “Close” entry in the header context menu.

Considerations

• When creating this proposal, because of its widespread-ness in other programs, I didn’t test the existence of alt / option + drag behaviour in Blender. It turns out that the alt / option key is currently not being used by Blender for this purpose, which makes adopting this idea of duplicating areas a bit more difficult. It could also indicate that this functionality of alt / option + dragging should be implemented in other parts of Blender as well - for example the 3D Viewport and Node Editor. On the other hand, alt is now used for selecting tools.
• To continue on the previous note, how can the functionality of alt / option + dragging be communicated towards users? Maybe by adding it as a tooltip? Or as a option in the header context menu, with the shortcut key “alt / option” displayed?
• Performance impact, especially when animating the area sizes to reduce abrupt changes.
• Feasibility, how much effort / rewriting does this take to implement?

Final thoughts

I hope this post can bring about an interesting discussion about the future of area management of Blender

[Howard_Trickey]

I too, even though a long-time Blender user, sometimes forget how to split and join windows. Thanks for your detailed work on mocks and options. They look pretty good to me. But I’m not sure how that helps me discover how to duplicate or delete a window. Is the “draggable area” indicator in a header really obvious to people as to what it means? Maybe, but I’m not sure. The bigger problem for me is that I’d have to remember some random key (Alt) that I have to combine with a mouse click in order to perform this operation. At least with the current system, I remember that I have to click-drag somewhere around the edges, and once I discover where, I have rediscovered how to do it. How might you indicate to users that they have to Alt-click?

[Arjo]

I edited my post to add the parts argumentation and considerations, which also address these concerns.

Communication of the functionality would mainly be done through familiarity.

Having the functionality of closing the area in the context menu is commonly used by other programs:

Visual Studio Code:

Unity:

The header can be treated the same way as a tab in other software, since tabs (for example in Unity and Photoshop) can also take up a space by their own. The expected behaviour from tabs is that you can move them around by dragging. This is implemented in every program that has a modular user interface - as far as I can tell.

As for discoverability of the alt / option + drag behaviour, that is a valid point. Because I am so used to having the functionality in other programs (as I mention in my edit), it didn’t come to mind that it isn’t used in Blender.
It could however be an indication that Blender could benefit from implementing this everywhere - in the 3D Viewport, Node Editor and Outliner for example. However, the alt key is used for other things, so this should be properly examined.

Another approach would be to add the options in the header context menu:

After creating this because of your comments, this feels like a step that could fairly easily be implemented in the current system. I think this might even fall under the UI Paper Cuts thread.

[johnsyed]

@Arjo In one word… just like krita… and i always wanted this kinda behaviour in blender.

[Harleya]

Love it! Although this is a long list of proposed improvements, there are a couple items that could be implemented separately from the rest so they might give you a nice start.

The idea of having an “area close” operator would come in handy now, and later with new ways of initiating it. So personally I would start there. Then add that, and those other options, to the header context menu. By the time you have done those two you’d be quite familiar with that area of code and can proceed to the some of the more complex things. That’s how I would approach anyway.

[megalomaniak]

Hmm, yes this proposal largely reflects my own views on this as well. What I as a user always envisioned blenders tile/area management to become in the future, essentially. I wish I could give the OP more likes.

One thought I’d like to offer though (and this criticism might apply to the draggable indicator of the modifiers too) is that the dotted pattern should only show up on cursor hover - indicating interactivity.

[smilebags]

Only showing up on hover severely hinders discoveravility. For sure it should change on hover, maybe to a more contrasty appearance, but I think it should always be visible otherwise people simply won’t know it is there.

[Arjo]

That’s a great idea! I cloned the Blender codebase and I’m now looking at how to properly contribute code (Process/Contributing Code - Blender Developer Wiki, Tools/CodeReview - Blender Developer Wiki and Login).

I do have programming experience, but that is mainly in the area of interactive experiences / games and web. Contributing to open source software is new to me, but I think this is a fun challenge and I’ll take a look how far I can take it

In the upcoming weeks I do have important deadlines, so I will have to start after that.

[Hto_ya]

The idea indeed looks pretty sweet. And it works perfectly in software like vs.

But can editors of software like vs be arranged in the way blender’s editors can be?
I think we can’t just copy the design because it will cause troubles.

For example, how user would close areas like area 5?

In order to close areas intuitively user must supply additional information besides just click on “close button”.

[julianeisel]

@billrey and I discussed this before and we’re both in favor of a tabbed interface that allows more conventional interaction. E.g. you could drag editors to different “tab-stacks” (areas), close areas by removing all tabs, pop-out or un-dock windows with drag actions etc.
Like this proposal points out, such a design doesn’t necessarily violate the non-overlapping principle - which is a strength of the Blender design in my view.

This is a very conventional way to manage windows, which I think wasn’t that common during 2.5 or was out of reach back then.
E.g. even Pixar’s Presto appears to have something like this:

(screenshot taken from this presentation)

There’s of course a big design discussion to be had before this becomes reality. And although I’d love to see this in Blender, I don’t think it’s something we can or should look into before the end of the 2.x series. Until then our focus should be on wrapping up the 2.8 project and making sure other module agendas don’t come to a halt due to usability questions.

[julianeisel]

@Harleya

The idea of having an “area close” operator would come in handy now, and later with new ways of initiating it. So personally I would start there. Then add that, and those other options, to the header context menu. By the time you have done those two you’d be quite familiar with that area of code and can proceed to the some of the more complex things. That’s how I would approach anyway.

Unfortunately the area closing is quite a bit trickier than it seems. I spent almost two full days on this during the Code Quest, but didn’t finish it because I couldn’t get some corner cases to work. I ended up with dozens and dozens of test files for different corner cases I found.
I don’t wanna discourage anyone from giving it a go, just don’t expect an easy ride ;/

[smilebags]

Agreed, this would be a huge improvement to the usability of windows/tabs in Blender. A lot of software follows this standard, and for good reason.

@Hto_ya

Do u have any ideas on how user would close areas like area 5 on the screenshot? because I don’t see any in your proposal.

Conceptually, I think one thing to remember is that regions can only exist in a line, either horizontal or vertical, so that grid there is not a problem at all. It will only ever collapse in the ‘line’ that it was created in.

[billrey]

The advantage of tabs, is that in many cases you can actually save a lot of space, in addition to the fact that they are easier to use. Often times you need quick access to several editors, but not necessary simultaneous access.

Currently, you might have a layout like so, with each editor being quite small and crammed together:

With tabbed editors, each editor can be much bigger:

When you also factor in the fact that tabs are much easier to use, and a standard concept that many users will already be familiar with, it’s overall just a better solution.

[jc4d]

Would be great to have tabbed editors.

[megalomaniak]

I suppose cursor changing to the hand grab one might do as well.

[Hto_ya]

In order to know how they will collapse I need to know how they were created? I don’t think this a good idea neither

[Hto_ya]

I’m not saying tabbed interface is bad.
Name of this topic is “Drag and drop area management”, and I’m saying that I’m not seeing how current blender UI system and that proposal will work together not only in special cases, and the author doesn’t supply.

[megalomaniak]

@billrey

The advantage of tabs, is that in many cases you can actually save a lot of space, in addition to the fact that they are easier to use.

Yes, however I’d only expect to see a tab in case two tiles are overlapping, otherwise the single tab is just wasting screen-space.

[Hto_ya]

Closing an area it’s just simple join, and with new join op it’s not a problem at all. Join in what direction? That is the problem

[megalomaniak]

Could give a quick modal for the user to indicate/select direction with a highlight included darkening any invalid tiles/directions.