Looking For Fashion?




Why Cards are not Nav’s


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).

Changing Hierarchy

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.

Preserving 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 list of cards

Cards

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 with Card Design

Nav-List

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.

The most common example of this would be how outlook handles the list of incoming emails.

Panels

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)

https://dribbble.com/shots/6379838-Drag-and-Drop-Affordances

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.

https://dribbble.com/shots/5921662-Radio-Buttons

Radio/Checkbox cards

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.

Conclusion

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.


Why Cards are not Nav’s was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.