3

I am working on a project that will add considerable new functionality to an existing application. We were previously limited by a framework that did not (realistically) facilitate responsiveness, so everything that was build up until now was not responsive in any way. For the current project we have two seemingly contradictory goals:

  • Integrate our features into the wider application, including a lot of navigation across the different sections (i.e. from old framework to new, and from new to old)
  • Make the new section "responsive"

Frankly, the idea of making the new features fully responsive seems like a terrible idea, since as they navigate through a single application, they would be seeing wildly different views when using smaller devices: This is a mockup of a task flow that touches both responsive and non-responsive pages.

Does anyone have any experience in a transition like this? Are there any examples of making certain modules or areas responsive, with the rest not?

  • I found an article that speaks to this topic that has been helpful, in case anyone else runs into this issue: webstandardssherpa.com/reviews/responsive-retrofitting – Rath_Er Mar 31 '15 at 23:35
  • We're in the same boat. I have to agree with you, making something 'half responsive' defeats the entire purpose of being responsive in the first place. – DA01 Apr 13 '15 at 16:12
2

If I'm on a mobile device, and 0% of your site is responsive, that's a detriment to the entire experience.

If 20% (your new features) are responsive, at least 20% of your site is now easier to use.

Granted, that likely now makes the 80% that isn't responsive that much more frustrating in comparison--but maybe that's a good thing as it will push your company to redo the entire site.

  • I don't think that is necessarily the case. Introducing an inconsistency in interaction model for different sections of the app would lead to a jarring experience AND be disorienting. If the header/footer and navigation all were modified to work well on the responsive sections of the app, it would be really hard to track whether you are in the same app or if you had been navigated away. And I should mention that there is essentially no way we will be able to redevelop the other portions any time soon, so any inconsistency would be baked in for at least a year, if not more. – Rath_Er Jan 16 '15 at 23:27
  • 1
    It'd take jarring and disorienting over not usable at all--assuming the current site is a pain to use on a mobile device at the moment. But if the current app is a lost cause anyways, then maybe it doesn't matter. Stick with the way it us until the redesign. It's just that I rarely see those "we'll make it responsive next year" promises come true. As such, one could argue that for the long run, a jarring experience now is good--as it will encourage the complete redesign sooner than later. But that's all a strategic decision more than UX. – DA01 Jan 16 '15 at 23:45
2

Consider setting up a subdomain url which points directly to the most significant page of your new responsive functionality. This will give your mobile users easy access to part of your software which is ready for their use.

Alternatively, you could add some onload javascript to your main application's home page to check the browser's screen size; if it detects that the browser is a phone, redirect to the most significant page of your new responsive functionality.

With either of these techniques, you are effectively dividing your program into its phone-friendly parts and its phone-antagonistic remainder. Non-phone users will still be able to reach both parts, while phone users will only see your new code. Then, as time allows, you can make your legacy pages more responsive, effectivley moving them over to the phone-friendly side of your offering.

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.