## Background
- **Description:** A group of regular Buttons or ToggleButtons. A ButtonGroup can be multi-select or single-select.
- **History:** Commonly used component that exists in OOUI and is documented in the Design Style Guide; see links below.
- **Known use case(s):**
** GrowthExperiments:
*** Current {F35267782}
*** Proposed revision {F35267784}
** Recent Changes: {F35240562}
** WikiLambda: currently need a group of regular buttons with mutually-exclusive actions. Multiselect would be nice in the future. Design screenshot:
{F35222230}
- **Considerations:**
- Any changes to the Button component will also impact ButtonGroup, e.g. {T305437}
- OOUI has ButtonGroupWidget, which is just a group of Buttons or ToggleButtons. There is also ButtonSelectWidget, which has several Button or ToggleButton options that are mutually exclusive.
### User stories
- //add at least one user story//
### Previous implementations
These artifacts are listed for historical context. The figma spec, linked below, is the source of truth for the new component.
- **Design style guide:** see [[ https://design.wikimedia.org/style-guide/components/button-groups.html | Button groups ]]
- **OOUI:** see [[ https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#demo-section-button-sets | "button sets" section ]], [[ https://www.figma.com/file/2Jb1lVkhEMDFxO20I5xwyA/?node-id=2549%3A57467 | Figma spec ]]
- **Vue:** [[ https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/tree/master/app/src/lib/mediawiki.ui/components/MWButtonGroup | ContentTranslation ]]
---
## Codex implementation
### Component task owners
- Designer: //add the main designer's name//
- Developer: //add the main developer's name//
### Design spec
// Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below. //
A component spec sheet has not been created yet.
| Component spec sheet |
---
## Stage 1: Minimum viable product (MVP)
MVP includes basic layout, default states, and most important functionality.
### Acceptance criteria
- [] Determine what MVP includes for this component and document this in a subtask. Assign task to designer.
- [] Design MVP. Once complete, assign task to developer.
- [] Implement MVP
---
## Stage 2: Additional states, features, and variants
This might include a disabled state, framed/frameless designs, transitions, supporting different use cases, etc., which will be captured in separate subtasks.
### Acceptance criteria
- [] Document design and implementation of additional states and features in individual subtasks
- [] Complete each additional state/feature subtask
---
## Stage 3: Refinement
This stage includes any final touches or bug fixes needed before the component can be deemed complete, which will be captured in separate subtasks.
### Acceptance criteria
- [] Finalize docs: open and complete a subtask for any additional demos that need to be added or documentation that needs work
- [] Meet accessibility standards: open and complete a subtask for any necessary accessibility improvements
- [] Meet internationalization standards: open and complete a subtask to fix any i18n bugs
- [] Complete testing: open and complete a subtask for any additional unit or functional tests that are needed