It’s not about the device. — Ethan Marcotte
Is anyone actually going to use the browser on a watch, though?
Sometimes the question’s asked sincerely; more often than not, it seems to be asked skeptically. (And perhaps a little derisively.) But each time I share a link to an article about browsing on the Watch, it’s always, always asked.
There’re a few different things at play here.
Let’s start by taking the question at face value. If we do that, the answer’s an easy one: folks have quite literally been using wrist-based browsers for years. There’s a fair follow-up question to be had, of course—how popular are these browsers?—but the only things that can answer that question are your own site’s logs and analytics, and your own research into how your audience accesses your work.
Digging a little deeper, I read more than a little device fatigue underneath the question: we’re asked to support so many devices, and so many browsers, what’s the benefit of adding this weird one? And, hey, I get it. When I worked on The Boston Globe’s responsive redesign, I got a thrill loading our prototype on an early Kindle’s black-and-white browser, sure—but I recently had a minor existential crisis the first time I saw a browser embedded in a car’s dashboard. If folks are skeptical of adding yet another screen to the list of devices we’re planning for, I can completely sympathize.
I’d only say this, which is what I say every time I find out about a new device, a new browser, a new whatever that’ll be accessing my work:
It’s not about the device.
Let me start by saying I generally avoid terms like “mobile,” “tablet,” and “desktop” in my work. It’s not that they’re bad; it’s because they’re broad. In my experience, terms like these confuse more than they clarify. Ask a roomful of clients or stakeholders to define “mobile,” and you’ll get a roomful of slightly different responses.
What I think is helpful, though, is breaking down the specific conditions or features that’ll cause our designs to adapt. So at the end of my last book, I showed a table like this:
|Input Method||Touch||Keyboard / Mouse||Hybrid||Speech||Joystick / Analog|
|Network Speed||Slow (EDGE / GPRS)||Medium (3G)||Fast|
|Network Condition||Offline||Primarily offline||Spotty, high latency||Reliable, stable|
The table’s a bit dated now, but it’s generally still a helpful model for me. Because while our designs need to adapt to differently-sized screens, that’s not all we have to account for. A table like this helps me think about the various conditions that might cause my design to change, and decouple those very specific challenges from broad device categories. Not every “mobile” user will see the screen as I might, instead using a speaking browser to access my work—we need to design for them, too. Additionally, I can chat with my team about how the layout might adapt across different screen sizes, independently from how quickly it’s rendering on different network speeds; after all, there are plenty of “desktop” machines with decent touch displays, or perhaps tethered to a 3G antenna.
Personally, the Apple Watch is interesting to me not because it’s a watch. Rather, it’s interesting to me because it’s a smaller-than-normal touchscreen attached to a cellular antenna, and one that’s not necessarily on the most reliable connection. It helps me look past the device, and to think about how someone will interact with my work under those conditions. Once I do that, I can start to design accordingly.