How much does a responsive web design cost? | Hacker News Reader

How much does a responsive web design cost?

bradfrostweb.com

40 pointspulleasy17 comments

Some notes of guidance from a recent recode and redesign (which included making the site responsive / mobile web friendly) of a site with a medium-sized code base. YMMV.

1) Test multiple versions as you go. If you're targeting, let's say, three widths (320px, 321-999px, 1000+px), whenever you make a change, test it in all three. It can be frustrating at first, but it can save you a lot of trouble later.

2) Use a service like BrowserStack, which will relieve you from having to possess each piece of hardware/browser combo and from running (sometimes slow) device emus/sims locally. Extremely handy, and will probably save you a lot of time and annoyance.

3) Keep in mind device orientation. What looks just fine in landscape may look squished in portrait, and what looks just fine in portrait may look like it's lost in the big empty in landscape. Percentages may be your new best friend in responsive-land, but you still may need to tweak anyway.

4) Think about places where the direct handling of mobile gestures make sense. Things like slideshows and such work well here. Touchable (requires jQuery) is helpful here for a low-impact solution: https://github.com/dotmaster/Touchable-jQuery-Plugin/

5) Remember that things like the "hover" event don't work (yet/ever) on touch platforms, so if you were relying on that to signal something, you'll need to change your signal to something clearer for that environment.

6) Think carefully through interactive elements, especially ones that rely on 3rd parties. Your map-based application will likely need a bunch of work. Your giant sidebar widget for showing the latest posts on FaceTweet+ might need to go.

7) Mercy for those on 3G (or worse.) Not every person is going to be on a nice quick Wi-Fi connection, so think carefully about which files (images and scripts, mostly) you'll need and how you'll load them. The responsive image battles are still simmering, so you do have some choices to make, all of which involve at least some degree of ugly hackery (multiple sizes with server-side selection? Demand-loading via AJAX/AHAH?) Same goes for extra JS - are you really going that fancy animation or 500k bottom bar?

8) Ads. If you've got 3rd party advertisers/sponsors, you probably want to check if they have appropriately sized ads for you. Both scaled and down and scrollbar-forcing ads are no fun at all.

9) Navigation. Fat footer? Starbucks-style expandable list menu? Both? Other?

10) Fingers! 8px between elements rule-of-thumb is a good starting point. It may look great, but if people are tapping the wrong things constantly, they'll get annoyed.

HTH

For a web developer creating a website these days by himself it's starting to get daunting, there's so much things you need to consider that you really need to start working with other people if you want to get your project running in a fair small amount of time and have a solid project.

Today you need to consider: responsive design,javascript frameworks, css frameworks, LESS, websockets, nosql vs rdbms, server-side frameworks, good quality design, good UX, cross-browsing etc..etc..

Back in the old days we didn't consider or even thought of half of this, not that it was better, obviously not, but most of us learned gradually. I would hate to be a programmer and have to start learning all of this from scratch :X , the entry barrier is much higher now, it's sad.

On the other hand, mobile apps don't have all this fat around, you can easily build an app by just using the APIs and focus on design and UX

You're glossing over the fact that for mobile apps you need to develop a separate app for each of the major mobile platforms out there, using a different toolset, process, and language for each one. Surely that's no less daunting than dealing with browser compatibility as a web developer.

I'm curious if you've ever done any mobile app development; You most certainly have to think about frameworks, design, different devices (especially on Android, where your app may be launched on any of a myriad of varying screen resolutions and sizes and densities). You still have to do quite a bit of non-straightforward work in order to create an app that is "responsive" to the device's size.

To be honest I was talking just about iPhone development which is the main mobile device to code for atm.

And yes, while you have to have responsive app (iPhone, Ipad, vertical/horizontal), you pretty much have the framework (cocoa) do all the heavy lifting for you, you don't have to worry about you content being viewed in a different device or other OS.

The Android on the other hand I got to agree with you, but Android itself is the Internet Explorer for mobile apps. I'd hate code for an android device as well :P

> nosql vs rdbms

Why not use both? For example, store your session info in redis, but have it refer to user data which is in the DB. This effectively turns it into a cache to make short-lived data cheaper.

That is what I've done at a few projects for work. Worked quite well.

I can't stress enough the truth in what he says about ongoing maintenance costs being higher when launching a site with separate codebases for different screen sizes. This is really what sells responsive sites in my opinion: Focus.

Have two versions of your site? When you integrate a new feature you have two sets of problems. Two sets of tests. Two sets of, well... everything.

This is almost doubly so when it comes to content strategy. With two versions of a site it's often been my experience that one or the other (usually mobile, but I expect that to change) starts to count as little more than an afterthought and tends to degrade over time. A single responsive codebase really forces a lot of tough content questions to be asked and allows a simpler path for those problems to be solved.

This isn't to say that you shouldn't do what's best for the project. A somewhat hybrid example is what NPR has done with their native / web app ecosystem. Their content is often being pulled from a single data store and brought into different presentation layers (native mobile apps on devices, HTML on the web) as needed.

"A single responsive codebase really forces a lot of tough content questions to be asked and allows a simpler path for those problems to be solved."

Sounds like approaching the problem from the wrong direction. The primary ingredient of a site is the content. The content informs the design. The moment the design forces the content is the moment the design fails to be a design, and probably becomes decoration.

If the content is conducive to a responsive design, by all means consider a responsive design. But if the content isn't conducive, don't force it into a responsive design.

How many other people played with the width of their browser immediately upon following the link?

Interestingly, we asked a related question during Customer Development for our startup:

Will You Pay for a Responsive Redesign? - http://blog.roveb.com/post/15394363841/will-you-pay-for-a-re...

From your post "Update 17 Jan 2012: Of the top 100 sites most visited on the internet, 71 of them have content specifically designed for mobile devices." -- I feel like websites with extremely large budgets (top 100) would currently be best served by mobile specific sites because they don't have to worry as much about the costs of updating/testing multiple different sites that most others do.

That being said, as the number of different mobiles devices quickly rises it will soon become near impossible to maintain a mobile site specific to every device.

One thing I wished the article addressed was the usability of responsive sites vs. dedicated mobile sites. In the majority of cases, I find dedicated mobile sites more user friendly on smaller (smartphone-like) devices than most responsive desktop sites.

I much prefer "responsive" Web pages to "mobile" sites. Many "mobile" sites cram way too many flashy graphics and bloated scripts into the client; compound that with features that disable zooming, and you have a UI disaster. Finally, don't forget URL fragmentation because of the "m.inane.com" nomenclature. "mobile" users then link "desktop" users to the "mobile" site, which is unnecessary.

Nonetheless, we're probably both guilty of selection bias.

The trade off, is, well, now you need a dedicated mobile site. Subsequent changes to your codebase suddenly require twice the effort, since you're changing two different sites.

No, every change to a responsive site can break other resolutions/media queries without your knowing. Or do you routinely view your site on an iphone, Android, ipad, Kindle, netbook, laptop, and 30" monitor?

You're claiming responsive comes for free, or is no harder than purely non-responsive. Definitely not true.

Responsive design means that the flight to themes/frameworks will only increase. The effort to develop & test is doubled and relying on a foundation is no longer a "nice to have".

Reply on news.ycombinator.com