Something I’ve been trying to solve for a while is; why “active states” just don’t work with cards, this blog explores the abstraction of the differences between cards and nav’s.
Visual UI language
When creating interfaces it is of importance to make sure there is a consistent “Visual language”.
A visual language is a way of saying “is it clear for the user what the interaction will be when they click on an element”.
The most common interactions involve either changing where you are in the hierarchy or preserve the hierarchy and change elements on a page (are you going deeper in the site or moving sideways).
A common example of changing hierarchy are colored hyperlinks in text, you know that when you click on them you will lose the page you are on, and go to the page the link goes to. In essence changing where you are in the hierarchy.
An example of preserving hierarchy is the top nav. When you click on an item you will go to that page, but the menu will still be visible on the page you go to. From a hierarchical perspective you are moving sideways and not up or down.
Cards vs Lists
This is not a definite guide, your design language may differ due to the differences between website and application design, and mobile vs desktop patterns, complexity, or just taste and trends.
A card is a self-containing UI element that contains information about a single topic and can be interacted with. In normal person speak: A card has some info and can be clicked.
Cards should work similar to a hyperlink, once it is clicked, you go to the page about the card.
A Nav list is often visually identical to cards, except that there is usually a content panel visible, when you select a nav-list-item, you expect the contents of the panel to change.
Navigation list items, work more like navigation, when you click on them, they are still visible, but elements on the page change.
If you want to know why we call it a navigation items “lists” check out this article at css tricks.
Sometimes you would like to group content together to make it look nice, without there being any interaction associated with the card (dashboard metrics).
To avoid confusion between“clickable-cards” and “non-clickable-cards” we use the term “panel”. This means we can also style it slightly differently and just makes everyone's life slightly easier.
Card-esque Elements (Advanced)
Drag-able List items
Sometimes you would like to drag an element around (like Trello or Jira) sometimes this is a card sometimes this is a list item. Personally I like it when there is some kind of visual cue (affordance) that this can be done. Another best practice to think about is to add buttons, because dragging is not always possible due to technology restrictions or user disabilities.
Cards with nested actions
According to the HTML5 Spec Document from W3C: you are not allowed to nest certain elements (such as buttons) in an anchor tag, and a card is often one giant anchor tag.
That being said, there are a bunch of examples where you might want to add clickable elements inside a card such as liking, favoriting, sharing, deleting, or any other micro-interaction.
I'm not sure what the best practice is, use it against your best judgment, and try to keep accessibility in mind.
Another example that you often see in applications with high “end-user interaction quality” is when cards are used to select an option. These elements work similar to radio buttons or check-boxes but with more context.
They are not even really cards, they are just radio buttons that are styled to hold more content than a regular radio button. Often have a visual cue that they can be selected or checked.
If it has a selected/active state its probably not a “card”.
Use Cards to change where you are in the hierarchy.
Use lists to preserve where you are in the hierarchy.
Cards can be styled as lists and vice versa (but try not to).
A non-clickable card should be called a panel.
Try not to nest clickable items within cards.