An Image Orientation Check for Customer Upload Previews
A customer photographs a damaged item, uploads it, and the preview shows the picture sideways. If they submit anyway, the person reading the enquiry may struggle to see the problem. This article proposes a fixture set and a short confirm step so rotation is caught while the customer can still fix it.
Why orientation goes wrong
Phone cameras may record the way the device was held separately from the pixels, and different software may honour that note or ignore it. The result is that the same file can look upright in one place and rotated in another. Whether your preview does this depends on your own implementation, so test it rather than assume.
The orientation fixture
Prepare a small set of test photos of a simple subject with an obvious top, such as a sheet of paper with a large letter F and the word TOP printed at the upper edge. Take it in several ways: phone held upright, rotated left, rotated right, upside down, and, if you can, a front facing camera shot. Name files by how you held the phone, for example held-left.jpg. Keep a table with columns: File, How taken, Expected preview, Actual preview in your page, Actual in the received view, Pass or fail.
The last two columns matter: the preview a customer sees and the image your staff later open may be handled by different code.
The rotate-and-confirm journey
Consider this sequence as a proposal:
- Customer chooses a photo; the page shows a preview with the caption Does this look the right way up?
- Two buttons rotate it a quarter turn left or right, and the preview updates at once.
- A confirm control reads Yes, this is the right way up. Submitting is only possible after that confirmation or after the customer removes the photo.
- The final summary shows the same preview again before sending.
Branching choices
If your fixture passes in both views, the confirm step may still be worth keeping as a safety net, but you could make it lighter. If the preview is right but the received view is wrong, the fault lies in how the file is stored or shown later, and the confirm step will not fix it on its own. If rotation is applied only in the preview, decide whether to apply it to the stored image as well, and test that the choice survives submission.
Worked example (hypothetical)
Imagine you upload held-right.jpg. The preview shows the F lying on its side. The customer taps rotate left, the F stands upright, they confirm, and submit. Staff open the enquiry and see the F sideways again. That one row of the table, preview pass but received fail, reveals that the rotation was applied only on screen. The fix would be to carry the rotation with the submission, then rerun the whole fixture.
Stop conditions
Stop and fix before release if any fixture file fails in the received view, if rotating a photo loses the customer's other uploads, or if the confirm step can be bypassed by submitting quickly. Stop also if a very large photo makes the preview too slow to judge.
Acceptance checks
Every fixture file has a row with both views recorded; the rotate controls work with keyboard and touch; the confirmed orientation matches what staff later see; removing and re-adding a photo resets the state; and the page states clearly that the customer is responsible only for what they see, not for technical details. These are checks for your own testing and make no claim about every device or file type.