I recently sold Responsive Design to management at work and, excitedly, we will begin working on transitioning one of our sites within the coming weeks. As I read more and more into the responsive design process and bring developers up to speed with the new user interface, I began to pose some questions to myself. I feel it just resulted in even more questions but perhaps some other people in the great Internet universe may have some answers for me.
How do you maintain a DRY code base?
After I tried a couple different approaches to a responsive design, I finally landed on Twitter’s Bootstrap to putter around with. While it’s great to *cough* bootstrap with, it’s in no fashion to be the be-all end-all user interface CSS — you will end up hijacking the code and inserting crazy stuff in it and you would be much better off just starting from scratch for your own web-app.
But how do you maintain DRY code? There are more way to skin a cat, and even more to accomplish the same thing in CSS and JavaScript. How can you prevent other designers and front-end developers from re-inventing the wheel over and over again whenever they make one small edit to the UI?
We did a huge overhaul to just one section of our website, and when the project started I wrote a clean piece of Sass for the developers to use, and by the time the project was done, it was cluttered with repeated and unnecessary styles. I can only imagine it will be 10x worse with a responsive designed website.
How do you organize your code for the multiple experiences?
That being said, how ARE you supposed to organize your code then for these multiple experiences? As far as IDEs go, there are not many (if any) options for CSS out there that can deconstruct your CSS and find duplicated styles and tell you where you can optimizer your code. (If there are, I haven’t used any.)
How to debug with multiple experiences?
We only have 2 people in our QA department and it already sucks time away from them when they need to test features in all the major web browsers and their major versions. Which devices should they be testing on? How much complexity is added with each new screen resolution that you add to the code base?
When I developed my proof of concept, I developed on a Mac with Chrome, Firefox and Safari. I never even took a look at it in Internet Explorer. When do you say “I am only going to support until version X?” You could easily dismiss browser eccentricities and say you should only design for resolutions, but that’s hard to explain to a client when they go to use the website on their respective computer/mobile device and finds out it doesn’t work.
How do you instruct developers not as familiar with front-end development?
As stated above, we had a fairly small development team and after a couple of months of development, even though I had instructed my teammates that they didn’t need to condense the styles into one-liners because we had the Sass compiler do it for us, I was still finding unreadable code in the code base. How do you bring everyone up to speed? It seems with responsive design and more complicated design methodologies, it’s harder for the everyday “coder” to be up-to-speed on all the new jazz with front-end development too.
So those are my current gripes. It’s not going to prevent me from using responsive mobile design at all, but I imagine it will cause some headaches down the road while everyone is still trying to figure out exactly the definition of what responsive design really means.
