search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.16k stars 28.53k forks source link

Explore Extensions Management UX #68527

Closed sandy081 closed 2 years ago

sandy081 commented 5 years ago

Explore Extensions Management UX

Extensions Management include:

Over the time this viewlet has become a single place for all of the above which made it

This seems like Extensions viewlet is overloaded with too many features and used for managing/browsing/customising extensions instead of just using like an explorer.

Goal of this issue is to explore some ideas considering all above use cases and come with a good design which gets aligned with current VS Code UX.

Following are some issues that are kinda related to current viewlet

tmsns commented 5 years ago

Might be an idea to use the the actual marketplace site in a webview for all “Browsing Marketplace” related items?

alexweininger commented 5 years ago

I think it would be worth while to consider implementing a way to group or organize extensions, enabling the user to quickly enable/disable project specific extensions when setting up a workspace.

RoestVrijStaal commented 5 years ago

This might be a separate issue but...

I'd advice to add to Managing installed extensions the criteria Unmaintained. Which means the shown extension(s) didn't get any update from its developer within a year or after a new major (or minor) release of VScode.

For each extension you need to manually navigate to its source repository to check its maintenance status. Which is obviously annoying.

LonMcGregor commented 5 years ago

It would be nice to be able to install an extension, and automatically enable it just for the current workspace.

Right now to do this you need to Install it, disable it, then re-enable it for the current workspace (potentially needing to reload the UI after each step).

gulshan commented 5 years ago

@LonMcGregor Just disable the extension and re-enable it for the current workspace. No reload required. After initial disabling, a reload button will show up (not knowing your future intension), which will be gone after re-enabling for the current workspace.

IgorKrupenja commented 5 years ago

I think it would also be nice to have a way to recently updated extensions so you could check out release notes for those.

usernamehw commented 5 years ago

I remember asking about sorting of Running Extensions by activation/activation time to be able to find slow-loading extensions quickly. Can't find it now, but the response was that the fate of the Running Extensions is unclear: should it be in Extensions viewlet or in a separate tab.

I could probably send a PR, but only after this decision is made. Is it resolved now?

miguelsolorio commented 5 years ago

@usernamehw we're currently exploring adding that in this exploration (adding running extensions metadata) so I wouldn't attempt any PRs for now.

We're hoping to post some updates in the next day or two 😄

miguelsolorio commented 5 years ago

Exploration A

This concept explores using a simplified table of contents on the left side and various card sizes for extension categories. A lot of elements are borrowed from the Settings UI.

exploration a

gif

miguelsolorio commented 5 years ago

Exploration B

This concept explores using a rich table of contents on the left side to help improve the discoverability of extensions. This also splits the main content into two sections: Marketplace and Installed. This aligns more with our Settings UI.

exploration b

gif

alexweininger commented 5 years ago

@misolori I think this looks great and it will definitely improve extension discovering. Could you give more detail on viewing/managing installed extensions?

miguelsolorio commented 5 years ago

@alexweininger for viewing/managing extensions, here's what we're hoping to do:

image
image
gulshan commented 5 years ago

This looks great. With this UI/UX, the existing left pane for extensions will be unnecessary I think. In that case, extension view icon can put on top of settings icon. Because all other icons are denoting a pane.

miguelsolorio commented 5 years ago

@gulshan that's one of the options we are discussing since we already have an established pattern for actions in the activity bar to open a viewlet. Moving it next to the settings gear fits better as that opens a context menu.

fabiospampinato commented 5 years ago

Integrating the marketplace better into vscode sounds like a good idea, but there seems to be too much going on on these proposed designs IMHO:

screen shot 2019-03-08 at 15 50 06 screen shot 2019-03-08 at 15 51 58

  1. I count 4 separate columns of content: activity bar, sidebar, categories/our picks column, extensions. Maybe that's a bit too much.

  2. In the extensions section there are (at least) 4 different kinds of rectangles: there are 3 featured extensions, 4 recommended extensions, 3 regular extensions, 2 extensions with a description. Maybe 2 kinds of rectangles would be enough instead of 4. Maybe always using the same number of columns (except for featured extensions maybe) could help the design as well.

  3. The columns used for the categories/our picks column and the extensions column don't have the same proportions as the columns used in a single extension's page, the first column is a bit narrower there. So when clicking an extension to read its readme I'm kind of seeing the second column moving a bit to the left and that's distracting.

  4. Does this scale well on smaller screens? I can't see all these columns fitting well on a 13" laptop. Perhaps some controls for changing category can be put under the search field rather than on their own column (but the current design seems to align better with the current settings page), perhaps showing less extensions per page could be helpful too. Also I'm not sure it's useful to know what version an extension is going to get updated to, as I can't see the current version I'm running anywhere on the page and nobody remembers these things.

miguelsolorio commented 5 years ago

@fabiospampinato thanks for the detailed feedback, appreciate you taking the time to write this!

  1. This something we're aware of and hope to have a global solution for since it impacts other areas (Settings, Keybindings).

  2. We're still experimenting with showing the right number of items here, which will determine their sizes, so this is good feedback.

  3. I'm hoping to tweak the layout a bit so that the main content always stays in the same columns. Nice catch 👀

  4. We're designing this with responsive in mind, similar to how our Settings page is responsive this will adjust the layout accordingly as well.

