Mobile UI

The input device for a mobile app is a hand. That sentence does more work than it looks like it does, because almost every difference in this lesson follows from it.

A mouse pointer has a precise position, a hover state that previews what will happen, and a second button for secondary actions. A finger has none of those. It covers an area rather than a point, it obscures the thing it is touching, and the tap is the whole interaction — press and result, with nothing in between.

Field conditions make it harder still. An engineer may be standing, holding a device in one hand, in bright sunlight, possibly wearing gloves, and looking away every few seconds. A layout that tests well on a desk at arm's length can be genuinely unusable there.

/** Density-independent units. The platform scales them for the screen. */
export const touch = {
  minTarget: 48,
  minGap: 8,
  edgeInset: 16,
  destructiveGap: 24,
} as const;

interface TargetBox {
  minWidth: number;
  minHeight: number;
  padding: number;
}

/** Pads a small glyph out to a thumb-sized tappable box. */
export function targetFor(visualSize: number): TargetBox {
  const padding = Math.max(0, (touch.minTarget - visualSize) / 2);
  return { minWidth: touch.minTarget, minHeight: touch.minTarget, padding };
}

/** Honours the user's text size setting, with an upper guard. */
export function scaledText(baseSize: number, userScale: number): number {
  const applied = Math.min(Math.max(userScale, 1), 2);
  return Math.round(baseSize * applied);
}

const editIcon = targetFor(16); // 16-unit glyph, 48-unit target
const bodyText = scaledText(16, 1.6); // 26 at the user's setting

• Treat this as a shape rather than an API. Whatever toolkit you use has its own way to express sizes; the point is that the numbers live in one module instead of being retyped per screen, so a review can check them in one place.
• targetFor separates what is drawn from what is tappable. A 16-unit pencil icon with 16 units of padding on each side gives a 48-unit box, which is why an icon-only button can look restrained and still be comfortable to hit.
• scaledText multiplies by the user's setting instead of ignoring it. That multiplication is the whole feature: a hard-coded 16 stays at 16 no matter what the user asked for, which quietly overrides an accessibility choice they made deliberately.
• The clamp at 2 is a real trade-off, stated honestly. Unbounded growth breaks dense layouts, and a guard keeps them usable. But every unit you shave off that ceiling is taken from someone who needs large text, so a cap of 1.2 is not a compromise, it is a refusal. Prefer fixing the layout to lowering the cap.
• Percentages and fractions of the screen are fine for widths. They are the wrong tool for touch targets, because a fraction of a small screen is a small target.

Hold a phone in one hand and the thumb sweeps an arc. The bottom centre of the screen is comfortable, the middle is reachable, and the far top corner requires shuffling the device in your palm or using the other hand. Screens have grown considerably; thumbs have not. So put the primary action low and within that arc, and reserve the top corners for things used rarely — a settings entry point, a close button. A save button in the top right corner is a small tax charged every time, and one-handed users pay it most.

Reach also argues for keeping destructive actions away from frequent ones. If "add note" and "delete visit" sit side by side in the reachable zone, a mistap is a matter of time. Separate them, and require a confirmation for the one that cannot be undone.

Safe areas are the other geometry problem. The screen is not a rectangle you fully control: a cutout may take a bite from the top, corners are rounded, and at the bottom sits a home indicator that swallows upward swipes. Ask the platform for the safe area insets at runtime and lay out inside them rather than hard-coding numbers per device, which ages badly with every new handset. The on-screen keyboard is the same problem in motion — it can cover half the screen, so a form has to scroll the focused field into view rather than trusting it to be visible.

Then there is text size, and this is where most mobile accessibility is won or lost. Many people run their device above the default, some well above, and the reasons range from low vision to being forty-five. If your app honours the setting, they can read it. If it does not, your app is the one they squint at. Honouring it means text that grows, containers that grow with the text, and layouts that reflow rather than clip. Test at the largest setting you support and fix what breaks — that testing pass finds more real accessibility problems per hour than anything else you can do on mobile.

Two things travel with dynamic type. Contrast, because sunlight on a screen turns light grey text into no text at all, and a ratio that passes on a monitor can fail outdoors. And labels, because an icon-only button is silent to a screen reader unless you give it an accessible name. A pencil glyph with no name is announced as "button", which tells the user nothing about what tapping it does.