Mobile is not a breakpoint
It is a different device, a different network, a different input method and a different amount of attention. Narrowing the window simulates almost none of that.
Resizing your browser window changes one variable: width. It does not give you a touch screen, a slower processor, a flaky connection, a smaller battery, a virtual keyboard that covers half the screen, one thumb instead of two hands, or sunlight on the display. Those are the things that actually make mobile hard, and the responsive design conversation has spent fifteen years mostly about the one variable it can simulate.
Start with input. A mouse pointer is one pixel; a fingertip is about nine millimetres, which is roughly 44 CSS pixels. A button that is comfortable to click is frequently impossible to tap reliably, and two links four pixels apart are one link with a random outcome. Hover does not exist, a :hover menu is unreachable, and on some browsers the first tap triggers hover and the second activates, so some mobile menus need two taps for no visible reason.
Then the network. A median mobile connection is not your office wifi, and the tail is much worse than the median. The same page that loads in 400ms on your laptop can take eleven seconds on a train, and the failure mode is not slowness, it is abandonment. You built an intuition for this in the first lesson’s waterfall; this is where it becomes a design constraint rather than a number.
Then the processor. A mid-range Android phone from a few years ago is roughly five to ten times slower at running JavaScript than the laptop you are reading this on. Work that costs 50ms in development costs 400ms in someone’s hand 400ms is the threshold where an interface stops feeling immediate.
Then context. Phone use is interrupted, one-handed, often in bad light, often while doing something else. That argues for larger text than feels right on a desktop, higher contrast than looks elegant in a design tool, and forms that can be completed in pieces rather than abandoned when a message arrives.
The practical consequence for the rest of this lesson: every fix here is verified on a real device, not in a simulator. DevTools device mode is a useful drawing aid and a bad test, it has your processor, your network and a mouse. The next four chapters give you the specific failures; the last one makes you go and look at a real phone.
You should now be able to
- List what a narrow browser window does not simulate
- Design for touch, network and interruption rather than width
- Explain why your laptop is the least representative test device you own
Loading…