UX meeting agenda 3 August 2016

[stevencl]

Agenda for tomorrow

• Closing dirty split editor: Closing a dirty split editor (existing OR untitled) should not affect the initial editor #8983
• How to show errors in the editor: How to show errors in the editor #9062
• Opening arbitrary commits in diff viewer: PR Proposal: Open arbitrary commits with diff viewer #9871
• UI for replace all: Replace All button should have a different UI #9887
• Files with the same name: Cannot distinguish different files with the same path.filename(x) #8499

@Microsoft/vscode - let me know if you want to join the meeting tomorrow.

@sandy081, @joaomoreno - we hope to discuss a couple of issues that have been assigned to you.

[bgashler1]

We should also discuss designs created for the following items last week...
Merge all 5 vscode panels into 1 #9659
Close icon on terminal/console/etc. pane should be "x": #9638

[chrisdias]

this is a big list! can we prioritize by what we think we can tackle in Aug milestone and move the rest out for a later discussion?

[stevencl]

The full list of UX items in the August milestone is even bigger: https://github.com/Microsoft/vscode/issues?q=is%3Aopen+label%3Aux+milestone%3A%22August+2016%22

This was my attempt at focusing just on the items I felt we had to discuss.

An alternative could be that we meet more than once to go through the complete list.

I think we could get through the above list (the original list, not the full list) in an hour if we manage the discussion, especially if everybody takes a look at the issues before the meeting.

[bgashler1]

NOTES

How to show errors in the editor: #9062
We will leverage the existing binary file error experience.

Opening arbitrary commits in diff viewer: #9871
We will look holistically at our source control experience to see what is missing, such as Git history. We don't want to stuff more things into an existing UI piece, if it would be better in an area we have not yet created.

Merge all 5 vscode panels into 1 #9659
Below is the design we were most interested in pursuing. It uses a different tab style to avoid users confusing it with editor tabs, which are not interchangeable.

We need to iterate on two more things: 1) How will we show notifications? 2) What is the maximum bounded width of the local command/inputs on the right for each panel so that it won't obscure the tabs or appear strange (biggest offender "Problems" input box)?

Close icon on terminal/console/etc. pane should be "x": #9638
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)?