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

Sponsor deserves more visual real estate #150830

Closed
isidorn opened this issue May 31, 2022 · 20 comments · Fixed by #151886
Closed

Sponsor deserves more visual real estate #150830

isidorn opened this issue May 31, 2022 · 20 comments · Fixed by #151886
Assignees
Labels
extensions Issues concerning extensions under-discussion Issue is under discussion for relevance, priority, approach ux User experience issues verification-needed Verification of issue is requested verified Verification succeeded
Milestone

Comments

@isidorn
Copy link
Contributor

isidorn commented May 31, 2022

Testing #150748

We already discussed this offline but creating an issue so we potentially revisit this in the future.

Currently we render a ❤️ Sponsor button in the Extension details and it is great.
However I still think that we should add a simple ❤️ in the extension viewlet if an author has on-boarded to the sponsor. Here's my reasoning:

  • It feels to me the same as verified publisher - and we currently render that
  • If a user is super happy with an extension he will never open the extension details and discover that the extension is asking for a sponsorship. However everybody opens the extension viewlet from time to time (to install / uninstall extensions) and this should be discoverable there
  • We want to make this just discoverable enough so extension authors do not use notifications to spam users for donations
  • There is enough real estate in the extension viewlet. I suggest to not show this for search results, but only for installed extensions (when we do not show ratings / install count)
  • Adding an icon will not bring significant noise to the view

Design proposal: similar that we have the verified checkmark before the publisher. We could render the heart after the publisher area.

fyi @daviddossett @misolori for thoughts

@daviddossett
Copy link
Contributor

It's a nice idea. Couple of possible options below. I'm partial to the first option as a starting point for consistency w/ other actions but I included some louder options as well.

CleanShot 2022-05-31 at 10 30 12@2x

@isidorn
Copy link
Contributor Author

isidorn commented May 31, 2022

First two look great and just loud enough. We could add a blurb with link in the hover (similar like we have for verified).

@sandy081
Copy link
Member

I understand the interest behind making this feature visible to users.

But I am not convinced that this has to be shown as a primary action in the extensions view. Sponsoring is not something users often do when compared to other actions like enable, disable or uninstall. This is the main reason why I did not render Sponsor action in the header in the extension editor. Primary focus of our UI shall be to make day to day activity easy for users. Please also consider that for those users who do not want to sponsor (which I think is majority) this is unnecessary noise. This is also noise for those users who already sponsored - because I do not think they would sponsor again for the same extension.

For example, GitHub also does not render if a project can be sponsored when browsing for projects. One can only sponsor when you open the project.

It feels to me the same as verified publisher - and we currently render that

I disagree. Verified publisher gives an impression to the user that the extension can be somewhat trusted, where as sponsor action does not - this is requesting user to sponsor. Imagine if the publisher is not verified but still has sponsor action? How can I take a decision to sponsor. There is no enough information in the extension view for this. We shall always drive users to open the extension and provide as enough information as possible before they decide to sponsor.

Adding an icon will not bring significant noise to the view

I am sorry that adding an icon adds noise because extensions viewlet has very less real estate. Please see following

image

If the intention is to make it discoverable, I would explore the badge area which is intended for similar purposes like this

  • pre-release
  • recommendation
  • sponsor

Or let's come up with some smart model that periodically checks if user is using an extension for a long time and ask if user would like to sponsor those extensions.

@isidorn
Copy link
Contributor Author

isidorn commented Jun 1, 2022

@sandy081 good feedback and ideas, thanks.
Let me clarify: what I was proposing is not to have a clickable action in the extension view, but just some kind of UI decoration. Something to convey additional meaning and tackle the user's imagination. If you think a badge area is a better way to convey this information this works for me. The only problem I see with this approach is what if there are multiple badges - pre-release, recommendation and sponsor at the same time. Who wins right now when a pre-release extension is recommended?

Your idea for a smart model that periodically checks might work, my worry is that we would have to use notifications for it - I do not see a better way to ask the user to sponsor?

@sandy081
Copy link
Member

sandy081 commented Jun 1, 2022

Something to convey additional meaning and tackle the user's imagination.

Can you please elaborate more on this?

Who wins right now when a pre-release extension is recommended?

Is it possible to show the stack of badges from top to bottom? Can be a good UX challenge to solve?

my worry is that we would have to use notifications for it

I agree. I think we shall explore some Notification Center in extensions view for extensions specific prompts like this. It might be helpful to inform extensions that need attention like reload required, outdated, deprecated, sponsored etc.

Finally, I am still not able to understand why we want to make sponsor badge a first class concept? We are not doing the same for rating? IMO, rating an extension improves the extension eco system and adds more value to VS Code users and community.

@isidorn
Copy link
Contributor Author

isidorn commented Jun 2, 2022

I think that sponsoring probably brings more total value to the ecosystem than giving a rating. And for ratings users get introduced to them when they install the extension (we show ratings then). After that user can go to the extension details to rate.
Extension sponsor currently does not have this moment where users get introduced to the concept.
So when I said "tackle the user's imagination" I meant what I just said - just a way for users to discover this initially.

