In this section you can learn what CSS classes exist in the Card Designer and how they can be used to influence the colors, typography and layout of your Cards.
As a UI element Cards are distinctly minimalist and aim to show the user key information at a glance. We will therefore share some design guidelines that you may find useful when designing Cards for your organization.
In particular contains information and sample code for:
While the Elements on a Card can be freely arranged, you will find that having a consistent structure helps users interact with Cards and makes them more intuitive to use.
In most cases you will want to include a Card Title element on the top and optionally a Footer element if you want to enable features like expansion or linking to an outside resource where the user would get more detail.
Both these Elements can be customized on a global level so that wherever you are using these two Elements that their behavior and branding will be consistent for all your Cards.
In the Main area you can use any number of Elements, be it a video, PDF viewer or the Liquid View Element which lets you parse JSON strings inside a HTML layout using the Liquid templating language.
Follow the Card Designer manual to learn how to use the Card Designer and see a complete list of Card Elements you can choose from.
Use real estate wisely
Cards can be viewed on devices as small as an iPhone 4 and therefore you should consider how much and what information really helps the user understand the gist of a Card at a glance.
Establish a family
Structural consistency in your layout across different Cards aids users in predictability and scan-ability, as they have certain expectations of what kind of interaction an element offers them.
Use negative space to create information clusters
The Card Designer has built-in classes to create paddings, margins and borders, as well as background and text colors. Use these to create a clean and easy to scan Card design that clusters information.
Less is more
Avoiding information overload is critical to creating an efficient workflow for users. Only bring up key information that the user needs to see to decide whether or not to interact with the Card. Use Modals or links to outside applications for any secondary information that is not essential for digesting a Card.
Cards aren't apps, but they can still offer great interactivity through expansion, Modals/Dialogs and buttons. Use these Elements to their full advantage to keep the Card itself simple.
Digital Assistant centers around the principle of atomic design. That means rather than giving a
div a class that you then define in CSS, you start describing the look with the classes of your
div, using descriptive words like
background-blue or shortcuts like
mtsm for margin top small.
In practice this means that you don't have to add a lot of contextual CSS rules but rather can use class names like tools that you apply to an element.
Using atomic CSS versus semantic CSS has a few key advantages:
Better for teams
Atomic CSS is optimized for workflows where a small team is responsible for developing a set of CSS rules, with full HTML components built by a larger team. With Atomic CSS, developers can just look at a style guide—or the CSS source—to determine which set of class names they’ll need for a particular module.
"This sounds like a terrible idea"?
The first time we discussed functional CSS most members of our team did too, until we actually started using functional CSS, and the maintainability of our frontend went up by 10x (rough estimate). Why? The answer is simple:
- If you use functional CSS, when you add something new to a page, you'll rarely write any new CSS. You can build most of what you want by composing these small CSS classes.
- This is a sharp contrast to using traditional "semantic CSS", where you'll add new classes like
shopping-cart__item--selectedevery time you add something new.
- Because you'll write CSS less, your overall CSS size will be small. That's a win for your users (faster load time), but also a win for developers.
- Why? Because developers need to look at existing CSS and ask themselves: "Is there any class I can reuse?" - but this gets harder as the size of CSS grows.