Readable and usable on a phone, not merely rendered on one #73

New issue

Open

opened 2026-09-06 21:08:04 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-06 21:08:04 +00:00

Owner

Observation

Target for release 0.6.0 - user interface be readable by most smartphones browsers

What exists today

The interface is responsive in the sense that it does not overflow: Tailwind's sm:, md:
and lg: breakpoints are used throughout, the navigation collapses, and the browser suite
runs at a desktop viewport only. Nothing has ever been looked at on a phone, and nothing
tests one.

"Does not overflow" and "is usable while standing on a train" are different claims, and
only the first is currently supported by anything.

Why this matters more here than in most applications

A job search happens in gaps. The posting is seen on a phone, on a commute, in a queue;
the reply arrives on a phone; the interview invitation arrives on a phone. If recording
what just happened means waiting until you are at a desk, it does not get recorded, and a
record with holes in it is the one thing Postulo exists to prevent.

Shape

A phone viewport in the browser suite. The axe run already visits every page; it
should visit them again at a phone size, in both themes. Everything below is a
regression the suite can then hold.
The tables. overflow-x: auto keeps them from breaking the page but does not make
them readable — a six-column table on a 390px screen is a scroll bar with data behind
it. Applications, companies, sources and industries each need a form that works
narrow: cards, a chosen subset of columns, or the table settings (#already built)
defaulting differently on a small screen.
The board. Horizontally scrolling columns of 288px on a 390px screen is one column
and a hint of the next. Decide deliberately: one column with a status switcher, or the
columns stacked.
Touch targets. WCAG 2.2 AA asks 24x24 CSS pixels; comfortable is 44x44. The row
actions are px-2 py-1 text-xs buttons sitting next to each other, which passed the
desktop check and will not pass a thumb.
The forms. inputmode and autocomplete on every field that has an obvious
answer — email, telephone, URL, dates — so the right keyboard appears and the browser
can fill what it knows. This is the cheapest single improvement on the list.
The dashboard. Widgets are arrangeable now (#44) and the grid collapses to one
column, but seventeen widgets stacked is a very long page. Whether a phone should get a
shorter default arrangement is a decision, not an accident.
What a phone cannot do. Drag and drop on the board (#35) does not fire on a touch
screen; the status menu is the reachable path and must stay obvious rather than
merely present.
The rendered documents. Previewing a CV on a phone is reading an A4 page on a
390px screen. It needs a legible answer, even if that answer is "download it".

What this issue does not include

A native application, or a separate mobile interface. One set of templates that works at
every width, which is what the responsive utilities are for.

Classification

Enhancement, and a broad one. Not breaking.

Depends on

#67 for right-to-left, only in the sense that both are layout work and doing them in the
other order would mean doing some of it twice.

## Observation > Target for release 0.6.0 - user interface be readable by most smartphones browsers ## What exists today The interface is responsive in the sense that it does not overflow: Tailwind's `sm:`, `md:` and `lg:` breakpoints are used throughout, the navigation collapses, and the browser suite runs at a desktop viewport only. Nothing has ever been *looked at* on a phone, and nothing tests one. "Does not overflow" and "is usable while standing on a train" are different claims, and only the first is currently supported by anything. ## Why this matters more here than in most applications A job search happens in gaps. The posting is seen on a phone, on a commute, in a queue; the reply arrives on a phone; the interview invitation arrives on a phone. If recording what just happened means waiting until you are at a desk, it does not get recorded, and a record with holes in it is the one thing Postulo exists to prevent. ## Shape 1. **A phone viewport in the browser suite.** The axe run already visits every page; it should visit them again at a phone size, in both themes. Everything below is a regression the suite can then hold. 2. **The tables.** `overflow-x: auto` keeps them from breaking the page but does not make them readable — a six-column table on a 390px screen is a scroll bar with data behind it. Applications, companies, sources and industries each need a form that works narrow: cards, a chosen subset of columns, or the table settings (#already built) defaulting differently on a small screen. 3. **The board.** Horizontally scrolling columns of 288px on a 390px screen is one column and a hint of the next. Decide deliberately: one column with a status switcher, or the columns stacked. 4. **Touch targets.** WCAG 2.2 AA asks 24x24 CSS pixels; comfortable is 44x44. The row actions are `px-2 py-1 text-xs` buttons sitting next to each other, which passed the desktop check and will not pass a thumb. 5. **The forms.** `inputmode` and `autocomplete` on every field that has an obvious answer — email, telephone, URL, dates — so the right keyboard appears and the browser can fill what it knows. This is the cheapest single improvement on the list. 6. **The dashboard.** Widgets are arrangeable now (#44) and the grid collapses to one column, but seventeen widgets stacked is a very long page. Whether a phone should get a shorter default arrangement is a decision, not an accident. 7. **What a phone cannot do.** Drag and drop on the board (#35) does not fire on a touch screen; the status menu is the reachable path and must stay obvious rather than merely present. 8. **The rendered documents.** Previewing a CV on a phone is reading an A4 page on a 390px screen. It needs a legible answer, even if that answer is "download it". ## What this issue does not include A native application, or a separate mobile interface. One set of templates that works at every width, which is what the responsive utilities are for. ## Classification Enhancement, and a broad one. Not breaking. ## Depends on #67 for right-to-left, only in the sense that both are layout work and doing them in the other order would mean doing some of it twice.

tiagoagueda added this to the 0.6.0 milestone

2026-09-06 21:08:04 +00:00

tiagoagueda added the

labels

2026-09-06 21:08:04 +00:00

tiagoagueda added a new dependency

2026-09-06 21:08:05 +00:00

#67 Right-to-left layout, so Arabic and Hebrew can be read