According to a definition by material.io,
Cards contain content and actions about a single subject.
They should be easily scannable by the user, as they are typically clumped together in groups.
Think of playing cards: each card holds a unique set of information. For example, the 6 of diamonds holds specific data that separates it from, say, the 3 of clubs. Depending on the game being played, the player interprets each card as how it can be actioned, in order to achieve a goal.
Cards in a public-facing website or application, much like playing cards, are often limited to a single state. What they represent is often non-varying and not very dynamic. You click on the card, and you are linked to a single page.
But sometimes there’s a need for a card to change state, or to have multi-states. This is often the case in Admin applications, where the need to dynamically sort information is more crucial. Just like in many card games, certain cards can hold multiple values.
As an example, let’s take a look at the custom CMS we built for our internal operations on Acorn Interactive’s site. For starters, we divided our backend into 4 sections:
We then gathered our Admin User Stories that answered the following questions:
The generating of content is pretty straight forward, but depending on your internal operations, the managing of that content might need to be more nuanced.
Consider one of our Admin User Stories:
As an Admin, I want to be able to toggle a blog article between live and hidden so that I can manage both types of content.
Right away we see there’s the need for a post (represented as a card on a listing page) to have at least 2 states: Live and Hidden.
Now let's consider another one of our Admin User Stories:
As an Admin, I want to differentiate between 2 types of hidden blog articles:
…so that I know which articles need to be finished and reviewed.
As you can see, 3 states are now needed to manage the cards based on the Admin User Stories provided: Live, Inactive and Draft. Another benefit of having this Inactive state is that it can act as an archive of posts that can be pushed or pulled from the live site at any time.
The use of cards to organize all 4 of our backend sections seemed appropriate, as the admin user can easily scan and manage them, all in one dashboard view. For reasons outlined in our To Repurpose a Component or Not post, we decided to create a new card component for our custom backend, that would address different needs than the cards on our public-facing website. But what’s more, by creating this new card component we were able to address the needs of our 4 backend sections in a more precise way.
We knew that we’d be generating immediate and ongoing content for the Blog and Case Studies sections. As for the Jobs and Users sections, these would be more defined in the future, but we were confident their requirements would fit into the same card component as the others.
