Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore Extensions Management UX #68527

Closed
sandy081 opened this issue Feb 12, 2019 · 32 comments
Closed

Explore Extensions Management UX #68527

sandy081 opened this issue Feb 12, 2019 · 32 comments
Assignees
Labels
extensions Issues concerning extensions *out-of-scope Posted issue is not in scope of VS Code plan-item VS Code - planned item for upcoming ux User experience issues
Milestone

Comments

@sandy081
Copy link
Member

sandy081 commented Feb 12, 2019

Explore Extensions Management UX

Extensions Management include:

  • Managing installed extensions

    • Enabled
    • Disabled
    • All installed
    • Built in
    • Outdated
  • Browsing Marketplace

    • Searching
    • Categories
    • Order of viewing
  • Show Recommendations

    • Workspace
    • General (file)

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

  • Flooded with views and making them hard to manage
  • Hard to distinguish among installed, recommendations and market place
  • Missing prominent information on installed extensions
    • Active
    • Running
    • Activation time
  • Viewlet is lacking space to provide necessary information like
    • Why reload is required
    • Due to this fact, we have a different page for running extensions
  • There is no nice landing page
  • Hard to browse extensions in market place with categories

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

@sandy081 sandy081 added plan-item VS Code - planned item for upcoming ux User experience issues extensions Issues concerning extensions labels Feb 12, 2019
@sandy081 sandy081 added this to the February 2019 milestone Feb 12, 2019
@tmsns
Copy link

tmsns commented Feb 13, 2019

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

@alexweininger
Copy link
Member

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
Copy link

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
Copy link

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
Copy link

gulshan commented Feb 21, 2019

@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
Copy link

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

@miguelsolorio miguelsolorio mentioned this issue Mar 4, 2019
33 tasks
@usernamehw
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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

@miguelsolorio
Copy link
Contributor

miguelsolorio commented Mar 7, 2019

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

  • Surface additional metadata like activation time (which you can sort by)
  • Remove information that isn't as relevant (rating, install count, version)
  • Create a new "Updates" category that allows you to see recently updated extensions

image


image

@gulshan
Copy link

gulshan commented Mar 7, 2019

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

@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.

@artas90
Copy link

artas90 commented Apr 14, 2019

hi, please also consider the following feature request
#64671
thanks

@regs01
Copy link

regs01 commented Apr 16, 2019

And splitting themes and extensions

@JaimeStill
Copy link

@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
Copy link

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
Copy link
Contributor

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

@LonMcGregor
Copy link

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
Copy link

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:

  • Sort By: Install Count
  • Sort By: Rating
  • Sort By: Name

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
Copy link

chpxu commented Oct 17, 2019

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
Copy link

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

@sandy081
Copy link
Member Author

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

@ShaunaGordon
Copy link

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
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extensions Issues concerning extensions *out-of-scope Posted issue is not in scope of VS Code plan-item VS Code - planned item for upcoming ux User experience issues
Projects
None yet
Development

No branches or pull requests