Need better extension management UI

[joaomoreno]

The quick open UI isn't working fully well.

We need to come up with a better UI story that can

• increase visibility of extensions;
• fix awkward UI interactions we have today (status bar widget, error output pane, messages, etc);
• enable us to implement more features in the future (enablement/disablement, statistics, etc).

[joaomoreno]

Let me present what I call the Global Extensions Viewlet solution.

The idea is to use the sidebar area to manage your extensions.

• Similar to viewlets you can get into it by clicking an icon in the activity bar.
• Contrary to viewlets, this icon would be separated from the existing ones, indicating that it is a global concept instead of a workspace relative concept.
• The user can search and browse through several categories: All, Installed, Gallery, Outdated, etc.
• Clicking on an extension would show its details in a split view below the list. An optional Read more button could open the extension's README.md file in preview mode in an editor pane.
• Notifications would be displayed globally in the icon in the sidebar, similar to the existing viewlets.
• More detailed notifications would be displayed inline in each extension's row in the list and the detail view as well.

I like this because it is minimal, practical and solves many of the currently existing issues. It can also be implemented on top of our existing infrastructure.

The main concerns surrounding this is the breakage of the parent-child hierarchy we have with viewlets. You click a file in the parent Explorer view and it opens an editor in the child view. All viewlets work that way. The concern is that this solution would be confusing since clicking an extension would not open any editor view. IMO this can be solved by displaying this sidebar in a different style: render it with a different background color for example. This would provide the user some indication that this pane is somehow different and thus behaves differently.

[Tyriar]

Any reason in particular that the extension's README would not display in the editor view on click? There is a lot of good content/images in many extensions that will barely fix in the sidebar.

[daviwil]

Looks cool! Don't you already have an extension's README in its Marketplace metadata? Seems like you could just automatically show the README for any of the selected extensions, but maybe I'm missing something there.

[joaomoreno]

That would go into the same problem that we have for settings. Doing so would take an editor away, and you'd have to manually restore the state after you're done with extensions. It's sad that it happens with configuration settings today and we definitely don't want to go the same way with this.

[jrieken]

I'd go a step further and not allow editors or (debug) output windows while managing extensions (or for the future managing aspect of the product, like settings, keybinding etc.) My reasoning is that managing the product and coding (typing, searching, debugging) are two fundamentally different tasks that deserve separation.

Our workbench is optimised for the coding-task with the 3-level parent-child relationship between the sidebar, the viewlets, and editors.

For the managing-the-product-task I propose a simpler 2-level parent child relation between the sidebar and the rest of the workbench window (think of a combined viewlet-editor-area). It gives more space to build such UIs and most importantly being a separate thing it will not interfere with my editor-viewlet-arrangements. It could look like shown below.

The interaction would be like this:

1. The workbench is in default Coding-mode, the viewlet icons (Explorer, Search, Git, Debug) show at the top of the sidebar
2. At the bottom of the sidebar is a button to change into Management-mode
3. When selected the viewlet icons fold into one and move to the bottom, similar the management icons unfold and move to the top
4. The sidebar now allows me to switch between management-tasks, like Installing Extensions, Manage Updates, or Settings & Keybindings.
5. When the coding-button at the bottom of the sidebar is selected the product chances back into Coding-mode.

[daviwil]

+1, looks great! What tool are you guys using for these mockups?

[jrieken]

Credits to @joaomoreno for finding: https://moqups.com/

[stevencl]

I like the idea of having a higher level affordance that you can use to switch between coding and management. We might want to consider positioning the affordance at the top of the sidebar though for a couple of reasons:

1. In Monaco we found that many people overlooked the area at the bottom of the sidebar when looking for key functionality
2. Since conceptually the affordance is described and thought of as a parent of the coding and management 'modes' it seems to make sense to position it as a parent.

I don't have any firm ideas right now about what this might look like though.

Another thing we might consider too would be if we could allow the user to work with both views simultaneously, similar to how browser debugger tools can be snapped inside the browser or as a separate window. Doing so would allow the user to see the effects of changing any settings or installing an extension in the main coding window. Without this it could be a little laborious to switch to management mode, install an extension or change some setting , go back to coding mode, see if the extension or setting does what was expected, switch back to management mode, find another extension or setting, switch back to coding mode etc.

I know that this goes against the principle of not introducing any new UI but from a UX point of view I think this potentially provides a smoother workflow.

[Tyriar]

I liked Bracket's extensions UX, they have a button on the top-right which opens up a modal dialog with extension/theme search. Regardless of the direction we go, the presence of a button on the UI will make extensions much more convenient and accessible.

[bgashler1]

