Welcome views should use primary + secondary button styles

[daviddossett]

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

[miguelsolorio]

@joaomoreno not sure if you are still the respective welcome-view owner, feel free to re-assign

[joaomoreno]

Two options:

• Make the first always be the primary
• Enhance the current button markdown syntax to support primary/secondary

@jrieken I lean towards the first. Thoughts?

[jrieken]

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?

[daviddossett]

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.

[gjsjohnmurray]

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.

[jrieken]

I believe @bpasero did this for notifications by simply ensuring the first defined action was rendered as primary.

The difference is that notification come from a single source (extension) and these buttons come from multiple

[daviddossett]

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 Submit | Cancel options, I believe views like the Explorer should have their welcome views focused around a general most-obvious action(s)—in this case opening a folder from somewhere. That could be a great use case for a split button with secondary buttons below.