Vscode: Windows: the X to close an editor should be on the right

[bpasero]

It is natural on Windows to have the X affordance to the right of the document and not to the left. This applies for both tabs enabled or disabled.

However, we should not just put the X to the right of the file label if you have tabs disabled because that means having an unstable location of the close button depending on the size of the file path. Instead, we should move this action to the far right, but clearly inside the tab and not outside. See https://github.com/Microsoft/vscode/issues/7060 for a related issue.

/cc @alexandrudima

[stevencl]

We discussed at the UX meeting today and agreed that we would refine the button layout like so:

Brad will tidy up the mockups I created and copy them up to the deck with our visual designs.

[bgashler1]

With Tabs

Tabs disabled

[joaomoreno]

• How does it look when just one or two tabs are open? Do they stay that size, or do they grow?
• How does it look when the view is split?
• The second screenshot shows a very tiny src below the active tab, is that a glitch? How will we should the path of the file?
• In the no-tabs design, the actions to the right look broken, almost to the point of screen cheese. If the user explicitly disables tabs, why not simply remove that notion and just put the x button all the way to the far end of the actions and remove the lighter (darker, in light theme) grey background colour?

[bpasero]

How does it look when just one or two tabs are open? Do they stay that size, or do they grow?

We think that we want to keep all tabs the same width up to a maximum width but we would not let them span the entire width even if it is free. For example, if the max width is 200px and all tabs are smaller than 200px, we just use that. If one tab is larger, it gets the extra size and takes it away from the other tabs if possible. We would still try to keep all other tabs equal width if possible. We think that we do not want to crop the tab title (name of the file) at all, so once a tab title is cropped, it pushes other tabs out of the view. That way you do not end up with tiny cropped tabs that are hard to use and in most cases all tabs should show up with equal width.

How does it look when the view is split?

Every group has its own concept of tabs and actions, so a split duplicates the little action area where you see the "...", split action and stacks action.

The second screenshot shows a very tiny src below the active tab, is that a glitch? How will we should the path of the file?

I would not put the path of the file below the tab because there is likely not enough space if we keep the title height of the editor part.

In the no-tabs design, the actions to the right look broken, almost to the point of screen cheese. If the user explicitly disables tabs, why not simply remove that notion and just put the x button all the way to the far end of the actions and remove the lighter (darker, in light theme) grey background colour?

We want to try this design to emphasize the fact that there are actions targeting the currently active editor and actions that target the group. Having all of the actions mix together is not very intuitive. So we would like to try a design where this becomes clearer. I would try it out to see how bad the experience is and then continue the discussion. If the background color looks like screen cheese we can also just try to put a separator between editor actions and the group actions.

[alexdima]

Please excuse my horrible Paint skills. IMHO the icon with the 3 files (that is currently the seargent icon ) should not be an icon, but should be painted custom. I also think no other actions should be in that area except the "seargent" icon. e.g.:

The idea is that the area to the right of the single tab or multi-tab is a fully clickable area, it is not an icon, but it is somehow painted to show the idea that there are other tabs under/not visible. I certainly fail at drawing this, shadows and co would help, but does it make sense?

When you would hover over that area it would light up somehow to indicate that it is clickable and that it allows you to go to the other tabs behind/not visible.

As for the actions, IMHO they should either go away entirely (I haven't seen a tab UI that includes actions in the tabs!) or go to the left of the 'x'. But if we do tabs, IMHO the area to the right contains just the tabs and not a mix of some actions + some tab management actions (and yes split editors should not be there! - maybe that is solved by drag & drop a tab towards the right of the screen creates a new side or something - goes from 1 to 2 vertical things)

[joaomoreno]

Every group has its own concept of tabs and actions, so a split duplicates the little action area where you see the "...", split action and stacks action.

Space's going to be pretty tight once we start duplicating that three-action box.

The second screenshot shows a very tiny src below the active tab, is that a glitch? How will we should the path of the file?

I would not put the path of the file below the tab because there is likely not enough space if we keep the title height of the editor part.

Meaning: it will not be put anywhere?

I would try it out to see how bad the experience is and then continue the discussion. If the background color looks like screen cheese we can also just try to put a separator between editor actions and the group actions.

The experience isn't going to be bad: the actions are useful and visible; it just doesn't look good. A separator would fix it perfectly.

[bpasero]

@alexandrudima I am not sure why you are so opposed to putting actions into the area to the right of the tab-group. I think we can add actions there as long as they are for group management. The only actions in there are moving groups around, closing all in the group and we argue that the split action is important enough that it should be there as well. I think we can copy from other tab UIs but we can also evolve the UI to be better.

To give an example, Eclipse uses tabs and also decided to use the space to the right for actions:

I find this a very good use of space in that otherwise empty area.

@joaomoreno we will not show the path when you enable tabs but you can see the path on hover. When disabling tabs we show the path as today.