Go to Content
Design System
Playroom Storybook
#StandWithUkraine

FunctionCard

Open in Storybook Open in Figma

This page describes FunctionCard, its content, and it being part of a group. To see some real-world examples, head over to FunctionCard examples.

Basics

A FunctionCard is a special Card a user interacts with to enable/disable George functionality. Like all Cards, multiple FunctionCards can be placed inside a CardGroup. They then become one big white box.

FunctionCards usually arrange their content in vertical orientation (top to bottom), but when their horizontal prop is set, they will flip to horizontal orientation (left to right, i.e. a 3-column layout) on tiers MD and above.

Without the horizontal prop, FunctionCards will keep their vertical orientation on larger tiers, but in this case they are not meant to be used alone. Instead, two or three FunctionCards will be placed next to each other in a row.

Loading demo…
Rules For Designers
  • FunctionCards have a larger top/bottom padding than regular Cards.
  • FunctionCards have a larger left/right padding than regular Cards at tiers SM and above.

Content

The reason to not simply use regular Cards are the three distinct content areas that give FunctionCards their specific look. Only the first content area is mandatory, but no matter how many areas are present, they will be placed in the following order for accessibility:

  1. Body area, for any type of content, almost like a regular Card;
  2. Indicator area, for an icon and optional state that accompanies the body text;
  3. Buttons area, for buttons and optional additional text.

Body

The body area will occupy all the available space inside the card, unless one or both of the two other areas are present.

Headings

Headings are all set in the same size, anything from <h2> to <h6> can be used. The heading level of choice depends on the headings outside the CardGroup and has to continue one level deeper. Headings may be omitted if the leading heading in front is sufficent. In this case the FunctionCard either has no heading, or we display a fake heading, by using a paragraph with a .g-h-major modifier.

The use of headings with a reduced font size (i.e. adding the .g-h-minor modifier to an actual or fake heading) is supported, but should be limited to Function Information Cards.

Loading demo…

Paragraphs

FunctionCards support two kinds of text: regular and small paragraphs.

Loading demo…

Other elements

FunctionCards can have pretty much any content inside the body, but sometimes we limit ourselves on purpose, to achieve the look of the examples shown in the following chapters, and also in the aforementioned FunctionCard examples.

Indicator

FunctionCards usually feature an indicator containing an icon or image, and sometimes a state label.

The indicator can be used as-is, so the icon simply depicts the function. But the indicator can also be used to represent a state. In this case, a state label may be added via indicatorText, which is then placed underneath the icon. Doing so presents the function in its “turned off” state, and addtionally setting indicatorActive means the function is “turned on”.

The indicator acts as a banner on top of the body content. In horizontal FunctionCards at tiers MD and above, the indicator represents the first column of the 3-column layout.

Loading demo…
Rules For Designers
  • Indicators are always centred across the cross axis of the card, i.e. in vertical orientation horizontally, and vice-versa.
  • Indicator icon has a default size of 48px, but in horizontal orientation the icon size increases to 64px.
  • Indicator text reflects the status of the function, usually active & inactive. The icon does not change colour in sync with the status.
  • While the indicator area is a CardBody, and as such has its own padding, it is moved closer to the body area, to avoid the otherwise large spacing between the two.

Custom indicator

Any kind of content, but in reality an Image, may be supplied via the indicator prop.

Loading demo…
Rules For Designers
  • When a custom indicator is present, it is used instead of icon, text, and status.
  • A custom indicator (and as such its content) is constrained in width to 200px. You are more likely to notice this constraint in vertical orientation, as the available space for the first column of horizontal FunctionCards on larger tiers is usually smaller than that.

Buttons

The third and last content area is reserved for

  • up to three buttons, and
  • some optional additional text.

The buttons area contains calls to action, and is placed underneath the content. In horizontal FunctionCards at tiers MD and above, this area is synonymous with the third column of the 3-column layout.

