This morning, Tyler Galpin took a shot on Twitter at Stuff & Nonsense’s new redesign:
Yay for completely unreadable line lengths on a screen larger than a laptop. Constraints, dude. http://t.co/jusxIj4H
Andy Clarke defended the design choice, saying, among other things:
I don’t want to put constraints on line-length. That’s not a designers’ job. It’s a user’s job. If anyone wants to change the measure in a flexible layout, they can do it easily by changing the browser window width on their Mac or PC.
By me not limiting line-length, a user can let big text fill their screen and see more of it at a time. A constrained, narrow width would force them to scroll and I don’t want that. If you think my logic’s flawed, or you can think of a better solution, I’m all ears.
As luck would have it, I’m all mouth.
So let’s chat for a minute. Let’s chat about two things that users can do to improve readability, as needed:
- lean in to the display
- invert the colors of the screen image using OS-specific commands
These acts have dramatically different barriers. The first requires only a minimally functional set of core muscles—no conscious thought or fine motor control whatsoever. The second, some problem analysis, a conscious decision, prior advanced knowledge of one’s OS, and a modicum of fine motor skills, depending. (I still often botch the iOS home-button triple-tap.)
The greater the set of requirements to perform a task, the more the designer should do to prevent the user from having to perform that task. Absent some principle like that, how could we say that, in general, designs shouldn’t feature white-on-black body copy? Or, I don’t know, 6px body copy?
I would argue that the action Clarke empowers his users to take—constraining line lengths by adjusting browser window sizes—has more requirements than the scrolling he’s trying to help them avoid.
Scrolling is easy and barely conscious for many people in many cases. It’s such a fundamental act of web reading that we have many different ways to do it:
- the arrows on the scroll bar
- the whitespace in the scroll bar
- the scroll position indicator in the scroll bar
- the mousewheel
- the trackpad
- whatever you call the top of the Apple Mouse
- the space bar
- the down arrow key
- tapping a phone’s screen and dragging (so easy I do it with my nose when I’m wearing gloves)
And so on.
(Okay, one more: In Instapaper’s iOS app, you can just tip your iPhone or iPad to scroll. Marco Arment seems to have taken scrolling to be so important in developing an app for reading that he wanted to make it even easier. This despite the tap-and-drag’s having been, again, an absolutely fundamental iOS interaction from day one.)
By contrast, resizing a browser window as Clarke would prefer we do requires, first, that we make the conscious decision to do so. Anecdotally, when I make the decision to resize a browser window, it feels like I’ve done a lot more analysis of the problem I’m having than when I scroll, a behavior that I started using in, I don’t know, 1987. I bet you feel more or less the same way.
There are also fewer ways to resize a window. Historically, you could use your OS’s maximize and related buttons or you could grab the bottom-right corner of the window. The buttons probably don’t help Clarke make his case, since they don’t resize with enough control or predictability to be useful in trying to adjust text sizes.
The latter method, grabbing the corner, was such an interface problem—with its small targets and somewhat sloppy, two-axis behavior—that, starting with Lion, Apple decided to change the model significantly. I’m stubbornly attached to Snow Leopard, so I can’t speak to the effectiveness of the new resizing features. (And to be fair, Apple tackled scrolling, too, not that I was jazzed about those changes.) But it’s tough to imagine an argument that resizing is easier than scrolling, the dilemma as Clarke figures it.
All told, if it were my site—and, at the moment you read this, it will be—I would much more readily encourage scrolling than resizing.
Don't Look Now 