Extensions view redesign

[isidorn]

We have already quickly discussed this, but creating the issue so we can track this work for the future.

Extensions view UI deserves a UI face lift. Here's some thoughts:

• We might need a way to show extension specific msgs in there. We do not want to use notifications. Example msgs: "you have 2 deprecated extensions", "you have been using this extension happily, consider sponsoring or rating it", "this extension has an update" - Explore Extensions Management notification center #159889
• Extension item size is too small. We should not show that many search results Extension item height could be larger #150449
• How to show ML recommended extensions
• Are all the details really needed? For example should we show activation time only if it is above a certain threshold?
• Are all the menu entries really needed? Some menus got pretty complex (example filter menu) Should we surface some other action instead?

fyi @chrisdias @digitarald

[miguelsolorio]

Don't think we'll have time for it in this iteration but likely in the next, moving to July

[isidorn]

@misolori thanks, there's no rush here.

[miguelsolorio]

Here is some early ideas that we can start discussing in the next iteration:

• We can show more description text to make it easier to know more about the extension without having to click on it
• In order to reduce the visual noise we can show ratings/installs only when searching
• We can also save some space by removing the publisher and combining the verification with the extension title
• We can also combine the additional indicators for recommended/pre-release/extension pack next to the title
• We can update the search input to match the rest of the other filtering patterns by adding clear and filter options in the input field

CleanShot.2022-07-24.at.20.29.19.mp4

[isidorn]

Great ideas! I love the direction.

One more thing I would like us to rethink are the menus. There are a lot of context / filter menus which I think are a bit too much. I can look into the numbers to see on what actions people actually do click.

Assigning for August, and we can start discussing more from next week.

[digitarald]

Might be interesting to start doing some customer development on how users use the current search. Star ratings and downloads seem an important aspect, but we can also understand what meaning/weight the other indicators have.

@misolori would be good to keep the redesign in the default sidebar width, which is smaller than your mockup. Or did you plan to give the sidebar more space?

[eamodio]

@misolori A few comments

We can also save some space by removing the publisher and combining the verification with the extension title

This one concerns me -- since the check mark says nothing about who the publisher is. I think the publisher is an important piece of information

We can also combine the additional indicators for recommended/pre-release/extension pack next to the title

Will these still be visible if the title is longer than the available width? Also, I find the current "pre-release" badges/buttons quite confusing and hard to see/understand, and I'm not sure this helps.

You also have so much open space here, it would seem to me that the pre-release button could live there

I would also suggest the "badge" for pre-release to be something like a box with PRE in it and overlay that on the extension image

[isidorn]

@benibenj @misolori @sandy081 and me just had a discussion about this. Here's our current thinking:

• We will first focus on improving the extension search experience. @misolori will work in August on the design side, and @sandy081 and @benibenj will take up engineering in September.

• Feedback on @misolori current design:

  • The extension description should either be 2 or 0 lines. 1 line is not enough for a meaningful message
  • As @eamodio suggest we should experiment with PRE for pre-release extensions icon
  • We should consider to get rid of the "extension recommendation" badge
  • We should experiment with adding a 4th line which would have publisher + rating + downloads
  • We believe that having the actions on the last line resonates well
  • If we increase the size of the extension items in search, how will that resonate for other scenarios where we might have less vertical space? Or should the size increase only happen for search?

• After we improve the search experience we believe there are additional problems worth exploring:

  • How to improve the current experience of managing installed extensions? Imagine users with 50+ extensions installed
  • Extension notification center for extensions related messages (deprecated, updated, errors?)
  • Should we re-visit the menus we have in the extension view. I suggest to look at telemetry and see how much popular is each action.
  • Does managing installed extensions deserve an editor space? Can we successfully pull this off with the space we have in the viewlet
  • How to show ML extension recommendations

Let me know if I missed something from our discussion. @sandy081 since you know all the extension open issue you might know some of the other top problems users are facing. I plan to think more about this and edit this comment.

[miguelsolorio]

Here's some minor updates based ont he feedback from above:

Default

Installed

Trying to see if it makes sense to show the publisher info when installed

[eamodio]

For the "Default" (which I would assume applied to a search as well?), I like the publisher/proof row, but I wonder if the install button always need to be visible in its own row -- or maybe only visible on hover/selection. Visually, I see a lot of install buttons that stand out so much compared to the rest. I also think another description row would be more valuable to add.

