A Device Rotation Check for a Product Comparison Table
A comparison table is usually built for one orientation and then quietly rebuilt when the phone turns. If the rebuild forgets which columns the shopper chose, they lose their place at the moment they were about to decide. This article proposes a rehearsal you could run before shipping any rotation behaviour. Everything here is a conditional design suggestion, not a description of existing software.
The idea
Treat the selected columns as state that belongs to the shopper, not to the layout. Rotation should change how many columns fit, never which columns are chosen. A layout change may hide a column from view, but the choice should remain stored.
The portrait to landscape state rehearsal
You could write the rehearsal as a short script with a state line recorded at each step. Use this template.
Step 1. Open the table in portrait with a known set of products and columns. Step 2. Select columns by hand. Record the selected set and the visible set. Step 3. Scroll horizontally and vertically to a marked position. Record the position. Step 4. Rotate to landscape. Record selected set, visible set, position. Step 5. Change one selection in landscape. Record again. Step 6. Rotate back to portrait. Record again. Step 7. Rotate twice quickly. Record again.
For every step, write two columns in your notes: expected and observed. The selected set should be identical across steps 3, 4 and 6 unless the shopper changed it in step 5.
Branching choices
When landscape fits more columns than portrait, you must choose a rule, and the rehearsal should name which one you picked.
Branch A: show only the selected columns. Rotation then changes width allocation, nothing else. Branch B: show selected columns first, then fill spare room with unselected ones, visibly marked as not selected. Branch C: when portrait cannot fit all selections, keep them all but scroll, and show a count such as '4 of 4 chosen, 2 visible'.
Branch A is the simplest to verify. Branch B risks the shopper believing filler columns were chosen. Branch C is honest when selections exceed the width.
Hypothetical worked example
Imagine a table of five fictional desk lamps with columns for brightness steps, arm length, base size, weight and finish. The shopper selects arm length, weight and finish in portrait, and the visible set shows all three because they fit. After rotating to landscape under Branch A, the three columns widen. The shopper then deselects weight. Rotating back should show two columns, not three. If weight reappears, the layout is reading a default instead of the stored choice, and the rehearsal has caught a fault.
Now a second case: the shopper selects all five columns in landscape, then rotates to portrait where only three fit. Under Branch C the table should say five chosen, three visible, and scrolling should reveal the rest. If it silently drops two, fail the step.
Stop conditions
Stop the rehearsal and fix before continuing if any of these happen: a selection changes without a shopper action; the table reloads and empties its rows; the scroll position jumps to the start; or the page loses the selection after two quick rotations. Do not continue testing later steps on a state you already know is wrong, because later results will be unreliable.
Acceptance checks
- The selected set recorded at step 6 equals the set at step 5.
- No step changes the product rows or their order.
- The visible set only differs from the selected set where width forces it, and the page says so.
- A shopper using assistive technology hears the selected count after rotation, if your build announces it.
- The rehearsal passes on at least one small and one large screen you have access to, and the notes name those devices, so nobody assumes wider coverage.
Keep the filled in notes beside the release record. If a later layout change touches the table, rerun the same seven steps. A rehearsal this short is more likely to be repeated than a long test plan, and repetition is what makes it useful.