There’s been debates up and down the internet about the pros and cons of responsive vs adaptive vs native apps, so it’s easy to get bogged down by buzzwords and semantics. Instead, answer some fairly simple questions about real choices and whether to use RWD will answer itself.
How many layouts will you design?
A few years ago everybody built sites on a 960px grid, and probably most still do.
Designing 3 widths that correspond to “mobile”, “tablet” and “desktop” views is a common approach, though the lines between them are increasingly blurry.
Grids: fixed or fluid?
Giving your layout fixed widths suits the static tools used by most designers and allows for pixel-perfect development.
Fluid grids and elastic design; swap pixels for percentages and make your design stretchy!
How are you going to work out which to show?
Show the exact same content to every device, regardless of size.
Tweak styles, typography and layout with CSS media queries and use feature detection to pull in richer content when the browser can handle it.
By detecting what devices are being used you can infer screen size and capability, however this needs to be done on the server side: serve up entirely different code depending on the kind of device your customer is using
Responsive might be the new shiznt, but it’s not what you’re looking for. On large screens your content will sit in a centred column, and on small screens zooming and scrolling is necessary.
Classic Responsive Web Design
You’re looking at using a simple layout with some CSS tweaks that’ll elegantly flow into any container that the web of things can throw at it. Consider capping your design at high and low widths, so things don’t get unpredictable at either end of the scale, and be aware that the fluid nature probably means you’ll want to design this partly in the browser. This is a popular choice for mobile-first design or simple content sites like blogs.
Given you’ve only got a single fixed layout to display, there’s probably no point using device, width or feature detection.
Although media queries can be used to tweak styles, if you’ve got one design you’ve got one set of mark up so there’s little point in a server side solution.
Your super-stretch approach predates RWD, but using a fluid grid means at least partly designing in the browser, and depending on your content things can get strange on very narrow and very wide screens, so it’s so probably only useful for a very masonry-like or image-heavy grid layout, lest an awkardly long word break your layout.
If you’re trying to show multiple views you’re going to have to distinguish which are to be shown where, for example by detecting width, browser features or devices.
Server side solutions
Is your site just too heavy to work on a phone? Does it have radically different requirements between desktop and mobile? Serving up different sites to different devices can be a legitimate mobile-friendly solution. However it’s a tailored back-end solution instead of a front-end one-size-fits-all, so it’s not responsive. There’s a few downsides to this approach: it requires a list of all devices which requires constant expensive maintenance, it’s trickier to maintain content parity due to different codebases, and you’ll likely have doorslams as desktop links are picked up on mobile browsers or vice versa.
Also it should be noted that the separate sites might themselves be responsive, for example an “m-dot” mobile site might work on both mobile and tablet devices.
Modern Responsive Web Design
As far as RWD is concerned you’re doing everything right: combining two or more layouts with CSS media queries and progressive enhancement for a rich device-agnostic solution. It’s not easy though, the fluid sections that go between static designs should be designed in close collaboration with the designers. Alternatively abandoning the outmoded page-centric approach and instead design modules with a separate content hierarchy and design the layout directly in the browser!
Mind the gaps!
Targeting certain “best practice” widths that in today’s device-rich market are essentially arbitrary is risky. New form-factors and screen resolutions arrive regularly, they all need to work in portrait or landscape, and there’s already a lot of overlap between mobile, tablet and laptop. It’s fairly likely that a given device won’t your target widths and you’ll need to zoom or scroll as with a single width site.
The plus side is little-to-no designing in the browser, but a semi-fluid approach would be more extensible.
CSS media queries changes up the layout and typography depending on browser widths; there are many examples of media query driven sites, one of my favourites being The Great Discontent. The caveat is that it’s not suited to serving different content or radical redesigns as everything needs to co-exist in the page simultaneaously and reliably, so can be expensive in terms of developer time.