[EuiButtonGroup] Better differentiate the current selection

[ryankeairns]

Is your feature request related to a problem? Please describe.
[internal feedback] I cannot tell with confidence which value is actually selected by looking at this unless I click and make the selection. But I just want to know what's selected, not change it.

Describe the solution you'd like
Can I suggest to make the selected item have more differentiation, perhaps an outline in addition to darker colouring. (this is one example to highlight).

Proposed redesign

---

Additional context
This is particularly problematic when only two options are presented (see below):

For reference, we apply margin around the currently active option in the compressed version of this input. Perhaps we can apply a similar style to the default size EuiButtonGroup, as well.

[cee-chen]

@ryankeairns any suggestions or opinions on what the solution/fix should be? Should normal be way more bold than low? Should we, e.g. change the highlight color to primary instead? This isn't an option, as EuiButtonGroup supports multiple color types.

Edit for clarity - I'm looking for a clear acceptance criteria to close out this issue :)

[ryankeairns]

I have not sketched any design alternatives, so I'm going on quick thoughts:

1. Yes, additional font weight (i.e. bold) would help, and
2. I'm inclined to copy the compressed version where there is padding within the group (as seen above)

Caveat:
We'll likely want to retain a height of 40px so that this matches other form controls
Edit: see Cee's comment below

[cee-chen]

Good news on 1., I've increased the font weight of selected buttons as part of the component's Emotion conversion (#6841).

I personally like the look of 2 a lot!

We'll likely want to retain a height of 40px so that this matches other form controls

I don't think this is correct. The button group should match the height of the buttons at the specified sizes, the compressed styling is what matches the form control heights.

[ryankeairns]

Added the proposed design from my previous comment to the issue description.
Seems solid enough to proceed that direction.

[cee-chen]

I spiked this out a bit but I'm running into slight difficulties.

1. There's a very light border between multiple buttons of the same color/selection that isn't present on compressed. Should we remove this border entirely going forward? Does removing the border visual difficulty between delineating between options?
2. Multiple selections on the compressed style do not combine/join together visually in compressed styling but they previous did in uncompressed styling. Is this fine/an intentional choice?

Uncompressed:

Compressed

[cee-chen]

I spiked this out because it's easier to have something to look at in-browser: #6876 / https://eui.elastic.co/pr_6876/#/navigation/button#button-groups (make sure to test selecting all and unselecting all on the 2nd example)

TBH, I'm not sure I'm a huge fan of the change in reality. The styling change is significantly more complex than I thought (especially for disabled states, particularly when a button inside a group is disabled but the entire group is not disabled), and to be honest, visually I can barely even see the 2px border especially on certain color combos.

I think the font-weight change I've already made is already a sufficient indicator for selection, and it might be worth considering skipping the pill/padding changing. Thoughts?

[ryankeairns]

The styling change is significantly more complex than I thought (especially for disabled states, particularly when a button inside a group is disabled but the entire group is not disabled)

Helpful context; not surprising to learn :)

I think the font-weight change I've already made is already a sufficient indicator for selection, and it might be worth considering skipping the pill/padding changing.

In light of the additional context - and that this is most relevant in situations with exactly two options - this seems like the practical thing to do first. We can then keep an eye/ear open for additional feedback.

[cee-chen]

Thanks Ryan!

In light of the additional context - and that this is most relevant in situations with exactly two options - this seems like the practical thing to do first. We can then keep an eye/ear open for additional feedback.

For the purposes of this open issue, should we go ahead and close it for now until we hear that more change is needed? Or we could leave the issue open and let it auto-close in a year 🤷

[ryankeairns]

Let's close it. People can still add comments / provide feedback but, and until this happens, it won't land on our roadmap.