I thought since James posted his thoughts on recent work designing a mobile site, I thought it’d be good to look at it from the other side of the process. I’m going to be writing this article from the point of view that designers design and a developers code; this includes HTML and CSS. It’s not too technical, so don’t panic. If you are looking for a little more technical information, check the links at the bottom of the article.
Dedicated
Hopefully, if you’re a developer building a new site from scratch you’ll be following something akin to the MVC paradigm. If you are, great – this whole process is going to be a lot easier.
The beauty of MVC is thanks to the fact you’ve isolated the output into organised views, switching content based on device type becomes an easy process. You don’t have to make any major changes to your business logic or applications’ core, you just output different content. By detecting the device type accessing your site (by checking the user agent) you can redirect your users from http://www.yourwebsite.com to http://m.yoursite.com.
It’s worth mentioning here that you want to be making smart decisions about forwarding: http://xkcd.com/869/ If you’re going to redirect from your desktop site to your mobile, make sure you’re redirecting to the same page. It’s also worth mentioning that it could be a good idea to reverse this process too: a desktop user may visit the mobile version of your site – do you want to offer them the desktop version?
Assuming you’re still with me here, as you can easily adjust your output by device type and you’re being clever with your redirecting you can get to the actual building of your site. The advantages of a dedicated site are you know the device type you are developing for, so you know it’s limitations and screen sizes. As long as your designers were equipped with this same information you’re left with the easy job of taking your existing, working, applications and adjusting the output to match the design. Frankly speaking, that’s easy.
Of course there are down sides…
With a dedicated site you’re now having to worry about the fact that you’ve got multiple designs to manage. Every page on your site has multiple versions. Your SEO types might be concerned about splitting link juice between mobile and desktop sites. The potential for problems redirecting to mobile content that simply isn’t there become an issue. Then there’s the performance hits you get from processing those redirects (it does add to the time it takes to perform the initial load).
I’ve assumed you’re working under the MVC paradigm, but what if you aren’t? What if it’s a legacy site you’re patching up? What if your HTML is mixed in with your code? Well suddenly it’s a lot more complex and you’ve got a lot more work to do.
There’s also the devices themselves. You’ve got to keep up with the ever changing world of hardware. Mobile devices and the support for Flash is the kind of thing you need to watch for. New devices (and potentially new user agents) are hitting the market all the time and you’ve got to keep on top of things. Throw into that mix that you’re going to need a small army of test devices and I’m sure you’re getting an idea of what a mess you could be looking at.
Responsive
In the long run, responsive design should be the preferred solution. In part because Google recommends this and because chances are you rely on Google for a decent proportion of your traffic. But there are other advantages to this solution.
With a responsive design you’re less concerned with device specifics. There are things you need to watch for of course (pixel density of devices being a good example) but the theory is the viewport (screen) of the device is the key. More information: http://www.quirksmode.org/blog/archives/2012/06/devicepixelrati.html
At a basic level, there’s two approaches to how to handle varying viewport widths…
Firstly you can concern yourself with breakpoints. Specific points between various widths result in different displays of your information. This is the easiest starting point for making a responsive design. Pick a width and make your site work for that width using media queries. You should be able to get the majority of the way to a responsive site by just using media queries and some css magic. You might face issues with how to handle large (well, wide at least) images in your site, but don’t worry – it’s a problem the industry as a whole is facing with no brilliant solution yet.
The second method is the better option. You still work to break points as before, but rather than stepping from one resolution to the next you make the process fluid. Imagine a 320px, 640px and 960px designed site. If you’re just dealing with the breakpoints then your site “steps” from one design to the other as the viewport increases. By allowing fluid widths between the designs (by using % widths for example) you’ll get a much better flow from one to the other. Of course you can only do this if the designs at each breakpoint allow for it.
So what are the downsides of responsive designs? Well you lose 100% control over the output. You can no longer adapt the raw html output depending on device. Depending on what content you’re putting out there this may create a slight awkwardness or lack of context to the content. It’s also more difficult to get right. When you’re targeting specific devices you’re completely aware of limitations, screen, device input, etc… but from a responsive point of view you’ve got to make sure the content works regardless.
This is where you need to start thinking about how a visitor uses your site. Hover events are useless on mobile devices because there’s no cursor. That means the pointer cursor doesn’t show either, so from a user experience point of view that’s gone. Using small links or buttons? That’s going to a problem for someone to accurately bash with their thumb. Small text means pinching and zooming around on a mobile, but too big and it’ll look horrid. You’ve got to be sure your site doesn’t just look good for any device any screen size, it’s got to work with any device and any screen size. Of course the same applies to dedicated sites but in that scenario you decide what controls to output to the device to use.
Conclusion
If your site is flash heavy, I’d consider dedicated so you can deal with devices that do not support flash gracefully. If you’re running a content site (hey like a blog!) then responsive is probably the best for you because your primary concern is the content you produce. A legacy site will be easier to make responsive but if you need granular control of device specific output then dedicated is the way.
This might be an edge case but if you’re producing apps for mobile devices having a dedicated site will more easily allow you to target advertising your apps to the devices your visitors are using. An edge case, but something a responsive site doesn’t easily allow for.
Neither approach is right or wrong. I would say responsive should be the first choice as it has the best long term outlook, but at the same time it’s all going to come down to what’s going to be easiest and/or provide the best results.
More information
- Samples of responsive design
- Starting a responsive design project
- How to redirect to mobile versions of your site
- How to build a mobile site
