I'm wondering how responsive design plays along with the Separations of Concern principle, in respect of how we're allowing a single implementation behave for multiple presentation devices (mobile, tablet, browser sizes etc.). Is it breaking the principle?

If I make changes to a web page that I know is behaving responsively and should work on 5 devices for example, am I not making the development extremely difficult due to possible regression that can occur from a single place in the software?

Sure it's making me write less code and work a lot faster on multiple devices, but now each one of my pages requires potentially much more thorough testing, which is the cost I could move to not using a responsive web framework and maintaining separate implementations of a page.

  • Are you asking in terms of responsive design for the UI? – DFord Jun 20 '13 at 14:24
  • 1
    Yes. Responsive UI design with frameworks like Boilerplate, Bootstrap etc. – Martin Blore Jun 20 '13 at 14:42
  • 1
    it's only a violation of SoC/SRP if responsiveness is handled by more than one layer/component – Steven A. Lowe Jun 20 '13 at 20:07

How you're currently looking at responsiveness goes against the separation of concerns principle. Your question presumes that responsiveness is a single responsibility that only belongs to one component.

I'd suggest that responsiveness is an attribute / responsibility that can be applied to multiple components. For the sake of my example, I'm assuming a generic MVC | MVP | MVVM type pattern.

The View most certainly has a hand in the responsiveness of the application. The UI elements and logic that you use all dictate how the View will perform. So the View is responsible for the responsiveness of the UI elements.

The Controller also has a hand in application responsiveness. The types of data structures and how the business logic is crafted will affect performance. So here, the Controller | Presenter | ViewModel also have responsibility for responsiveness. But this responsibility is over different elements than what the View is responsible for.

Finally, the Model is responsible for the data access / service calls. There are obvious performance considerations in how the data is retrieved and presented to the middle layer. But again, this is a different element that must also be responsive.

Responsiveness as a property is not the single responsibility of any one component. All components must be responsible for their own crafting in order to contribute to the overall application. A great UI and Controller can be rendered useless by seemingly interminable data requests.

As far as testing, using a tiered approach still works in your favor with respect to overall effort and responsiveness. If you have 5 devices and wrote individual layers for each device, you would have 15 components to test. Using the MVC* pattern allows you to remove 8 components from testing since you have a common Model and Controller. If those two layers perform their share of the work in being responsive, then you only have to test them once. You can then focus your remaining efforts on the 5 Views.

  • Thanks for this answer Glen. I hadn't even considered Responsive Design beyond what I'm thinking is just a Web UI framework. – Martin Blore Jun 21 '13 at 12:38

I do not think it violates separation of concerns since the CSS uses media queries to separate the style for a particular screen size. The media queries encapsulate the code for a particular screen size.

I think, instead of thinking about responsive design as working for X number of devices, responsive design should be thought of as working for all screen sizes. Its the same web page, just styled to the screen size.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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