close icon on terminal/console/etc. pane should be "x"

[chrisdias]

The terminal, debug output, console, etc. panes at the bottom have a small down arrow for the action to close or hide the pane. clicking on this makes the pane slide down and disappear.

The down arrow to me suggests that the window will be collapsed down rather than closed. Whenever I click on this I expect there to be an action at the bottom of the editor to restore the pane. Instead I have to use the keyboard or menu to bring these back.

As a result, a better icon for this pane would be the close "x".

Alternatively, there should be a visualization at the bottom of the editor that there is a pane that can be restored.

[stevencl]

There's another item open to suggest a tabbed UI to switch between panels - #9659. We should consider if we want to tidy this up all in one go.

[gertcuykens]

I think the logic behind the down arrow is because you can open it again using the symbols at the bottom. Once all consoles have there own symbol at the bottom the down arrow would make more sense then the x symbol.

[stevencl]

@bgashler1 will work on designs for this.

[Tyriar]

The down arrow to me suggests that the window will be collapsed down rather than closed.

The panel is being collapsed down rather than closed as the state of the panels stays the same. The trigger for this change was that the x icon was ambiguous as to whether it kills the integrated terminal process or not.

[bgashler1]

We are leaning towards this design. It keeps the the commands to add/remove terminals in the context of where they are added/removed. It also avoids making the "x" appear to terminate a process; it now is more clear it's just closing the UI panel.

But we need to to investigate how doable it is implementation-wise, as @isidorn suggested (since these are native boxes). Also, how would this affect renaming terminals (and should renaming be allowed)?

[Tyriar]

@bgashler1 My experience with styling native drop downs is to avoid doing it and prefer a custom solution instead (which often has a11y implications).

I personally think that is less clear than it is currently. Why is x better than v? For editors x means close and get rid of all unsaved changes but that's the opposite message we want to get across for the panel (it will not clear output and will not delete active processes)? Other places that use x on the UI are also fairly destructive:

• Delete a watch expression
• Remove a file from the search (you need to rerun the search to restore it)

[stevencl]

To make this work like a proper hide/show action (this is at the root of the issue that @chrisdias has raised) we would need to make sure that there is an affordance in the status bar that does the reverse of the hide action (clicking the 'v').

Since our goal is that the status bar is the place where the user looks for ambient information about the workspace we would not simply add a control to the status bar to show the horizontal panel. We would need to have some kind of ambient information that the user could read and then choose to open the panel based on what they read.

Right now we have a half way house where we show the number of errors and warnings on the status bar, in the bottom left hand corner. Clicking on this shows the problems panel. So we can sort of hide the horizontal panel and bring it back from the status bar but the two actions are very disconnected.

@bgashler1 and I spoke at some length about this just now and want to explore a design where we reserve space on the status bar, where we can show ambient information regarding each of the content providers in the horizontal panel. When the user clicks on any of these indicators in the status bar the horizontal panel is shown, and the indicators are removed from the status bar. When the user then collapses the panel, the indicators return to the status bar.

We will need to work out what ambient information can be shown for each content provider in the horizontal panel and what we do when there is an absence of such information.

Effectively we are trying to design an experience that is not too dissimilar to the way that the sidebar works (it's just horizontal, instead of vertical) but without the overhead of a full horizontal app bar.

[isidorn]

Let's make a decission about this at today's ux meeting?

[bpasero]