Cards are generous. They give every item a border, padding, a title, a little room to breathe, and plenty of opportunities for the page to become six feet tall.
That generosity became a problem in the Park Field Guide.
An attraction roster is not a collection of unrelated stories. It is a comparison surface. Someone wants to scan names, types, descriptions, service notes, and current waits without relearning the layout on every row. Once that became clear, the right component was not a more compact card. It was a table.
A card works well when each item needs its own action, media, hierarchy, or independent story. It can contain different kinds of content without pretending the pieces line up.
A table works when the columns are part of the meaning.
On a park page, the repeated questions are predictable:
- What is this experience?
- What kind of experience is it?
- Is there a service note such as Single Rider?
- Is a current wait available?
- If there is a wait, what direction is it moving?
Those questions belong in headings and rows. A real table also gives assistive technology the relationship between the header and each cell. Rebuilding the same visual arrangement with nested div elements would trade away that structure for no useful benefit.
The first instinct in a dense mobile table is to shorten everything.
Sometimes that is correct. The wait readout splits into three short headings, Minutes, Level, and Trend, so each cell answers one question. A service pill can say “Single Rider” while the day-of availability note sits beside it in ordinary text.
Other shortening creates new work for the reader. A dash in a wide empty column is still a wide empty column. An audit sentence compressed into one centered line can become a puzzle of orphaned dates and dot separators. A description clipped after two lines may hide the exact detail that distinguishes a show from a ride.
The compact version needs hierarchy, not just fewer characters.
On narrow screens, the experience column receives the flexible space and the wait columns use only the width their content needs. Metadata breaks into intentional groups. Service notes wrap as units. The row can get shorter without asking the words to behave like icons.
The park planner also uses a small meter, but not as decoration.
Its four steps represent a named crowd band: quiet, moderate, busy, or heavy. The label and provenance remain visible in text, and the meter is hidden from assistive technology because it does not add information beyond those words.
That is a different job from a wait time. Ten minutes is already a number. Turning every wait into a meter would require an arbitrary maximum and could make the same ten minutes look different across parks or attraction types.
Visual encoding is useful when the scale is real and explained. Otherwise, the table should be allowed to say 10 min.
Live-looking tables create a special trust problem. A current wait without a source or timestamp can become stale while retaining all the visual authority of a live readout.
The roster keeps the feed source and update age above the table. Single Rider coverage has its own reviewed date and limitation because it is authored research rather than live provider data. Unknown waits remain dashes instead of zeroes.
These details take vertical space. They also change how the table should be interpreted, so “condensing” them out would make the design smaller and the information worse.
The better move was to structure them: a source line, a review line, and table headings that do not compete with the evidence notes.
Switching to rows did not require removing the Park Field Guide’s visual character.
Land accents still identify sections. Each row carries a small scene of its attraction. Headliners retain their status treatment. Attraction names use the editorial display voice while operational labels stay in mono. The authored map remains above the roster as the park-specific visual moment.
The table supplies order. The art supplies place.
Trying to make the table itself carry every bit of personality would reduce its usefulness. Trying to make the entire page look like a spreadsheet would lose the reason the guide is memorable. The design needs both layers, with a clear handoff between them.
The guide did eventually gain a Cards view. It is for browsing: each attraction gets a larger stage for its scene, which is the right shape when the question is “what is this place like?” rather than “which line is shortest?”
The table stays the default. The two views share the same data, filters, and headings, so switching between them changes the presentation without changing what the guide claims.
A stack of cards can be easy to code. A table with responsive columns, grouped metadata, truthful empty states, and readable focus behavior needs more care.
The result is simpler for the visitor because the repeated relationships stop moving around.
That is the standard I want to use elsewhere: choose the semantic structure that matches the task, then add the smallest visual treatment that helps someone read it. A familiar component is not automatically the right one just because it has rounded corners.
See the current treatment on any Park Field Guide detail page.