These are some excellent ideas. I think making management (settings, themes and extensions) as a mode of the product is a wise choice, because it would allow you to leave your editors all intact. It also gives us more real estate and a neater, more consistent place to render these views.

[bpasero]

+1 for having a UI that is not interfering with my coding workflow. for that we should make it very clear (in terms of UX) that the UI for managing extensions, settings, etc. is visually looking different from our workbench. my fear is that once you go into the management UX, it looks too similar to the actual coding UX. I am fine reusing the concepts of sidebar, viewlet and editor (which is really just a master-detail thing) but imho it should really have a look that you can separate the one from the other.

I like Johs design, but I wonder if this one should pop up as overlay over the workbench so that you can see it is somewhat modal or even be in a separate window to make clear that you are not interfering with the coding workflow.

[Lonefy]

if the extension itself has some settings, how about providing GUI and interfaces for these ext-settings :)

[seanmcbreen]

Joao and I chatted about this a little today. The key things I propose here are:

• I like the idea of editor windows vs modal or a pop-up (rationale below)
• First class action in nav bar (left side) I think is critical - this should also have indicators like git does e.g. green with 3 == 3 suggestions, red with 4 = 4 issues or updates (ignore my color choices :))
• Includes common metaphors for Installed, Recommended and Marketplace in a single pane of information - we could fit a lot in here but I also have expansions and I imply scroll bars as an option.
• Ability to scope and sort marketplace results - remove themes from results as an example.
• Ability to act from the list views if you know what you want e.g. install or update
• Demotion of license to the details view (I'm not sure it needs to be in list view but may be missing some context).

I do think my mock up is a little 'over designed' we don't need all those controls all over it. And it's something we could grow into vs. start with. It's also not nearly flat enough i.e. it would look out of place in VS Code right now. So think of it as components and a suggested direction.

I'm not too much in favor of a modal experience as I don't perceive any of the UI actions as blocking - so I'd love to leave the interaction mode free.

[bgashler1]

@seanmcbreen I'm not sure if modal was the right word to describe it. Modal tends to mean, like you said, blocking further interactivity until an action has been taken by a user. What I see this as is a management view, not a mode. For instance, you could go back and forth between Editing views (including Explorer, Git and Debug) and the Management view via the action bar on the left and pickup right where you left off on each without losing any of your context or activity in the views.

Utilizing a "view" approach would allow us to take up the full real estate of the window, which allows us to give richer experience at discovering and managing extensions. It also avoids editor management clutter by repurposing editors, as is used in Atom.

@stevencl what would you think of launching this management experience in a new window via Ctrl + Shift + N to do a side by side experience? People with two monitors could easily make changes this way. Or, perhaps this is a good opportunity for us to introduce the ability to tear off windows.

Also, @jrieken, I'm not sure I like replacing buttons in the activity bar, since it might be confusing where they went and it adds another level of interaction to get back to certain parts of the Editing views. Rather, I would suggest simply adding an additional action button, and making that action button take us to a view that takes the whole window as I've described earlier. Getting back to previous Editing views would then just be a click away,

[waderyan]

I agree with @stevencl. Can we discuss the relevant user scenarios?

Extension life cycle - User Stories

1. Discover extensibility - the user is aware that extensions are available and understands why they may want to install an extension.
2. Specific extension discovery - the user can discover a specific extension to aide their workflow.
3. Relevant extension discovery - the user is given a customized recommendation experience to find relevant extensions.
4. Shop for an extension - The user is able to compare and contrast extensions to determine which one to install.
5. Learn how to use an extension - The user is given the necessary education (onboarding) to know how to use an extension effectively.
6. Configure an extension - the user has easy access to change specific settings within an extension.
7. Maintain an extension - The user can maintain an extension, including being made aware when it is causing a performance lag or needs an update. Also, includes a communication channel with extension creators for bug / issue feedback.
8. Uninstall an extension - The user has a positive experience uninstalling an extension.

In my mind each part of the above life cycle is important and should be considered in the design. Do you think these are relevant and should be considered? What would you change? Is there any user scenario you would add?

Many of the UI mockups seem to be addressing these stories and I feel good about the direction we are going.

[iam3yal]

Personally I dislike the idea of having a UI management for extensions, I dislike it in Visual Studio and if anything I'd argue that this is nothing but annoyance!

Visual Studio has grown to be a stack of interfaces that I no longer use because I do everything in the command line much faster and I have a better experience with it than clicking on things.

I really hope that the Visual Studio team would realize one day that there should be one way to install extensions, install packages, install anything and it's the Package Manager Console! that's how I'd really like to do things.

Now, to Visual Studio Code what I'd really want to have is a Console that I can use to install extensions, install nuget packages, install npm packages or another kind of packages and the only thing it needs is Intellisense for packages but yeah definitely unified experience for installing packages.

Instead of tackling specific problems, I'd argue that a much better design is to let programmers handle it and what I mean by that is creating a Console that is extensible and is designed for installing packages, whatever the package might be, VSCode extensions, nuget, bower, npm, you name it.

Just to be clear, I mostly suggest the experience of the Package Manager Console available in Visual Stuidio to Visual Studio Code but taking it few steps farther.

[Tyriar]

@eyalsk be sure to 👍 #691 - It would enable something like this:

code --install-ext=ms-vscode.csharp
code --uninstall-ext=ms-vscode.csharp

[iam3yal]

@Tyriar thanks! ;)

