Compare view

Problem Context

• Items are similar enough to share meaningful attributes, such as products, plans, locations, services, courses, vendors, devices, loans, or saved options.
• Users are in a shortlisting phase after search, browse, filtering, or saved-item collection and need to make a compensatory decision across several criteria.
• The attribute set may be longer than a card can show, and some attributes matter only to a subset of users.
• The view may be static with preselected options or dynamic with user-selected candidates from a list, grid, search result, or saved view.
• Mobile and narrow layouts make the full matrix difficult, so the product needs item-count limits, attribute subsets, paired comparison, or a saved shortlist fallback.

Selection Rules

• Choose Compare view when users need to evaluate a small number of similar items across the same attributes.
• Use Compare view after users have narrowed candidates through search, filter, category browsing, recommendations, favorites, or saved items.
• Use table when the main task is scanning many records, auditing values, sorting rows, or exporting the dataset rather than comparing a selected shortlist.
• Use card grid or card list when users are still discovering candidates and do not need aligned attribute tradeoffs.
• Use details panel when users need to inspect one selected item while staying in a list, grid, map, or board.
• Use data grid when users need to edit values, reorder columns extensively, or navigate cells like a spreadsheet.
• Use filters or facets when one nonnegotiable attribute should eliminate items before comparison.
• Avoid Compare view when items are not mutually exclusive, too cheap or simple to justify comparison, mostly aesthetic, or too unique to share useful attributes.
• Limit comparison to a small set, usually two to five items on desktop and fewer on mobile.
• Do not hide important differences behind hover-only cells, collapsed rows, or marketing-only labels.

Required States

• No compared items state with instructions for adding items and a route back to browse.
• One compared item state that explains another item is needed for meaningful comparison.
• Full comparison state with item headers, grouped attribute rows, actions, row labels, and selected-item count.
• Maximum item limit reached state with a clear remove or replace path.
• Differences highlighted, identical rows hidden, attribute group collapsed, attribute group expanded, and all attributes restored states.
• Item removed, item swapped, item unavailable, missing attribute, stale price or status, loading attributes, and failed attribute load states.
• Mobile pair comparison, horizontal-scroll comparison, sticky header, and selected-item tray states.
• Return-to-browse, save comparison, share comparison, export comparison, and choose item states.

Interaction Contract

• Compared columns represent user-selected or explicitly preselected peer items, and the view states the item count and comparison limit.
• Each row compares the same attribute across items using consistent labels, units, formatting, and missing-value rules.
• Hide-identical and highlight-differences controls update row visibility or row emphasis without changing the selected items.
• Removing, swapping, saving, or returning to browse preserves the remaining shortlist and the user's place in the originating list or grid when possible.
• Sticky item headers, row labels, and group headings preserve orientation while users scroll vertically or horizontally.
• Mobile comparison either limits columns, lets users choose a pair or subset, or provides a saved-item fallback instead of squeezing the full matrix unreadably.
• Action buttons such as Choose, Buy, Apply, Save, or Contact are tied to the correct compared item and remain distinguishable from remove controls.
• The view explains unavailable, stale, missing, estimated, normalized, or vendor-supplied attributes before users rely on the comparison.

Implementation Checklist

• Define comparable item type, maximum item count, required attributes, optional attributes, groups, units, missing-value notation, primary action, and return-to-browse state.
• Add compare affordances to source cards or rows with persistent labels, keyboard access, and a selected-item reminder or tray.
• Render comparison with item headers as columns, attributes as rows, grouped sections, sticky identity, row separators, and responsive behavior.
• Implement remove, replace, hide-identical, highlight-differences, group collapse, save, share, export, and choose actions with clear focus management.
• Model empty, one-item, max-items, missing attributes, stale attributes, unavailable item, loading, failed-load, mobile, and horizontal overflow states.
• Keep selected items keyed by object ID rather than visible index so filtering, sorting, reordering, and returning to browse do not corrupt the shortlist.
• Test with long item names, long attribute labels, mixed units, missing values, duplicate names, many groups, narrow screens, keyboard, zoom, and high contrast.
• Provide a table, data grid, or details handoff when users need exact row work, many records, editing, or deep per-item inspection.

Common Generated-UI Mistakes

• Allowing too many compared items so columns become unreadable.
• Using inconsistent labels, units, or attribute availability across compared items.
• Showing long marketing paragraphs instead of concise comparable values.
• Hiding compare selection behind hover-only controls.
• Dropping item names, prices, or key status when users scroll.
• Failing to hide or highlight identical rows, forcing users to search manually for differences.
• Treating a general table, details page, or card grid as a Compare view without selected-item management.
• Removing selected items when users return to browse, filter, sort, or change viewport.

Critique Questions

• What decision are users making, and which attributes genuinely influence that decision?
• Are the compared items similar enough for row-by-row comparison and mutually exclusive enough to justify choosing among them?
• Can users see item identity, price or status, row labels, units, and differences while scrolling?
• What is the item limit, and how do users remove, replace, or add candidates?
• How does the view behave with missing attributes, identical attributes, stale values, and mobile width?
• Would a table, card grid, details panel, filter panel, or saved list better match the user's stage?