I’m currently in the process of rolling out yet another Card UI. Since Pinterest, the end-state of every list view with decent imagery is to become a Card UI. But thar be dragons! I’m here to share some of the pitfalls Paravel have encountered building Card UIs over the years.

Matching Card Heights

Rendering a grid of cards can be as easy as applying a 1px border around each item. But the first piece of feedback you get is to make all the cards have the same height.

Float grids need JavaScript to match card heights across rows. But doesn’t match subgrids.

Flexbox grids can match heights, but to align children to a subgrid you need to pass down a “flex soup” of flex declarations. Not great, but works.

Grid layout gets around the matching height problem superbly, but currently doesn’t support the subgrid usecase. Subgrids are probably a 2020 thing.

Truncation is not a Content Strate…

Popularized by Karen McGrane, “Truncation is not a content strate..” has become somewhat of a meme filled with marketing disasters.

Text inside a box is always a problem on the Web. It’s in large part due to the problem of overly-optimistic static text mockups.

Because all cards need to be the same height, you have to lock this down. Your first instinct is to combat this is try text-overflow: ellipsis. But this results in ~3-4 visible words in a description. That’s not very… uh… descriptive. Even worse with titles.

The best option is to never truncate. But if you must truncate, a decent solution exists in the non-standardized CSS property -webkit-line-clamp. This is like text-overflow but applied to multiple lines of text. Here’s a CodePen of how I’d like to be doing line-clamping in the future.

And good news! Edge just rolled out support for -webkit-line-clamp making Firefox the big hold out. I think Firefox is setting their sights on the now spec’d line-clamp property which is shorthand for the max-lines and block-overflow properties.

Double Padding Problem

Another subtle issue when everything starts becoming cards is that horizontal space on mobile starts getting consumed by padding. The card should be off of the viewport’s edge and the content inside in the card should be off of the card’s edge. This further compounds the truncation problem.

There’s also vertical padding between cards to worry about as well. Not a huge issue, but with dozens of items, they start to feel disconnected and could start to contribute to repetitive scroll fatigue.

Responsive Collapsing

On a recent project, to combat the double-padding issue and gain a bit more horizontal space we dropped the card metaphor on mobile for something more compact. I think it’s the right decision but increases the code complexity now that we have an iOS-style Table View that turns into a Card UI.

… And what happens if those cards are in a layout with a sidebar?!? Welp. All hell breaks loose and you have to turn on/off the Card UI. This is where Container Queries sure could help.

Hierarchy arms race

Once something is a card, it has a border, now everything else craves a border. Over a few iterations, everything becomes a card. A line gives prominence. Now everything wants prominence.

This isn’t unique to cards, but more a by-product of borders and borders are a core feature of a Card UI.

Poor Horizontal Scanning

Compare reading through a book or scanning a magazine vs. thumbing through a deck of cards. Each takes a different amount of time and has a different posture. There’s a place for everything but Card UIs tend to go against the tried and true F-Pattern.

Cards lend themselves to more casual, visual browsing experiences. I can’t believe I’ll say this… but cards work pretty well in a horizontal carousel (like the infamous AMP carousel). Stew on that for a bit… cards beget carousels.

Tap Areas

Now that everything is a card, more features get added. The first thing that gets added is a call to action link inside the card. Okay. Except that you probably coded it the first time around as a giant block-level link. So you undo the block-level link, but need secondary CTA or a “Details” link to replace the original block-level link.

Two or more links inside the card breaks leaves the tappable card metaphor broken. What you’re left with is…

Baby Webpages

I’m of the opinion that all cards in a Card UI are destined to become baby webpages. Just like modals. Baby hero units with baby titles and baby body text and baby dropdown menu of actions and baby call to action bars, etc.

In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.

The desire to reduce clicks increases complexity and raises the cognitive load. Depends on your situation, but I honestly think the workaround here is to go back to having a strong detail view pages. Scope cards in your UI to truly being previews or –to borrow a term from the watchOS Human Interface Guidelines– a “glance”.

YMMV

I don’t mean to shut down Card UIs. Not at all. I think they can be effective. It works for Pinterest and Dribbble! And like I said before, I’m in the process of rolling out a Card UI. These are just some of the challenges I run into over-and-over again while building out these types of UIs.

If you’ve got good principles or rules of thumb for guiding Card UIs to success, I’d love to hear them.