No Silver Bullet, Chapter 57
Responsive is the new black.
Responsive is the new black.
There’s a lot of responsive in the air – responsive design, responsive content, this post – but there’s also a growing set of misconceptions that agencies are hearing in discussions with clients. The next phase is, naturally, the backlash. It might be worth taking a deep breath before then, and trying to make a bit more sense of what it is and what it helps you with.
How Was It Really, Pops?
In the early days of the web it was easy – you picked a screen size, wrote that into the requirements, and coded away. Once mobile browsers started to leave the WAP era (jeez, remember?) and started to support HTML, designers found themselves with a ton of different screen sizes, varying support of CSS and HTML tags, and a clamor to support them all. Borrowing an ancient technique from UNIX (all rise! OK, be seated), we developed device profiles, which were basically a hardcoded set of device characteristics for each and every mobile device, stored in a database. Our server pages would detect the user-agent from the request, decide which device it was, pull the profile, and then – perhaps – accommodate the unique screen size and capabilities of the device.
It was an expensive drag. You basically punted the unpopular browsers, because you generally ended up writing custom server code for each device profile, and that was a pricey and unmanageable mess. You could get some reuse if you were careful, but since no one was really thinking in services then, it ended up as bits of code scattered around. The “m.site.com” URL style started around then, because it allowed you to make one decision – it’s a mobile browser – quickly, and you could segment your code and servers.
Cool! So, responsive design lets me code once and run everywhere and support everything forever, right? Ponies live!
Um…not quite. At a base level, you’re still adapting experience across multiple devices, writing code, and expecting it to work across multiple devices. You can’t get away without thinking how it’s going to work across those devices.
Squeezing the Tube
Responsive design is not a silver bullet. In technology solutions, there is always complexity – you just design where in your system you put it. You can decide what change you want to make easy in the future by designing to embrace that change. In some important ways, it’s less about the interesting coding approaches, and more about your entire approach to delivering the brand experience.
You decide what part of the system you want to spend your energy (time and money) on. Generally, in marketing, you don’t want to spend all your time rebuilding your server systems, so you should make those as simple and service-based as possible. You do want to spend time creating great new utilities and services for customers, so you should make those front-end systems as adaptable, and re-useable as possible.
That’s where responsive design comes in. It opens up the possibility of designing experiences that can adapt across the multiple devices customers are using, and leverages modern browsers to push code reuse and innovation to the presentation layer. But it doesn’t remove the need to make design decisions and investments – it just helps to shift it to the right places, in services in the backend, and design decisions upfront and closer to the device.
By taking a more systematic approach to how your web experience shifts and adapts across multiple devices, it also starts you thinking more about building design systems rather than styling pages. It asks you to think about your brand, and how that adapts and responds across multiple user contexts, and the devices that support that context.
Well, OK, I’ll think about that – but I still get a mobile site for basically free, right?
How Hard Can It Be?
It’s always going to take more effort and cost more to carefully architect and code a site than it is to crank out something. A responsive design site is going to cost more than coding up a plain old website.
At a simple level, you still need to decide what screen sizes you’re supporting, and how it will look across those screens. More deeply, if you’re making modifications to features and functionality – showing some content here, less on a phone – you need to design and wireframe up how that works. And if you have a reasonably complex services design you’re thinking about supporting – in-store integrations, mobile location-based services – the more your experiences will diverge, and the less responsive design may help.
Then you need to code it. Never as fast as one would like, right? And like I said, it takes a bit more coding and testing to make it responsive.
It doesn’t get you out of testing across the devices you’re targeting. There’s enough quirks and “emergent behavior” in the various implementations of WebKit to keep your developers gnashing their teeth.
The labor costs a bit more too – not many offshore or low-cost dev shops are fully up on the latest technologies here. The tools are not quite as mature as existing website tool chains.
Finally, the current state of play in HTML5 is that it’s not going to have the polished, smooth animated actions of a native app. That’s OK for a wide variety of applications, but you’re not going to get the full pizazz. Responsive is not something that helps with this problem.
Oh…so, Why Do I Want It Again?
There are great reasons to work with your agency toward designing and developing responsively:
However, it’s probably overkill if:
Responsive design (and coding, and content) is a rapidly developing field, and tools, techniques, patterns, and libraries are going to make it easier to build responsive web properties. However, it’s not going to allow you to target lots of screens cheaply – but it will push you to think more deeply about how you’re delivering your brand to those screens, and give you the opportunity to put your energy and money into where it will do the most good for the user – their experience of your brand.