-
Notifications
You must be signed in to change notification settings - Fork 29k
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
Welcome views should use primary + secondary button styles #158530
Comments
@joaomoreno not sure if you are still the respective welcome-view owner, feel free to re-assign |
Two options:
@jrieken I lean towards the first. Thoughts? |
Aren't these buttons contributed from multiple extensions? How do we agree on the one and only primary button? @joaomoreno what does define the order today? |
I believe @bpasero did this for notifications by simply ensuring the first defined action was rendered as primary. I don't think there was any fancy API beyond that. I like that model since it means we won't end up with a random mix of button styles. |
I'm unsure that simply giving the primary style to the first one is a good approach. Here's what my Explorer welcome looks like, annotated by where the contributions come from: I believe the core contributions always get top priority, followed by extensions in some order. If I disable either the Git extension (built-in) or Remote Repositories (from Marketplace), then re-enable them (in either order) they return to positions 2 and 3. These are both published by Microsoft, so I wonder if this causes Remote Repositories to get promoted relative to other Marketplace extensions (see below) Interestingly, the text at position 4 only appears when built-in Git is enabled, but it appears after the (not built-in) Remote Repositories. For my other three contributing extensions, disabling and re-enabling any one of them moves them to the end. A window reload reinstates the sequence shown above. Users of the Serenji extension (a FileSystemProvider) are unlikely to want to use the first button ("Open Folder"). There's currently no way I know of to hide it, and giving it primary-button prominence will make the situation worse. |
The difference is that notification come from a single source (extension) and these buttons come from multiple |
Now that I think about it, this is also hinting at the same discussion in #146688. There were some explorations around making the first button sort of a general "Open" primary button with multiple options. Regardless of the final solution, I feel strongly that having a huge list of primary buttons is a poor UI pattern. While these views aren't forms with simple |
Today we have 2-3+ primary buttons used in our Explorer. Extensions can also contribute many more. As a general UI principle I think we should only feature one primary action with the rest being styled as secondary.
Before
After
We recently adopted this behavior in notifications where we ensure the first action renders as a primary button. There's no special API other than the order of the array afaik.
cc @misolori
The text was updated successfully, but these errors were encountered: