

How much does a responsive web design cost? - pulleasy
http://bradfrostweb.com/blog/web/how-much-does-a-responsive-web-design-cost/

======
digisth
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

------
phatbyte
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

~~~
marknutter
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.

------
binaryorganic
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.

~~~
Isofarro
"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.

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

------
nreece
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...](http://blog.roveb.com/post/15394363841/will-you-pay-for-a-responsive-
redesign)

~~~
rileyt
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.

------
misterbwong
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.

~~~
jmduke
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.

~~~
bronson
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.

------
CubicleNinjas
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".

