[UI Proposal / discussion] Drag and drop area management

[Arjo]

Tabbed interface design + mockups

This is also in reply to @billrey, and somewhat @Hto_ya

I get that there needs to be a big design discussion for revamping the area management and that there are other priorities right now, so I’m not sure if it’s a good idea to continue this discussion at this moment, but seeing a positive view on tabbed areas does motivate me to create additional designs.

With tabbed areas it would be interesting to look into what implications it has for the workspaces in the top bar. I personally use the workspaces for switching between modelling, UV editing, shading, compositing and scripting and I don’t experience any slowdown or need for rearranging areas. That’s why in the initial post I stated that adding tabs didn’t seem like a necessity.

However, being invested now, I identified some options to better understand how this functionality could be implemented in Blender:

Mockup

The goal of this mockup is to give an initial idea of what this functionality could look like in its entirety. With that in place, it is easier to form an opinion about the options I describe after this.

Appearance and functionality of selected tab

The first thing is the appearance and functionality of the active tab. I identified the following options:

(In these options, clicking the downwards facing arrow would open the Editor type switch panel / drop down menu)

1. Icon, name, dropdown:
   

2. Icon, name:
   

3. Icon, dropdown
   

4. Icon:
   

5. Name, dropdown
   

6. Name
   

With the addition of a tab row above the header row of an editor, the full name could be beneficial, because someone can refer to a specific editor by its name instead of its icon or position, for example in the context of a tutorial or when helping someone else out.

Right clicking on the tab, outside of the downwards facing arrow, would invoke the header context menu. This menu can be extended with tab specific functionality as “Close tab”

Appearance and functionality of an inactive tab

The obvious: The colour gets toned down to indicate that this is in fact an inactive tab.

To stop tabs from jumping around - which is unwanted behaviour - the width of an inactive tab should be the same as when it is active. However, reducing the amount of visual elements could be wanted. I identified the following options:

Show:

1. icon, name, dropdown
   
2. icon, name
   
3. name or icon (depending on the aforementioned active tab options), dropdown
   
4. only name or icon
   

What to do with an area that has only one tab

An issue that is being raised is that when there is only one editor in one area, there is unused space in this tab bar. It is proposed that the tab could then be collapsed back into the header, to make optimal use of space.

I do think this is a valid option. However, there are some arguments to be made against it:

• It would lower the discoverability of the functionality of tabs.
• It would reduce the consistency and clear hierarchy that having this tab bar everywhere creates.
• It would remove the name of the editor type (e.g. 3D Viewport, Shader Editor), which could be something the user is searching for.
• If a button is implemented for adding tabs (which I will discuss in a bit), this would either also have to be removed, or be integrated in the header of the editor which doesn’t look right - in my opinion:
  
  

Background colour of tabbed area

One important aspect to note is how the tabbed area shows that it is a container for editors. In my earlier shown mockup, this is dealt with by having a background colour for the tab bar:

Also note the straight upper corners of the editor.

Add button

Lastly, how does the user create new tabs?

1. Implement a menu entry “Add Editor” in the top-bar menu “Window”, which has the full list of available editors as submenu entries.
2. Implement this same menu entry “Add Editor” (but then named “Add Tab”, maybe?) in the context menu when right clicking the tab bar.
3. Have an add button (visible in the mockup) in the row of tabs.

The behaviour of when editors are dragged around or created can still be along the lines I originally proposed. This behaviour of draggable editors is, as mentioned before in line with other software packages.

Thank you for taking the time to read and comment on this post , I’m having a lot of fun thinking about this topic and creating mockups.

Some more mockups:

Could maybe give some more context to the earlier mentioned options:

With dropdown:

Without add button:

[megalomaniak]

@Arjo

It would lower the discoverability of the functionality of tabs.

The whole header could be acting as the tab in single area in tile situation. Only additional ‘tab’ in that situation would be the + icon at the very right to add a new area/tab.

