Responsive Retrofits

I want to talk about something I’ve been seeing around a lot lately. A phrase that makes my skin crawl a bit when I hear it. Responsive retrofitting. I’ll tell you why…

 

Dirty Words

How many client meetings have I overheard where the conversation gets to what their mobile strategy will be with their old fixed-width site? How many phone calls with our SEO department when the client says that their conversion on mobile devices just isn’t cutting it? How many times have I heard “We’ll just do a retrofit. We can think about a real design later.”? The answer: too many times.

I understand the reasons clients and businesses have for wanting to do this. It makes the client happy. Clients get their “solution” that’s mobile friendly with their new market in mind without breaking the bank or investing the time and energy for a new solution. Businesses get some extra spending money while the client saves up for the next phase which they’ll hopefully come back for. Everybody wins. Or do they?

The people we’ve forgotten in this scenario are the users. They lose. Why? They’re getting a site they can comfortably access now. They should be happy! But, I don’t think they are.

 

Problems with a retrofit

Retrofitting means we’re going to take the current site made for desktop and try to jam it into the mobile arena. That means we could be inheriting all sorts of problems. A slew of fixed-width widgets and elements that need to be converted or otherwise re-laid out (or in some cases cut entirely, which is a bad practice in itself). Outdated or inefficient code, especially if the site was made by another party than your own. Another recent study of responsive sites shows that page weight at various sizes is hardly different for sites that were designed from the beginning to be responsive. How are we likely to fair when we’re retrofitting one where we may have less control or no choice but to keep that weight? User interface concerns are an issue. Some things were made with a large screen in mind and need that space to work as intended. Perhaps the biggest concern is that since we’ve decided to do a quick fix, we may not have the time or budget to address these concerns properly.

All these problems hit the end user. It’s not going to be pretty. A UI from the desktop jammed into a mobile space means awkward side effects to the experience. Performance issues of load times and potential page bloat means slow loading and bad response times, equating to a sour taste of the site (and brand) for the user. That leads to a bad view of the company the user is visiting. That doesn’t help the client’s end game. It doesn’t help your business either, as the client is unlikely to be happy, because their users are unhappy. Worst of all, its a half-assed approach to design. We’re forcing a solution upon something that demands something new. That’s not design.

 

Conclusion

So what do I think we do if we’re able? Simple, wait for a time when the client is willing and able to make a proper solution. Avoid the temptation to try to force the old site to work in a new context. There are probably other problems that need to be solved with the current implementation.

Responsive design is not a bandage for a bigger problem. It is not a quick fix. It is not just an add on option. Responsive design is a technique and a new way of thinking about our sites. You’re potentially doing more harm than good when you retrofit.

Proper responsive design (and I’d argue design in general) is not easy. It takes planning and coordination. It means thinking ahead on the goals of the project and about all the literal shapes it could take. Most importantly, it means taking all these things into account at the beginning with all interested parties. Only then will you be able to provide a solid, well thought out solution to the real problems your client faces.

Update: There’s an article out today that was posted through Smashing Magazine’s Twitter. You can read it here. A lot of it is more the “how-to” of doing this, but there are some great points (especially near the end) in the article. Basically, if you must do a retrofit, be sure to take multiple factors into account before you reach that conclusion. The “Pitfalls to Avoid” and “Things to Do” make a good quick checklist of things to consider if you’re thinking of doing a retrofit. Many of the pitfalls are similar to points I’m making above. Watch out for these when deciding if it’s the right thing to do. It will depend on the constraints of the project.

I also think it makes a good point that something is better than nothing in many instances. I’d like to add an addendum to that saying that a responsibly made something is better than nothing. Don’t just throw queries on it and call it a day. Be responsible and consider the performance, usability, and continuity issues between devices, browsers, and screen sizes when doing your retrofit. Here’s another article from Smashing that has a good list of approaches as well as pros and cons for each  if you’re considering a retrofit.