For the "Installed", I like the "PRE" badge a lot, but I wonder if it should be moved directly under the icon (in the empty space. Like the install button, I wonder if the gear was also only visible on hover/selection, because again the repetition of that stands out a lot. I also think that not having the publisher is ok on the installed version.

I do wish on the "Installed" version that the actual version number was visible in the list, so I can more easily glance at the version of an extension that is installed.

[RandomFractals]

What I would like to see is a standard "Pro" version publishing and support. Then as @misolori redesigns the sidebar for extension search, have an option to install a "Pro" version of extension that is packaged and published separately perhaps.

Granted, either custom or vscode team provided github sponsors api would be required to implement the workflow of sponsors check for the paid Pro version of extension and enable "Pro" features.

[isidorn]

@misolori nice work. Seeing this I feel like this additional vertical space that each extension item would get works well for "search results" but not so much for "installed". What do you think if the items were different sizes in those two scenarios, so there is the base size (same as before), and the extra size which is base size + install button at the bottom. We would use the extra size only when the extension is not already installed.

If we were to use the same sizes everywhere, then the last empty row of installed extensions with only a gear looks empty. Could we use it as a place for extension specific notification badge maybe and other runtime indicators?

Slightly related - on click we show the Extension Details page both if the extension is not installed and if it is installed. While this makes perfect sense for non-installed extensions I think we could improve this for installed extensions. The extension details page in this case should be tuned towards how the extension is running, and not towards the data which you needed while you were decided if you want to install it. @sandy081 what do you think?

[isidorn]

After going through planning I do not think we will have cycles to tackle this milestone, thus moving to On-Deck.
However I created a follow up issue for Extension Runtime Status #159786

[shellscape]

y'all are trying to reinvent the wheel when Atom had quite literally the perfect presentation for extensions/packages in a single page, single pane. The complexity difference between VS Code (and even the proposals in this issue) and Atom are staggering, with Atom being by far the simplest experience and execution.

[daviddossett]

@shellscape we all have the same goal: to make this product better. We welcome constructive feedback and ideas. Calling out the people above as "trying to reinvent the wheel" is not helpful.

Let's get specific. What exactly are you proposing given the many additional constraints and features that VS Code's marketplace supports for both extension users and publishers? How would you design it in such a way that it doesn't upset the millions of people that use the existing experience today?

[shellscape]

@daviddossett in another issue you asked me to enumerate the differences between Atom and VS Code, and what I thought was better, etc. I replied with an offer to do a video call that we could record and share with the teams. I even reached out on Twitter. The result was crickets.

The issues here are quite literally littered with suggestions in issues that were either overlooked and closed as stale, or denied outright by maintainers. I've spent the better part of the last few weeks looking through them while trying to get an environment remotely similar to Atom going in VS Code.

I'm going to assume that your reply is in earnest. What I'd like you all Microsoft employees to understand is that more often than not, replies like that seem take the position that we're in your business processes, that we have the same managers, same business constraints. To us, it's an open source project - with incredibly tight gatekeepers. We're not employees, we're users and hopeful contributors. If we make an offer of help, take it, rather than replying elsewhere with (forgive me for not having a better word for this) platitudes that make it appear we're lazy, obtuse, or vague in our criticisms.

Take me up on my offer for a call, we'll go over things in minute detail if you'd like. And I'm happy to spend that time to try and improve the project.

[daviddossett]

replies like that seem take the position that we're in your business processes, that we have the same managers, same business constraints.

Let me clarify - I was referring to the literal UI features and constraints that you can see in VS Code and it's extension marketplace today. Your original comment seems to be centered around the presentation of extensions. That's what I'm looking for more specific feedback on.

We all appreciate the offer to help. If you don't want to write it here, a recorded walkthrough posted right here in the issue is also great. That way the community can weigh in as well 👍

[nklowns]

Hello @esonnino, i got that this issue is mapped on Iteration Plan for March 2023

Currently, there is no visual distinction between globally enabled extensions and workspace-enabled extensions, which can be confusing for some users. It would be helpful to have a search filter for workspace-enabled extensions, so that users can easily find and manage extensions that are enabled in their workspace.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!