Aaand scrolling down I see you have added an image example of just that…

Except I’d have the + be decorated as a tab similar to the workspace tabs at the top.

@Arjo

It would remove the name of the editor type (e.g. 3D Viewport, Shader Editor), which could be something the user is searching for.

It doesn’t have to. The editor selector could just always render/include the name. At least by default.

[slinkous]

I’d suggest anywhere in the header as the dragging area, but with middle click instead of left click.

[Hadriscus]

As it’s not something I do very frequently, I think I’d be fine using the smaller “grip” button on the far end, so as to avoid accidental editor-drags and keep that sweet “dropdown-drag-select” functionality. It’s also visually consistent with how the panels (and now the modifiers) are presented…
I love the tabs and I think they could be kept in the header, unless that means too much scrolling if not every widget fits because of them.

[silex]

I second that. Having two or more different dragging behaviours would be confusing.
Integration behaviour with similar UI visual item will help with function identification and ease learning curve for new users a little bit.

[anon13094437]

Arjo, your Tabbed interface design + mockups and propositions are really great, Thank you so much for your time.

It’s nice to read that William and Julian are already planning the right things for the near future too!

I can’t wait for when the UI becomes overlapping with tabs and with a conventional manipulation system.

PS: you were wondering if the tabbed UI would make the top tabs you like obsolete, I would say no:
the top workspace and tabs are not conflicting concepts, you can keep them as UI layout presets and have an optimized overlapped UI as well, It just multiplies the possibilities instead of fixing a flaw then.

[lone_noel]

@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

I don’t think it’s that much of an issue. Currently (2.83) blender only allows for joining within rows and colums that were split from each other.

Going by that logic, closing (perhaps rather collapsing) an editor could simply enlarge all the remaining editors within the respective row/column to fill the empty space while keeping their relative size to each other the same.
That behaviour would be pretty general and also distinct enough from the join operators to make it a nice addition to the editor management by itself.

I hope this illustrates my point:

I don’t know wether that solves the complications from a code perspective, but from a user perspective at least closing would always give predictable results without the need of further input.

I’m also loving those tabbed editor mockups, @Arjo. As someone who often works from a 13" laptop this would help me organize my workspace more efficient, though I can also see myself cursing the tab row now and then for taking up more precious vertical space.

[Alberto]

It’s and old mockup from 2.79/CodeQuest era, but also could be good remember… Basically

• reduce the editor button to a single gear, less confuse for new users and reduce noise
• allow to lock interface, hidding completely the control
• Change workspace tabs to top to not confuse with editors tabs

Without lock interface

With lock interface

(It’s an old mockup with other concepts from here Interface proposal for blender2.8 from a user's point of view)

[Shwaky]

I am against the tabbed interface it wont solve all the User Interface problems but bring its own challenges

@Arjo

Tabbed interface design + mockups

UI design for software such as After effects that use tabbed interface have their own challenges in User experience. some tabs get hidden and hard to find,
IMO we can try and improve the UX for Blender by fixing where the UI falls short but not to try and replace it with another design that will bring its owns challenges and inconvenience the current blender users on learning a new UI workflow.

[anon13094437]

That’s the advantage of the tabs: nobody forces you to use them.

If you can’t find yours panels because you don’t remember their position if tabbed, then don’t use multi tabs and stick to one per area as it is currently, and people who like overlapped UIs can use multiple tabs.

No need to be against something that is allowing everyone to be happy, including the people who don’t overlap their UIs.

Since there is no discussion about removing the top preset tabs, you will still be able to toggle between different mono tabs presets if you like, unlike AE.

[Hto_ya]

Again, those cases u show is not an issue in general

When I say we can’t just copy the design I mean, we need to find the way to deal with those

And after stop being annoying I thought maybe with “drag and drop” area from place to place we can determine the direction to close by drag dir
And thus for closing just add two butts “vert / horiz”