benfletcher commented 5 years ago

  1. Regardless of chosen icon, I'd love a way to get from an extension directly to its settings without opening settings and searching (I think some extensions implement this themselves in arbitrary ways). A separate tab on the extension detail page with a view into just that extension's settings would alternatively be awesome.

  2. Side note: I've always expected the gear icon in the extension explorer to provide a means to access or change the extension's settings. But instead it lets you take actions upon the extension. There's no definitive meaning of these icons, but I'd argue it's more intuitive for a wrench icon to be used for actions upon a thing and a gear icon implies internal settings of the thing.

  3. The extension output pane being accessible from an extension view would be helpful to newcomers for discoverability of the somewhat hidden extension output pane. It was months after I started using vscode before I realized how much useful info could be gleaned from that pane or that it was explicitly accessible (vs. just being triggered by an extension error).

I guess this reads like a feature request, but post it here because I think they're relevant to extension usability and intuitiveness. The theme being better tying together of related extension views.

miguelsolorio commented 5 years ago

@benfletcher this is all really great feedback 🙌

MeikTranel commented 5 years ago

Feedback about process

we should produce a capabilities list for this one. Lots of comments here provide extremely valuable feedback, but should be out of scope for this issue.

For example: Some of the mockups and plan updates up the the comment chain already talk about sorting stuff by update-date etc. which atm isn't even possible because the persisted data isnt even there yet. The feature request is tracked here: https://github.com/Microsoft/vscode/issues/53405

The UX Update for this one should not depend on this feature. That would be unnecessarily moving the goalpost.

Feedback regarding the above ideas and mockups

👍Mostly looks fantastic.👍

Points of improvement

Everything "List"-like should have a "Order By" dropdown (maybe on the topright - see screensnip black bar) image

Sorting options should at least cover the following: Extension-Name (A-Z) - Extension Package ID - Release Date - Downloads - Author (A-Z) - Rating

It should also be possible to control ASC/DESC Sorting

Points for future consideration:

artas90 commented 5 years ago

hi, please also consider the following feature request https://github.com/Microsoft/vscode/issues/64671 thanks

regs01 commented 5 years ago

And splitting themes and extensions

JaimeStill commented 5 years ago

@misolori, in Exploration B, I really like the idea of having extensions grouped into categories. I tend to keep a lot of themes installed (because I get bored easily and like to switch things up), and as it stands, my Enabled extensions view is cluttered with themes. It would also be nice to be able to tag your installed themes so you can group them as you see fit.

LonMcGregor commented 5 years ago

If the "installed extensions" view is being migrated to a full-page view akin to the cards in chromium's extension page, then I think it might still be nice to somehow offer a very light sidebar that just had installed extensions and a quick toggle.

That's what I use in a panel my web browser to quickly toggle extensions as needed:

image

I guess one big difference is that extensions in VS code can have 3 states: Disabled, Enabled and Enabled for this workspace. I'm not sure how would be best to show a 3 way toggle.

usernamehw commented 5 years ago

@LonMcGregor, isn't there a 4th state: Disabled for this workspace ?

LonMcGregor commented 5 years ago

a 4th state: Disabled for this workspace ?

@usernamehw is correct. That's one I've never used personally. Makes things a bit trickier to imagine a quick toggle.

spartanatreyu commented 5 years ago

Something I've found missing from the current functionality that would be handy to have would be a way to order extensions by install date.

I installed the Trailing Spaces extension to highlight any random trailing spaces that have slipped into the code and it worked great, but randomly a few hours later I encountered a problem with it where it was incorrectly highlighting lines that were had no whitespace issues.

I went to the extensions pane to remove the extension and couldn't remember what it was called. I clicked on the menu button (three dots) in the extension pane, first to show only the installed extensions (which hides the pre-installed and recommended extensions), then again to sort by installation date.

Currently we have:

but no "Sort By: Install Date".

It was only a minor nuisance to re-read all of my installed extensions (25 of them, mainly language syntax support extensions) to find the misbehaving one but this would be a nice quality of life fix to add for devs that are trying new extensions

chpxu commented 4 years ago

I also think having like a small marker noting if it's enabled locally/globally

May help to resolve conflicts and make it easy for developers to fix their environment, since we can already disable per workspace etc.

sfabriece commented 4 years ago

Is whitelisting of extensions per workspace part of this issue or should I create a new one?

sandy081 commented 4 years ago

I doubt issue for that already exists, so please search for it.

ShaunaGordon commented 3 years ago

This still appears to be open, though it hasn't been added to in over a year. If there's a better place for this, I'm willing to move it there.

I'd really like to have the ability to enable/disable extensions in the text configs.

Use Case 1 (any of the config files): I have an extension that styles the Markdown Preview pane to look like an RPG rulebook. However, I don't need it for all of my Markdown files, just a subset of them, and that subset is within the same workspace as the other Markdown files (so enabling/disabling by workspace doesn't work here), but an option in the folder's .vscode/extensions.json could be used to tell VSCode to activate the extension for the files in that folder.

Use Case 2 (only workspace level, single user): I work in a number of disparate paradigms and I find it helpful to keep enabled only the extensions a given project uses, to cut down on clutter. Having that information in the config files allows my workspaces to "just work," even if I'm on a new machine.

Use Case 3 (only workspace level, multiple users): Having the enabled extensions in a workspace file allows me to share the extensions part of a workspace more concretely than the recommended extensions list currently does, adding a "required" layer and ensuring that the extensions are not only installed, but enabled. This can be particularly useful for standardizing base configurations (including extensions) within a team.

GregWoods commented 3 years ago

I love the idea of enabling extensions in text config files... I always felt extensions.json needed a bigger role! Also worth mentioning... this kind of feature needs to work sensibly for users who simply open a folder rather than a workspace. I end up creating workspaces in my single folder "projects", just so I can disable certain extensions!