- March 26, 2015
The Wearable Web
- @markhuot
- Development Director
There’s been a lot of talk recently about experiencing the full internet on the latest and greatest device class, namely our watches. Apple’s exclusion of the Safari web browser on their watch has many people up in arms. “It’s the web” people say, “it should be accessible anywhere,” they scream.
And while that’s all well and good I can’t help but think we’re approaching this all wrong, failing to learn from our own mistakes.
Some History
Best practices seem to be a pendulum of overreactions. Do the following sound familiar:
2004: Why is there no m. site? This is awful…
2015: Why am I on an m. site? This is awful…
What hindsighted absurdity will the latest device class add to that list? In 1999, our devices needed a dedicated experience that was optimized to their performance. In 2015, we have powerful devices that demand the full experience. In 2026, what sort of devices will we have access to? What sort of demands will they make on the internet?
If mobile sites were one extreme and responsive sites are the other extreme it stands to reason the next swing of our pendulum will move us back towards mobile sites. Keep in mind, the longer our pendulum swings the closer to the middle we’ll get.
Today’s Web
Sure it sounds great that I could theoretically access vox.com on my desktop, mobile, and watch – in each case experiencing the same content and commentary regardless of my device. But is that really the experience people want? Is that really the experience people need? The watch makes a case that the full internet isn’t what you need on your wrist. vox.com on a watch screen at 312 × 390 could be upwards of 50 pages long1. That’s a lot of scrolling. Maybe there’s a better experience that does more than shuffle content around. An experience that actually presents a different selection of content?
This all sounds like the internet of the 90’s doesn’t it? I can already hear the responsive townsfolk revolting at the very idea of a device-specific experience. But that’s not what I’m arguing for. That’s the other extreme, let’s not go there. But let’s not be afraid of it either.
What’s next?
There’s a middle ground somewhere that provides the user a choice of experience without removing anything from their reach. The failing of the m. era was the complete separation of the mobile site from its desktop counterpart. Features on one site that weren’t on the other. What technology is beginning to offer today is a responsive experience that extends to the back-end. With responsive checks and balances on the server we can offer the user more choices without overwhelming the front-end with every possible option. That could mean a special “headlines” page on vox.com or a “scores” page of espn.com optimized for those really, really, small screens (without isolating them from their desktop counterparts).
Some really smart developers are starting to make this a reality by blurring the lines between front and back-end technologies. Chris Coyier has been doing it in production over on codepen.io for a while now and it works. Taking responsive design to the next level allows us to offer up that single code base, the one design system, with the possibility to package it differently per-device.
[1]: granted the same page on a phone is still upwards of 20 pages of scrolling, so we’ve probably already conditioned users to expect the scroll.