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.
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:
- Body area, for any type of content, almost like a regular Card;
- Indicator area, for an icon and optional state that accompanies the body text;
- 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.
Paragraphs
FunctionCards support two kinds of text: regular and small paragraphs.
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.
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.
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.
Rules For Designers
- The buttons
- use the full available width at tier
XS
in both orientations, and at tiersMD
and above in horizontal orientation; - are displayed inline at tier
SM
in both orientations, and also at tiersMD
and above in vertical orientation; - are displayed upfront, i.e. before the additional text, at tiers
SM
and above.
- use the full available width at tier
- 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.
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.
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.
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.
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.
With shared footer
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.
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.