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.<p>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.<p>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.<p>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.<p>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: <a href="https://github.com/dotmaster/Touchable-jQuery-Plugin/" rel="nofollow">https://github.com/dotmaster/Touchable-jQuery-Plugin/</a><p>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.<p>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.<p>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?<p>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.<p>9) Navigation. Fat footer? Starbucks-style expandable list menu? Both? Other?<p>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.<p>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.<p>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..<p>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.<p>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
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.<p>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.<p>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.<p>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.
Interestingly, we asked a related question during Customer Development for our startup:<p>Will You Pay for a Responsive Redesign? - <a href="http://blog.roveb.com/post/15394363841/will-you-pay-for-a-responsive-redesign" rel="nofollow">http://blog.roveb.com/post/15394363841/will-you-pay-for-a-re...</a>
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.
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".