For multiple badges stacked on top - I live this to @daviddossett when he finds time (nothing urgent)

For the notification center idea - this might be just showing a badge in the extension view. The badge might go away once the user opens the view. I do not think we need something too heavy for this.

@sandy081 sandy081 added ux User experience issues extensions Issues concerning extensions under-discussion Issue is under discussion for relevance, priority, approach labels Jun 3, 2022
@sandy081
Copy link
Member

sandy081 commented Jun 7, 2022

One idea that came out of discussion between @isidorn and me is to add Sponsor / Rating to hover.

@daviddossett
Copy link
Contributor

Interesting idea. I can quickly sketch this at some point this week. Stay tuned.

@isidorn
Copy link
Contributor Author

isidorn commented Jun 8, 2022

@daviddossett we thought that the messaging should be something like "help make the extension ecosystem better by rating or sponsoring NAME_OF_EXTENSION"
This is not the exact wording, but that should be the underlying message, and then rating or sponsoring would be two links...

Of course we are open to other ideas :)

@daviddossett
Copy link
Contributor

daviddossett commented Jun 9, 2022

I think the explainer text probably just adds noise in this context. We could just have the simple actions like this:

CleanShot 2022-06-09 at 14 09 03@2x

@isidorn
Copy link
Contributor Author

isidorn commented Jun 10, 2022

@daviddossett this might work great. I would hate to add too much noise.

@sandy081
Copy link
Member

sandy081 commented Jun 12, 2022

When I implemented custom hovers for extensions, I was including rating in the hover and removed it later. I pulled those changes now and added sponsor and this is how it looks:

Screenshot 2022-06-12 at 18 43 35

It aligns with extension editor representation.

Note that I also moved Sponsor action to the header in the editor.

What do you think about

  • the hover?
  • moving sponsor action to the header in the extension editor?

@VSCodeTriageBot VSCodeTriageBot added the unreleased Patch has not yet been released in VS Code Insiders label Jun 13, 2022
@VSCodeTriageBot VSCodeTriageBot added this to the June 2022 milestone Jun 13, 2022
@sandy081
Copy link
Member

Reopening it for further discussions

@isidorn
Copy link
Contributor Author

isidorn commented Jun 13, 2022

@sandy081 I just tried this out from source and feels great to me. Both the hover, and the move to the header section. I am talking to Anup on the Marketplace side to get his thinking about the MP rendering - ideally we would also do it in the header section there.

My only feeling is that the color does not work for dark theme. Not enough contrast.

Screenshot 2022-06-13 at 11 26 09

Unrelated to this. "This extension is enabled globally" - I suggest to not have a hover for this, only if the extension is disabled does this deserve a message. If we remove this the hover will be lighter. Is there some benefit of this message that I am missing?

@sandy081
Copy link
Member

My only feeling is that the color does not work for dark theme. Not enough contrast

My bad, I did not check this in Dark theme. @misolori I need your help again to tweak the colour. Also can we have filled heart icon?

Unrelated to this. "This extension is enabled globally" - I suggest to not have a hover for this, only if the extension is disabled does this deserve a message. If we remove this the hover will be lighter. Is there some benefit of this message that I am missing?

Since we have different enablements, it is helpful to show it.

@sandy081 sandy081 reopened this Jun 13, 2022
@VSCodeTriageBot VSCodeTriageBot removed the unreleased Patch has not yet been released in VS Code Insiders label Jun 13, 2022
@isidorn
Copy link
Contributor Author

isidorn commented Jun 13, 2022

@sandy081 also I am not sure if the letters should be coloured. I think it will be nicer if they are just white. Notice how the verified has an icon and then Xdebug is without colour. So the <3 should be colured but not the "Sponsor"

Also Lydia was thinking the same when she did the initial mock
image

@isidorn
Copy link
Contributor Author

isidorn commented Jun 13, 2022

@sandy081 as for full or empty heart. Both work for me. Whatever you, @daviddossett think is best.
I have also shared this issue with MP side so let's also hear what they prefer

@miguelsolorio
Copy link
Contributor

@sandy081 previously the colors were being used as a background color in a button, do we envision this not being used anymore or do we need separate color tokens?

@isidorn
Copy link
Contributor Author

isidorn commented Jun 13, 2022

@misolori we envision those not being used anymore. We are leaning towards this design now it seems :)

@sandy081
Copy link
Member

sandy081 commented Jun 29, 2022

@isidorn Closing this in favour of the improvements done.

Please verify them.

Lets track any new ideas/suggestions in a separate issue

@sandy081 sandy081 reopened this Jun 29, 2022
@isidorn isidorn added verified Verification succeeded verification-needed Verification of issue is requested labels Jun 30, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Aug 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
extensions Issues concerning extensions under-discussion Issue is under discussion for relevance, priority, approach ux User experience issues verification-needed Verification of issue is requested verified Verification succeeded
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants