I’m involved in a project for a redesign of an existing site. The Designer Team delivered us -the Engineering Team- four separate HTML/CSS prototypes of how the site should look:
- On a Desktop Browser.
- On a Table Device, a similar but simplified design of the Desktop View
- A High-Tech Smartphone, the design is mobile-app like and very different from the Desktop and Tablet designs. Also, less content is shown there.
- A Low-End Smartphone, a simplified version of the precedent design but still very similar.
My first impulse was build one HTML/CSS prototype using Responsive Web Design, and merge the prototypes made by the Design Team, but now i’m having some concerns:
- Merging disparate prototypes might produce low-quality code.
- We might be sending code/files to some mobile devices that they don’t need.
- We need to handle the situation where -for example- some option must be present in Tablets but must be hidden in Smartphone. Using CSS to hide can be bandwidth waste, so maybe there’s a need of some server side code.
Because of that, the idea of building two different Web Applications -or even better, handle two Views in a same web application using some server side Framework like Spring Mobile- was being considered. I am not an expert on Responsive Design, so I wan’t to know what’s the best approach is this situation or the standard way to tackle this problem.
PS: If it’s worth saying, I’m building a Portal using WebSphere Portal as Portlet Container and building the Portlets using Spring Portlet MVC.
I would follow your first impulse and go responsive – I feel that when implemented properly it makes for a better user experience. Use a responsive CSS library and some javascript MVC frameworks/templating libraries to do your heavy lifting on the client side.
Addressing your concerns:
Low Quality Code from Handling Disparate Prototypes
I think using battle tested JS and CSS libraries and best practices should help you here. Think along the lines of backbone, knockout or angular to provide your clientside code with structure.
Sending Unneeded Code Files to Mobile Devices
I don’t think this will that big an issue. Build out mobile functionality first and go from there. This will ensure you get the core functionality created and allow you to build out to the bigger devices from there. Use only the bare necessities to keep things light. If you use templating engines you can reduce the amount of HTML you’re sending over the wire. Combine and minify JS and CSS files on the server side to minimize what you’re sending to the mobile devices.
Wasting CSS when Hiding HTML Elements
Use a templating engine. These can either be built into the clientside MVC frameworks or separate (Mustache, Handlebars). This will prevent you from sending over too much extra HTML. Additionally, you can lazy load certain sections if that floats your boat.
Conclusion
A well thought out Responsive Web Design should be capable of either avoiding or minimizing each of the issues. A lot of work has been done in the open source community to help negate those problems. I would highly suggest searching out those solutions and seeing if they are helpful with your project.
Its your team’s decision in the end, but make sure you consider the vast number of libraries and elect for the best user experience your team can support within the non-functional requirements (timeline, cost, staff knowledge) of your project.
Popular Libraries
JS MVC: backbone + templating library (see below), Knockout, Angular, Ember
Templating: Handlerbars, Mustache
CSS: Twitter Bootstrap, Foundations, Skeleton
Minification/Combination Tools: Yahoo YUI, UglifyJS
Miscellaneous JS: underscore, require
These are the examples I hear the most about. I’ve personally used Knockout and Twitter Bootstrap. I’m looking to play around with backbone and Foundations as well though. There is a lot of research to do in this area and not really enough space in a single answer. I think if you start researching these libraries and tools you should find plenty of information to get you to the right endpoint.
2