- 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.
- The card pattern has been used in many places, although it has never become a standard component. See the table below for many examples.
- 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)
- See T256036: Add Card component to
WVUICodex, a closed task that discussed potentially adding a Card component to WVUI
- 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
- Known use case(s):
- GrowthExperiments: see the first three items in the table below
- NearbyPages: see UI on beta
- 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|
|Growth Newcomer homepage desktop||Card in the Suggested Edits UI - note the Mobile and Desktop differences. Could the modules themselves be considered cards?|
|Growth - newcomer homepage on MOBILE||"Preview" module cards - selecting a preview module card will open the module as a full screen overlay on mobile|
|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 ??|
|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.|
|Related articles at the bottom of Minerva articles|
|doc.wikimedia.org, DSG code repo derivative|
|Content Translation 'home' page Desktop and Mobile|
|Content Translation side panel (Desktop)|
|Content Translation Section translation - mobile only at present||More info here https://www.mediawiki.org/wiki/Content_translation/Section_translation|
|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|
- add at least one user story
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 MenuItem, namely thumbnail styles and loading state, could be reused via a separate Thumbnail component.
Component task owners
Stage 1: Minimum viable product (MVP)
MVP includes basic layout, default states, and most important functionality.
- 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.
- 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.
- 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