[mossyblog]

The extension installation shouldn't have built-in UI like this, its defeats the purpose of Visual Studio Code imho. Instead i'd rather just have [Read More] [Install / Uninstall] ..instead of Cloud-down icon.

If the route is to explode this into UI first principles then in reality its just back to Visual Studio we all go?

The target audience is developers so their insights into command line control / development is potentially higher from a discoverability standpoint plus with supportive loop-backs to the vscode extension page(s) online, one has the ability to unpack "what is this extension?" there vs trying to mirror that experience inline.

Key factors.

• Cadence of Time. User's who install an extension are likely to be once-off moments in-time from a majority vs minority standpoint. The exclusion to this rule is when a user(s) in a refractory state and want's to browse / explore the "market place" for options. In which case i'd personally prefer they go visit the supportive page(s) for this as this can increase functionality for better search experiences or self-selection principles.
• Visual Studio Code major selling point for adoption is it's stripped down Visual Studio to the metal almost, incremental feature creeps like these put it back into a tool that does everything for you again (which imho is a deterrent).
• UI constancy vs consistency. It's one thing to graft its own UI shell into place, but when folks talk about modals i get twitchy, given OSX vs Windows modals have different set of behaviours. This is a fast way to break into jail.

Imho, it's fine, just nuke the icon given its reliance of symbology, size and colour have a negative effect. Instead, continue with the wording but remove License and fold it into [ReadMe] or [More.]. and keep the options to two. Isolating the [Install] into better grouping ie (solid fill while [Read Me] / [More] has wire frame bordering) also imho reduces cognitive load.

[kumarharsh]

Although I really like the willingness to improve the user experience, I have a few concerns I would like to put out there. There is this one thing I really dislike about atom - I have to leave my keyboard and use my mouse to install extensions. It's only a minute worth of time, but the experience is very jarring, and I have found myself trying to avoid installing packages until absolutely necessary, or trying out new themes at all. This was never the case with SublimeText, which in spite of having a limited UI around extension discovery/installation, makes the experience of using new packages much faster.

Atom has it's apm which I imagine would be an equivalent of sublime's approach (but it lacks a discovery mechanism).

I have another flicker of an idea, which largely keeps the same flow as now, but also makes it more easier to read the docs and manage extensions:

Basically, a developer presses ctrl + shift + p and types ext install, the dropdown appears, and he moves to the desired package, and presses ENTER. This opens up the management page for the package, which has the README (if available) and the INSTALL button already highlighted - thus pressing ENTER again installs the plugin.

Maybe another action Ctrl+Enter can be added to do a Quick Install (bypassing the above-mentioned flow).

[glen-84]

I definitely prefer @jrieken's mock-up (and it seems like others do as well).

You could add Installed/Recommended/Marketplace tabs under the search field, and do a fancy animation of the icons when switching between coding and management mode.

[stevencl]

We'd like to do a round of 1:1 interviews to get more feedback on your thoughts about the extension UI and UX. If you can spare 30 minutes of your time, please pick a time slot and I will set up a call with you: https://calendly.com/stevencl/vs-code-extensions/05-03-2016

[stevencl]

If you are interested in giving us some feedback about the extensions UI and UX, we've opened up some more time slots: https://calendly.com/stevencl/vs-code-extensions/05-03-2016

[felixfbecker]

I like @kumarharsh and @jrieken 's mockup. Using the sidebar as a result list / popular extensions list (maybe categories that can be collapsed) and showing the readme on the right like an open file while clicking through the results. It should be keyboard accessable (shortcut for opening the extensions area, navigate with arrow keys, install with enter) and should not be a blocking modal (Brackets 👎 ). Extensions should be able to install in the background (and please stop prompting to restart Code even if there are other extensions still installing).

[Stanzilla]

Is there an "update all" button? I noticed this is missing in the pre-1.2 release and would be quite good to have. There is "list all outdated" but not "update all outdated".

[Stanzilla]

@joaomoreno did we end up getting an "update all" button?

[Tyriar]

@Stanzilla see #8124, it's marked for July (v1.4)

[Stanzilla]

^Thank you