The goal of this exercise is to see if we can use a pre-existing Codex style for this button placement.

After exploring the button styles available in Codex, I think the neutral-quiet-progressive style works well for this application.

Rationale

• The main tension here is that the type style we’re using in the titles of these menus is the same as the button type style. Side-by-side they, they may look too similar. The design challenge here is to find a button style that contrasts sufficiently with the menu titles without being too heavy and bold.
• The neutral-normal style is really heavy for this context because of the outline and the bold text, even though it accomplishes the task of creating contrast with the titles.
• Neutral-quiet combination with 24px height and only 4px of margins on the sides and not a capital letter beginning the CTA helps a lot to create contrast with titles.
• The neutral-quiet-progressive style works really well, except that I worry that it relies too much on the colour of the link in the top right to call it out as an action. You can definitely see the difference in grey-scale, but they look really similar without distinction between the greys though.
• Right-aligning the link also helps distinguish.
• The copy itself also helps call it out as an action.

Given all these things working together, I'm comfortable using the neutral-quiet-progressive buttons style in Codex with tweaked height and left/right margins.

@ovasileva I think we can create an implementation ticket for this now for the backlog. Not sure how sequencing with codex would need to work.

cc @Sarai-WMDE @bmartinezcalvo @DTorsani-WMF @bwang

In T351660#9381381, @JScherer-WMF wrote:

Given all these things working together, I'm comfortable using the neutral-quiet-progressive buttons style in Codex with tweaked height and left/right margins.

@JScherer-WMF thank you for sharing your explorations. The neutral-quiet-progressive looks good for this use case.

Since we will need to create the Codex small button in T352201: Button: Evaluate the need for smaller/inline button styles it would be great if you @JScherer-WMF could contribute the Codex system with this small button by creating the design specs following the Design Contribution Guidelines where you could design the small version of the button and then we can decide who can implement it (if the developers in your team or the DST ones). Wdyt @CCiufo-WMF @RHo? Could this be a potential case for a design contribution?

In T351660#9383606, @bmartinezcalvo wrote:

In T351660#9381381, @JScherer-WMF wrote:

Given all these things working together, I'm comfortable using the neutral-quiet-progressive buttons style in Codex with tweaked height and left/right margins.

@JScherer-WMF thank you for sharing your explorations. The neutral-quiet-progressive looks good for this use case.

Since we will need to create the Codex small button in T352201: Button: Evaluate the need for smaller/inline button styles it would be great if you @JScherer-WMF could contribute the Codex system with this small button by creating the design specs following the Design Contribution Guidelines where you could design the small version of the button and then we can decide who can implement it (if the developers in your team or the DST ones). Wdyt @CCiufo-WMF @RHo? Could this be a potential case for a design contribution?

Are we confident in adding the small button size to Codex? I know there are use cases for small buttons, but we should be aware of how the decision impacts our strategy for component sizing/responsiveness. If we are definitely going to add the component then having it come in as a contribution would be great!

@bmartinezcalvo I made a task for the web team to implement the new size in Codex T352803, pls feel free to update it or retag it if its missing anything. Would be great to get DST to review it when we work on it down the line

I also made T352804 for the corresponding vector work

In T351660#9381381, @JScherer-WMF wrote:

The goal of this exercise is to see if we can use a pre-existing Codex style for this button placement.

After exploring the button styles available in Codex, I think the neutral-quiet-progressive style works well for this application.

@JScherer-WMF
One thing I noticed about the Vector design here is that the button text is not flush with the border when the button is not wrapping to a new line

In T351660#9384499, @CCiufo-WMF wrote:

In T351660#9383606, @bmartinezcalvo wrote:

In T351660#9381381, @JScherer-WMF wrote:

Given all these things working together, I'm comfortable using the neutral-quiet-progressive buttons style in Codex with tweaked height and left/right margins.

@JScherer-WMF thank you for sharing your explorations. The neutral-quiet-progressive looks good for this use case.

Since we will need to create the Codex small button in T352201: Button: Evaluate the need for smaller/inline button styles it would be great if you @JScherer-WMF could contribute the Codex system with this small button by creating the design specs following the Design Contribution Guidelines where you could design the small version of the button and then we can decide who can implement it (if the developers in your team or the DST ones). Wdyt @CCiufo-WMF @RHo? Could this be a potential case for a design contribution?

Are we confident in adding the small button size to Codex? I know there are use cases for small buttons, but we should be aware of how the decision impacts our strategy for component sizing/responsiveness. If we are definitely going to add the component then having it come in as a contribution would be great!

I added a comment about this on T352201#9384807. I have a couple of concerns:

