Cards are interactive containers that can be expanded, collapsed, dismissed off screen, or even used as a full screen surface to create a new context.
The card component is made up of a raised surface, and depending on the needs of the design, provides two interaction variations: simple, and complex. Cards can be simple in that the primary region is one large touch/click target, or complex housing two interactive regions — with each region containing one or more touch/click targets. The different regions are identified as either a primary region, or secondary regions (covered later).
Simple cards are used to initially hide content behind a tap/click, and can be expanded to reveal additional content, or morph to display completely different content. The collapsed state can only account for one interaction: expanding the card. Once the card is expanded, the secondary region is displayed. Optionally, upon expanding the card, either the secondary region is shown or both the primary and secondary regions are replaced with entirely new content.
- Primary region — Raised surface
- Secondary region (not shown until card is tapped/clicked)
Complex cards can also initially hide content behind a tap/click, but the main difference is complex cards display the primary and secondary regions in the collapsed state.
- Primary region — Raised surface
- Secondary region — High emphasis base surface (optional)
Note: The secondary region does not have to be a high emphasis base surface, it's shown here just as an example. The secondary region could be any static or interactive content.
Simple and complex cards both have a default amount of padding within the primary region, but can optionally allow content to extend the full width of the card. Secondary regions can also optionally use the default padding, or ignore padding completely to create a full-bleed experience.
Visually no changes are made through the various states; only the elevation changes as the user interacts with the component.
Cards can appear as collapsed or expanded, and both of these “states” without any additional interaction with the user would be considered to be in a static state. Some might refer to this as an enabled state.
When a card is either pressed (touch event) or clicked (mouse event) a pressed/active state is displayed to the user while the press/touch is occurring. Once the press is released and the click event is completed, the elevation returns to static state.
Cards should never be disabled. If the user cannot interact with the content on a card, the card should not be displayed at all. The most basic purpose of a card is to provide user interaction — if interactions aren’t possible, another component should be used instead.
Hover states only apply to users utilizing a mouse to interact with UI elements, and with the card specifically, the hover state creates a unique interaction in which the card rises slightly in response to the hovered pointer. The paradigm leans on the concept of a magnetic field in which the user's pointer pulls the magnetic card surface toward it when hovering.
The visual treatment of cards when focused via navigating through the document using the keyboard or mobile OS-level accessibility gestures, is handled by either the OS or the browser, and is not styled in any special way. When interacting with cards using either a touch or mouse event, the focused state is not applied.
When a user holds their press/click shorter than 500ms, visually nothing changes from the initial pressed/active state; but when holding the press/click longer than 500ms the card appears to lift off the surface to follow the finger/pointer. A long press can open up new opportunities for interactions such as moving the card, triggering swiping actions for data visualizations, displaying quick actions, and more.
For Web experience, dragged state could happen without a 500ms long press action. Like this cursor state for example:
Note: shape is a selection made by the FI within Theme Builder (sharp, soft, round, squircle), and the radius is based on the size of the component. The card component is considered to be a large component.
Cards can be placed almost anywhere within the main content area of a view or activity. The main thing to keep in mind is that when acted upon the card should not expand beyond the viewable area of the screen. If there is a need for more space than is available on screen, transform the card into a new context.
Cards can live on their own in the flow of content, or contained together within either a card group or list.
Cards appearing within a group of other cards should all have the same width and height to appear uniform and indicate their relationship one to another. The width and height of each individual card should be flexible to work within many different design solutions.
Note: the card group placement is different from the selectable tile component. A selectable tile is essentially a glorified radio button or checkbox and does not have any elevation. See the selectable tile component for more information.
Cards can appear in vertical lists — the height of which is determined by the content within the cards. There is no need to ensure uniform height for each card.
Cards are always interactive, and never simply used as a way to visually group content (see base surface if you are looking for a way to accomplish a visual grouping). Potential behaviors for cards are: basic touch interaction, expand (revealing additional UI), expand (revealing a new context), scrolling, swiping, dragging, entry and dismissal.
Basic touch interaction
Whenever cards are tapped or clicked, they respond to that action and mimic the physical world by scaling down to 98% upon the initial touch/click, and then scales back to 100% after the tap/click event completes. This interaction serves as a nice anticipation movement for all of the other card interaction patterns.
Collapsed > expanded (revealing additional UI)
Cards can expand to reveal additional content and secondary interactive regions. When interacting with the primary interactive region the card will expand or collapse — whatever the inverse of the current state is.
Collapsed > expanded (revealing a new context)
Whenever a user interacts with a card that expands to create a new context, the card should expand to fill the entire view. Once expanded into a full view, the user can collapse the card back down by swiping vertically on a non-interactive part of the surface.
All the cards within a card group do not need to appear on screen at once, and can be accessed by swiping horizontally or vertically to reveal additional cards in the group.
Some cards may include hidden interactions that can be accessed by a user swiping the card to the right or left. The pulling gesture should include some friction.
If actionable content lives below a swipeable card, and there’s only one possible action, swiping just a little will reveal content below; but will ultimately snap back into place if not swiped beyond the width of the actionable content. If the card is swiped beyond the halfway point, the action is triggered without the need for the user to swipe the card and then tap the actionable content below. In this context, “halfway point” is defined as half the width of the card. Swiping to reveal the full amount of actionable content below, while not exceeding the halfway point, the card will remain “open” and the user is required to manually tap the actionable content to trigger the action.
If multiple actions live below the card, swiping just a little will reveal the content below, but will ultimately snap back into place if not swiped beyond the width of the first action. Swiping fully will not trigger an action like the single action swipe; but will simply reveal all the actionable content areas below.
Some cards may be long pressed and dragged. Whenever this occurs, the card should increase in elevation and be dragged above other list items. List items beneath the card should respond to the position of the dragged card as it hovers, with all items becoming active again once the card is dropped.
Entry and dismissal
Some cards may not be displayed initially to the user, but appear after some time to request information or confirmation from the user. Upon entering, these cards should move any content in their way before entering, and come to rest naturally. Whenever a card that enters this way is dismissed, it should continue its original path of motion, bringing closure to the card’s entrance.
If a card is dismissed as resolved, it fades away to imply completion of a task.
Developer DocsVue Developer Docs
Component documentation coming soon!