UX meeting agenda July 20, 2016

[bgashler1]

Agenda:

TABS / OPEN EDITORS

• Closing dirty editor prompts for save (even when there are other duplicate editors open) Closing a dirty split editor (existing OR untitled) should not affect the initial editor #8983
• Debug toolbar in the way of tabs (move it?) Debug toolbar custom positioning #9093
• Quick Open preview, launched editors should stay open Show quick open results as preview while navigating through them #8939
• "Left, "right," "center" take up too much space? Need to validate this The “left” “right” “center” label in Open Editors take too much space #8961

OTHER

• San Fransisco font issues in Chromium (upstream problem affecting UX) Typography tune-up needed #9152
• Hard to place caret before first character when folding enabled. Hard to place caret before first character of line by mouse #8871

[bgashler1]

Please feel free to add items to discuss.

[kachkaev]

• Add support for opening multiple project folders in same window? Add support for opening multiple project folders in same window #396

[normalser]

• Provide an option to hide the activity bar Provide an option to hide the activity bar #1105
• Watch task indicator Watch task indicator #8513

[chrmarti]

• Git: status bar lacks indication that it will push Git: status bar lacks indication that it will push #8655

[bgashler1]

NOTES

Closing dirty editors prompts for save

We agree that we should no longer prompt users to save when they close a dirty editor if there is another duplicate editor still open. However, we will wait until the August milestone to get one last team member’s feedback before making the change.

Debug toolbar in the way of tabs

We could do a quick fix on this, but what we’re seeing is just one manifestation of a larger problem: our global commanding patterns need some work, as does our debugger UX. We will instead move to improve these overall experiences, which will in turn address this problem.

Quick Open preview, launched editors should stay open

We agreed that this is a compelling interaction need. We considered how competing products handle this, and we found that Visual Studio IDE handles it best. We will apply the relevant Quick Open interaction patterns:

• Quick Open will now create a preview editor (or leverage the already open one, if one exists) to show you a preview of each item you focus on in the list.
• Upon hitting Enter, the open editor will be kept open (i.e. no longer preview).
• If a user hits Esc or clicks away from the Quick Open command palette…
  • The command palette will close and whichever open editor you were on before previewing will be brought back in view.
  • The preview editor will remain and whatever you last were looking at in Quick Open will also remain inside that preview editor—exception: if you were on a preview editor when you opened Quick Open and previewed some items but never selected any (e.g. escaped out of it) then we will restore whatever you previously had open in that preview tab, since that would indicate that the preview tab is likely something you want to keep and not replace.

"Left, "right," "center" take up too much space?

We can experiment with using horizontal lines, but there would be a necessary tradeoff: we couldn’t have group actions in the Open Editors list.

We asked ourselves, “Should we even have the Open Editors list at all, if tabs are enabled?” Aren’t tabs sufficient to substitute for Open Editors? Some on our team are actually closing the Open Editors list to get it out of the way as they use tabs. We should validate if users would also fare better without them when tabs are enabled.

However, this is not a fix-all solution, because Open Editors are useful at least with tabs-disabled. And there’s another problem that needs addressing: As you open files from the Explorer viewlet, the Open Editors list grows (and this growing is magnified as you open files to the side in new groups, as 2 lines are added each time that happens: one for the file and one for its group label, such as “right”). This can be distracting and pushes the tree of files in your project down, which misaligns where you were previously with your cursor.

Possible solution for that: make Open Editors closed by default and/or allow it to be resized by users so that it stays fixed in its height and does not push things down.

Git: status bar lacks indication that it will push

We decided that first time users could be in for a nasty surprise if we don’t prompt them about what they are about to do by clicking on this for the first time.

The prompt could say “Sync will pull then push. Are you sure you want to sync?” followed by a “Sync” “Cancel” and with a checkmark that says “Don’t ask again.” Clicking the checkmark and continuing with a sync then would programmatically change the User Settings to never prompt again.

We will first run this by @joaomoreno

Watch task indicator

Showing when an ongoing task is both active and inactive is a great idea. @dbaeumer can handle this.

We also should holistically look at our tasks UX, as it could be improved. Or should we just rely on the integrated terminal and not have tasks?

OTHER

We unfortunately did not have time to discuss other issues during this meeting. We will address those separately or in a future meeting.

[joaomoreno]

+1 on the solution for the git status bar prompt. My idea is to implement it once we can programmatically change configurations (coming soon by @bpasero). The reason for that is that we already have a setting git.confirmSync, which we could leverage for the implementation... creating the chance for any user that clicked Don't ask again and regretted it to go to his settings and enable that confirmation dialog again.