1. Should we only limit to re-using a smaller size of the existing variant or should in fact a different style variant be explored for smaller buttons in use cases like this where actions are appearing 'inline' with content?
2. Specifically for this proposing, I am wondering about the accessibility issue for using a frameless progressive button with the menu text, where only the colour of the action differentiates it from the title and section links. It is related to this task T329963: Provide guidelines on when to choose which basic interaction element in Codex - specifically the point about " Gather an inventory/audit where there is ambiguity of links styled as buttons, or buttons styled as links". cc @DTorsani-WMF who is assigned to this task.

In T351660#9384840, @RHo wrote:

In T351660#9384499, @CCiufo-WMF wrote:

In T351660#9383606, @bmartinezcalvo wrote:

In T351660#9381381, @JScherer-WMF wrote:

Given all these things working together, I'm comfortable using the neutral-quiet-progressive buttons style in Codex with tweaked height and left/right margins.

@JScherer-WMF thank you for sharing your explorations. The neutral-quiet-progressive looks good for this use case.

Since we will need to create the Codex small button in T352201: Button: Evaluate the need for smaller/inline button styles it would be great if you @JScherer-WMF could contribute the Codex system with this small button by creating the design specs following the Design Contribution Guidelines where you could design the small version of the button and then we can decide who can implement it (if the developers in your team or the DST ones). Wdyt @CCiufo-WMF @RHo? Could this be a potential case for a design contribution?

Are we confident in adding the small button size to Codex? I know there are use cases for small buttons, but we should be aware of how the decision impacts our strategy for component sizing/responsiveness. If we are definitely going to add the component then having it come in as a contribution would be great!

I added a comment about this on T352201#9384807. I have a couple of concerns:

1. Should we only limit to re-using a smaller size of the existing variant or should in fact a different style variant be explored for smaller buttons in use cases like this where actions are appearing 'inline' with content?
2. Specifically for this proposing, I am wondering about the accessibility issue for using a frameless progressive button with the menu text, where only the colour of the action differentiates it from the title and section links. It is related to this task T329963: Provide guidelines on when to choose which basic interaction element in Codex - specifically the point about " Gather an inventory/audit where there is ambiguity of links styled as buttons, or buttons styled as links". cc @DTorsani-WMF who is assigned to this task.

Re: small button exploration: I didn't scope the original task to exploring small buttons more broadly, just finding an appropriate, pre-existing codex style to use. Maybe small buttons deserve a style all on their own, to your point.

Re: accessibility. I share your concern about those buttons relying on colour to differentiate themselves from menu titles. I looked at the component in grayscale as a comparison.

There are a few things that differentiate this as a button instead of another element in the title:

1. It isn't capitalized, which I'm not sure I love, either, but that's how it is at the moment.
2. Content: it's a call to action, so reading it helps to contextualize it as a button.
3. Position: It's either right aligned on the line of the title (in the normative spot where a close affordance would be) or right underneath it when it wraps (which is often) in a way that makes it clear that it's not the same element as the title above it.

Based on those points, I thought it would be ok to go ahead with this for now.

This is a broader, related issue, but all the links in Wikipedia currently rely solely on colour to differentiate from other text, as you can see in the grayscale image above. I've been noodling on some ways to address this, but I don't have anything concrete yet. It's the same accessibility problem of relying on colour too much. Something to keep in mind while we figure this button style out.

In T351660#9384550, @bwang wrote:

In T351660#9381381, @JScherer-WMF wrote:

The goal of this exercise is to see if we can use a pre-existing Codex style for this button placement.

After exploring the button styles available in Codex, I think the neutral-quiet-progressive style works well for this application.

@JScherer-WMF
One thing I noticed about the Vector design here is that the button text is not flush with the border when the button is not wrapping to a new line

, which makes sense because quiet buttons have a little bit of padding.
However, it is flush with the border when the button is wrapping

, meaning we would need to account for the quiet button padding when it wraps (which is pretty frequent depending on the screen size and language).
Would it be more consistent for the button text to always be flush with the border? This would also give a tiny amount of room extra to the title, to reduce the amount of cases the button has to wrap

Good catch, Bernard. I cheated and nudged it to the left in Figma to compensate for the padding. You're probably right that that isn't a really scalable technical solution. I worry that removing that padding in general will introduce accessibility problems around tappable areas when this button is used in-line without being right-justified with a title. This style would get used in edit history pages for example. You can see some examples of this in @bmartinezcalvo 's explorations in the description of the parent ticket.

@JScherer-WMF Ah I'm not suggesting removing the padding, just accounting for it consistently by moving it to the left or right to appear like the text is aligned with the border. We do this in a bunch of places i.e. the hamburger in mobile, you can see the icon is aligned with the rest of the page, but if you hover over the button the padding is still there

In T351660#9416341, @bwang wrote:

@JScherer-WMF Ah I'm not suggesting removing the padding, just accounting for it consistently by moving it to the left or right to appear like the text is aligned with the border. We do this in a bunch of places i.e. the hamburger in mobile, you can see the icon is aligned with the rest of the page, but if you hover over the button the padding is still there

That works, then! We would nudge it in the code the same way I did in Figma.