Responsive Web Design shows the user different elements — or elements arranged in different ways — by using media queries (if the device is a desktop or laptop, show them this; if a tablet, show them that; if a “phone,” show them the other thing) or other methodologies.
What about, though (especially if your app/site uses MVC anyway), leveraging MVC to return different Views based on the type of device / user agent?
Each Model/Controller pair could have at least three Views (desklaptop, tablet, phone, as well as perhaps more granular gradations and/or Views tailored to larger devices) and, based on the size of the user agent’s real estate, invoke the appropriate View.
I’m thinking this might be a more natural and easier to implement way of optimizing the experience for all users, at least for those conversant with MVC. How exactly this is implemented (how the user agent is determined and the appropriate Controller ActionResult is invoked) I’m not sure, though… thoughts?
UPDATE
Response to the comment and answer:
I’m thinking more along the lines of this scenario, for which, IMO, media-queries won’t satisfactorily handle:
Your app/site has as its centerpiece a map. There are ancillary but vital pieces that are placed around the map (top, botton, and side) that all fit on a tablet (barely) and larger devices just fine. On a phone, though – no way – there’s only room for the map, and even then the map is almost too puny.
The only way I can think of to deal with this is to show the map full-screen on the phone, with buttons or links in states like Wyoming, Montana, and Nevada that will invoke the parts that surround the map on larger devices but will monopolize the screen on a phone. In each case, the currently displaying View will need links to [re]open the other portions of the app/site.
Otherwise, the only way it could be usable with a phone is if the user is carrying a magnifying glass around with him (or zooming and swiping around the screen like a madman, but IMO that’s a pain in the gluteus maximus).
And so, in such a scenario it seems to me that Views would be easier to implement than altering the CSS, as this is a major renovation of the screen, not just a rearranging of furniture.
2
I implement responsive design by viewing width, not device or browser type. This way it’s future-proof and useful in unexpected scenarios. For example, when a new phone comes out with a huge screen and resolution my sites will still be optimized to use it well.
Also, my HTML is identical for every device / resolution. In the MVC architecture only my CSS is responsible for the responsive design. There’s nothing on the server side which cares, making implementation much easier. The only possible advantage of pushing some of the work into your controllers might be to not prepare data which isn’t visible on smaller screens, but this is rare in my experience and not worth the added complexity. Then add the fact that browser / device detection is unreliable and you’re introducing bugs.
To summarize, responsive design is only a responsibility of the view in MVC, and then it’s best handled by just CSS.
UPDATE
In response to your update, your issue is still confined to only the view. You could still solve this example with only media queries and javascript. You could also break up your HTML into components that load separately. But your site’s basic functionality is unchanged, keeping your model, controller, and most of your view the same on every device.
Also consider that on an HTTP request to your web app you don’t know the resolution of the screen. You could load an empty page, then use JS to get the current resolution, and AJAX to load the rest of the page (with screen res as a parameter), but that’s inefficient and would have to be rerun on every page resize.
1
Take a look at Sencha Touch.
http://www.sencha.com/products/touch/
It doesn’t tell you exactly how to do it, but it implements a very powerful version of “profiles”, which utilize not only the screen size / resolution of your device, but also the type of device (ex. tablet, phone, etc.), and the OS of the device (Windows Phone 8, iOS, Android, etc.) and caters the layout to that of your device.
It’s much more powerful than just attempting to build a website utilizing CSS and Media queries to determine what to build, where to build it, and if to build it. Granted, I’m sure it utilizes a wrapper to wrap a lot of those functions and abstract them away from the developer. However, it provides a nice, clean, easy way to build an application that spans over multiple different devices and types of devices.
In the case of your map example, you could implement something similar to that in Sencha Touch so that on a larger-screen device (tablet, or even an HTML5 compliant desktop browser) has a fullscreen viewport defined where the map takes up the bulk of the screen, with a navigation bar docked to the left side of the screen with your various critical functions to choose from, and a possible navigational structure on the top. If you want to move this to a smaller tablet (iPad Mini, for example), you could drop certain parts of the navigation out of there so that it doesn’t take up needed screen space, but could be accessible instead by a “menu” button that overlays the corner of the map, or slides up from the bottom via a hidden docking bar.
The options are really endless with what you may want to do. I think the best bet though would be to utilize some sort of framework (you don’t have to use Sencha Touch – it’s just what I use and like, but I’m sure there are plenty of other good options out there), so that you don’t need to go through the work of reinventing the wheel and attempting to do this type of thing yourself. Overall though, I think you will definitely want to go with a solution that much more provides you with functionality above and beyond simple CSS rules and/or JavaScript/jQuery.
Good luck!
4