Loading demo…
Rules For Designers
  • The buttons
    • use the full available width at tier XS in both orientations, and at tiers MD and above in horizontal orientation;
    • are displayed inline at tier SM in both orientations, and also at tiers MD and above in vertical orientation;
    • are displayed upfront, i.e. before the additional text, at tiers SM and above.
  • The additional text
    • will be displayed in a smaller font, and
    • is centre-aligned at tiers SM and above.
    • It should only be used in vertical FunctionCards.
  • While the buttons area is a CardBody, and as such has its own padding, it is moved closer to the body area, to avoid the otherwise large spacing between the two.

Variants

As indicated, the screen size and the horizontal prop determine the FunctionCard’s orientation.

Horizontal orientation

When horizontal is set, the content areas will be displayed left to right on tiers MD and above.

Loading demo…
Rules For Designers
  • The content of the body area is left-aligned.
  • The content of all three columns (indicator, body, and buttons) is vertically centred;
  • the buttons area acquires 25% of the card’s width, and
  • the indicator area acquires 15% of the card’s width.
  • If a custom indicator is specified, the indicator area acquires 23% of the card’s width.

Vertical orientation

Here, space is limited, for body content we only use headings and paragraphs, which is why we focus on how to describe the FunctionCard’s functionality.

A description can be specified via children and/or buttonsText. Interestingly, for vertical FunctionCards, the children are optional. In most cases the buttonsText is sufficent, sometimes you need both. Currently, our examples for vertical FunctionCards do not feature a case where children are used without buttonsText, so please double-check if you encounter a design that requests this.

The following example shows the three different description styles for illustrative purposes. In reality however, those styles are not mixed. Instead, a single style is used for all cards in a row.

Loading demo…

In a CardGroup

Both variants can be part of a CardGroup.

A horizontal FunctionCard needs no special treatment and should simply be added to a regular CardGroup. In there, a horizontal FunctionCard is just one among others. It continues to occupy the full width, consecutive cards in the group will be placed underneath, and there should always be separator lines between the cards.

Loading demo…
Rules For Developers
  • A single horizontal FunctionCard requires no CardGroup wrapper. However, basic spacing rules dictate to put it in a Group wrapper.

VerticalFunctionCardGroup

A vertical FunctionCard on the other hand must always be part of a group. Two or three vertical FunctionCards should be grouped together, and the dedicated VerticalFunctionCardGroup exists to make this happen.

When there are only two cards, a vertical separator line is recommended, but when we have three cards, we go with the opposite, i.e. specifying no separator via the group’s noLine prop.

Loading demo…
Rules For Developers
  • VerticalFunctionCardGroup is a helper component that makes use of CardGroup under the hood. It exposes the noGap prop, which can be set to combine it with another CardGroup that immediately follows.
  • Using four vertical FunctionCards is also possible, but in this case we still show only two cards per row, so we need two rows, i.e. two conjoined VerticalFunctionCardGroups.

With header

To add a header (title bar) before horizontal FunctionCards, just add a CardHeader to a CardGroup. Nothing special here, this is the procedure we already have in place for regular cards.

HINT We do not add such a header before a set of vertical FunctionCards.

Vertical FunctionCards may share a common footer. Simply create three FunctionCards without a buttonsText and put them in a VerticalFunctionCardGroup. The group comes with a footer prop, the content you put in there will be used to create the shared footer. For obvious reasons, this kind of CardGroup will never have separator lines between the cards.

Loading demo…

Function information cards

The so-called function information cards differ from regular FunctionCards by having no indicator, which is why there is no 3-column layout for them. As a result, they are only used in vertical orientation, i.e. in a VerticalFunctionCardGroup, and there are always at least two of them next to each other.

Semantically, the following example uses a heading followed by a paragraph, which is fine in most cases. Even two paragraphs could work in some scenarios, but two actual headings per card must be avoided.

To achieve the required visual effect, where the semantically more important piece of text on top has a smaller font size compared to the information card “tagline” following it, adding the modifier classes .g-h-minor to the first and .g-h-major to the second line of text is required. Similar to regular vertical FunctionCards, the final paragraph with the longer text will be placed in the buttons area of the FunctionCard via the buttonsText prop.

Contrary to the following example, function information cards are usually not used on their own, a more common example is a horizontal FunctionCard followed by two function information cards.

Loading demo…