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?


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.

  • I'm not sure I'm following your question. Can you clarify a bit more? You talk about how responsive web design uses views based on the type of device they're on. But you then continue suggesting that vary idea as though it were your own. So I'm not entirely sure what it is that you're asking. If you are wanting to know more of what types of frameworks are available to help you lay out your website based on different user agents / device profiles, you may want to rework your question to state that. As it is, it's very ambiguous and hard to answer.
    – kenzietech
    Aug 27, 2013 at 21:28
  • 1
    Your scenario does not make you site responsive. To be responsive, you have to account for all screen sizes, not devices. It is supposed to adapt to the screen size fluidly. In your scenario, your layout does not adapt to the screen size fluidly. Your scenario needs to send a request back to the server to create a new page.
    – DFord
    Aug 28, 2013 at 0:36

2 Answers 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.


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.

  • Yeah, that's what I meant by device - not "iPhone" or "iPad" or "Kindle Fire" but device dimensions. Aug 27, 2013 at 21:32

Take a look at Sencha 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!

  • Sencha touch is a mobile app framework. The question is about responsive web apps. Also you don't address how it relates to MVC.
    – Matt S
    Aug 28, 2013 at 15:11
  • Sencha Touch is a mobile web framework. You can take that a step further and make it a mobile native app using either Phonegap or its built in compiler. But by its very nature it is a web app framework. Go to the link I put and look at what it says on the top: "Sencha Touch Build Mobile Web Apps with HTML5" And that's exactly how it relates to MVC. It abstracts the nitty gritty detail out of the needs of the developer, and relies on the framework to deal with the determination and the layout of the view, based on the criteria and configuration you give it.
    – kenzietech
    Aug 28, 2013 at 16:11
  • The first sentence on their website says it's a "mobile application framework" to "build powerful apps". I may be misinformed but I'm just reading their site.
    – Matt S
    Aug 28, 2013 at 17:28
  • It's a matter of semantics... It builds HTML5-compliant web apps, and you can then expand on that by generating native device apps.
    – kenzietech
    Aug 28, 2013 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.