Scan patterns change with reading direction and content type

What it is

The same desktop search layout — breadcrumbs above, filters on the start side, results in the middle — often takes its first landing on the top-start result card in a left-to-right UI. Mirror it for right-to-left and the first landing follows the start side; it does not stay in the geometric top left. Swap the middle pane for a gallery instead of a result list and landings move to the largest image; the filter pane is deferred. Scan patterns follow writing direction and content type, not the physical corner of the glass. Taking a heatmap from an English news site as a rule for an Arabic store or a photo detail writes someone else’s reading habit down as error.

Why it happens

Years of reading train a preferred heading: which side a line starts, which side a page starts. On a new viewport the eye goes to the habitual origin, then unfolds. The prior is weak. A stronger peak from content type — an image past half the screen, a full-width player — overwrites it. Type also sets strategy: forms are short hops between label and control; galleries are large hops image to image; articles follow lines. Direction prior times type strategy. There is no universal heatmap. A mirrored layout that flips coordinates but not reading origin (icon direction, digits still stacked LTR) sets gaze fighting between habitual origin and actual copy origin, and the heat becomes a dirty shape that matches no textbook figure.

Studying it

Build LTR and RTL of one architecture, then list / gallery / form of each — six materials, one task (“find the one you can buy,” or “submit”). Compare quadrant of first landing, time in the start-side third, and a strategy tag (along lines / jump peaks / paired short hops). Independent variables are script direction and content type; the dependent is path shape, not task success. Observers must be fluent readers of that direction. Running RTL pages on people who do not read Arabic measures a strange layout, not an RTL scan.

Where it stops holding

Icons, digits and video chrome often do not mirror with copy, so two directions coexist and scanning goes mixed. A mobile single column collapses left-pane / right-pane; direction differences remain mostly in the top bar and inline origin, and desktop quadrant contrasts shrink. Expert spatial memory for a given product can beat the direction prior: someone who enters Settings from the top-end every day will not move the first landing just because the language changed. New users and new pages feel direction and type most.

Applying it

• Do not write “put the important thing top-left” into every locale. Write “put it above, on that script’s start side,” and in RTL actually flip the reading origin, not only the containers.
• When the same chassis swaps content type, change peaks for the type. Do not keep the list-page heatmap. A gallery’s first landing will be an image; filters should not pretend they are still stop one.
• If digits, timecode and playback stay LTR on an RTL page, treat them as a second origin and check that a critical action does not sit in the gap neither origin scans.
• Check: fluent readers of that language do the same task; stack first landings. Modal quadrants for LTR vs RTL should flip with the start side; modal objects for list vs gallery should change with type. If RTL still piles on the geometric top left, either mirroring was incomplete or a peak (hero, high chroma) overwrote the direction prior — handle the peak on its own; do not add decoration that says “please look at the right.”

Related

• Same group: F3.04.1 Text-dense pages show a horizontally decaying scanpath · F3.04.2 Structured pages are scanned by jumping to visual weight
• Nearby: F3.09.1 The top and the start side are granted higher rank by default · F1.14 Semantic conventions of position · F4.05 Alignment
• Search terms: reading direction · RTL · scanpath · content type