Add “Cards” to [[ https://design.wikimedia.org/style-guide/components/ | Design Style Guide “Components” ]] section.## Background
=== Acceptance criteria- **Description:** A common layout for presenting information, e.g. a link to an article page with a thumbnail, title, and description. There are many use cases across Wikimedia. Cards may be standalone or in a layout with other Cards.
[] Collect current card or card-like implementations across web products, examples: [[ https://design.wikimedia.org/ | Design homepage ]],- **History:**
- The card pattern has been used in many places, although it has never become a standard component. …See the table below for many examples.
[] Define general rules on appearance and interactivity - See T153417: Align the style for lists of pages, a related task (although some of these cases may be covered by a future ListItem component)
[] Align to internationalization and accessibility requirements - See T256036: Add Card component to ~~WVUI~~ Codex, a closed task that discussed potentially adding a Card component to WVUI
[] Define layout rules for when multiple cards/modules are shown in dashboard type content area - See T286973 and T299682 for discussion about reusing the WVUITypeaheadSuggestion and CdxMenuItem components for other card-like use cases, an idea that was later declined in favor of creating a dedicated Card component that better covers non-menu use cases
[] Add “Cards” to “Components” section
//** Examples of pages with cards/card-like layouts **//- **Known use case(s):**
- GrowthExperiments: see the first three items in the table below
- NearbyPages: see [[ https://en.wikipedia.beta.wmflabs.org/wiki/Special:Nearby#/coord/37.78348208159495,-122.4685506720315 | UI on beta ]]
- **Considerations:**
- As mentioned, there are many existing examples of card-like layouts. A first step in this epic will be to collect and organize these use cases, then define general rules on appearance and interactivity and align to internationalization and accessibility requirements
- We will need to define layout rules for when multiple cards/modules are shown
### Examples of pages with cards/card-like layouts
| Sample screenshot | Found in | Notes
|--|--|--
| {F34408565} {F35193862} | [[ https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_homepage | Growth Newcomer homepage desktop ]] | Card in the Suggested Edits UI - note the Mobile and Desktop differences. Could the modules themselves be considered cards?
| {F35193860} | Growth - newcomer homepage on MOBILE | "Preview" module cards - selecting a preview module card will open the module as a full screen overlay on mobile
| {F35193864} {F35193869} | Growth - post-edit dialog/bottom sheet on mobile & desktop | Appears after someone completes a Suggested edit task - unclear if this would be a separate bottom sheet component - would only the article within this be considered a "card" or ListItem component ??
| {F35193873} {F35193882} | Structured task link "inspector" card, shown under the item on desktop, as a bottom sheet on mobile (similar to VE link card) | again, not sure if only the article inside the dialog/sheet is considered the card/ListItem.
| {F34408567} | Main page |
| {F34408569} | Related articles at the bottom of Minerva articles |
| {F34432307} | [[ https://doc.wikimedia.org/ | doc.wikimedia.org ]], DSG code repo derivative |
| {F34432310} | [[ https://design.wikimedia.org/ | design.wikimedia.org ]] |
| {F35193888} {F35193893} | Content Translation 'home' page Desktop and Mobile |
| {F35193890} | Content Translation side panel (Desktop) |
| {F35193896} | Content Translation Section translation - mobile only at present | More info here https://www.mediawiki.org/wiki/Content_translation/Section_translation |
| {F35196454} {F35196470} | Echo notifications (on Special:Notifications and in the popup menu in the header) | Notable features: Unread/read indicator, different links for the entire card and items within the card e.g. user page and "view change" link, notification age in the bottom-end corner |
### 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:** n/a
- **OOUI:** n/a
- **Vue:** WVUITypeaheadSuggestion and CdxMenuItem were suggested as potential Card components but are too divergent from Card UI and use cases. However, some of parts of [[ https://github.com/wikimedia/design-codex/blob/main/packages/codex/src/components/menu-item/MenuItem.vue | MenuItem ]], namely thumbnail styles and loading state, could be reused via a separate Thumbnail component.
---
## 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