UX meeting agenda July 5, 2016

[bgashler1]

Agenda:

TYPOGRAPHY / TEXT

• Goto menu title should be "Go to" Goto menu title should be "Go to" #8538
• CJK strings on the UI are very difficult to read on standard definition monitors due to font weight and size Several CJK strings on the UI are very difficult to read on standard definition monitors due to font weight and size #8653

TABS

• Tab dragging should show where the tab will be inserted, not which tab it will be "replacing" Tab dragging should show where the tab will be inserted, not which tab it will be "replacing" #8544
• Problems with theming tabs (solution: using CSS variables?) Explore to introduce CSS variables from themes and use in workbench #8151
• Showing local commands Local commands for editors need to be visible with Tabs enabled #8779 Editor actions are hard to discover when tabs are enabled #7666

@Microsoft/vscode please let me know if anyone else wants to come.

[isidorn]

• Panels should toggle focus between editor and panel just like other views Panels should toggle focus between editor and panel just like other views #7540

[bgashler1]

NOTES

CJK support

We need to let this issue sit longer with the community to see if our users are experiencing this problem the same way @Tyriar is. If we try @Tyriar’s suggestion, we’ll need feature flag that can be enabled/disabled in case it causes some problems. Something we could try right now: we could add an animated gif that shows people how to change this font size with dev tools (and a code block they can copy). They then can give us feedback and, if desired, share screenshots.

Tab drop visual feedback

We need to let this issue sit longer with the community. Wait for +1s for the two approaches we could make. We should do a mockup of dynamic sorting (browsers’ approach to tabs), and also of the vertical bar showing insert position (Atom’s approach). The advantage to doing one of these solutions is that we can more intuitively allow a user to move a tab to the left or right of a tab.

Tab colors issues

We need to switch tab colors to rgba due to anti-aliasing issues that could diminish the user experience on Windows for some users, since mix-blend-mode disables an important anti-aliasing feature in Chrome. @bgashler1 will make a PR and get it for the July milestone. (See below paragraph for a related issue).

CSS 4, SASS or CSS Custom Properties?

We’re not sure how long Chrome will take to support color-mod() in the CSS 4 spec, and we also must support other browsers for the stand-alone editor—therefore, we can’t rely on it at this time. SASS could be better, (because it would fix many other current problems, such as how verbose our CSS must be and simplifying the changing of colors/sizes across VS code consistently), but it does add another language to compile from. Or, should we go with CSS custom properties since they are dynamic, or both? We need to decide on improved styling technology not just based on tab colors but on all the issues that would be benefit from it.

Local commands should be visible with tabs-enabled

We agree that we must show local commands, to remove the “price for using tabs,” which is the problem of having to right click a tab each time to use these. We discussed a few designs @bgasherl1 made and brainstormed a couple more. One that made local commands appear in an editor widget seemed promising—but we need to address how we can show multiple widgets, such as find/replace and the local commands together (possibly through stacking?). We will wait until next UX sync to discuss, so that @alexandrudima can give his feedback.

Panels

We will discuss this in a later UX sync when @sandy081 can attend.

CC - @chrisdias and @Tyriar