Responding to Responsive Design – how my workflow is changing
“We’ll just make it responsive” – this is something I hear more and more, and when I hear it, I shudder slightly because I don’t really know what it means.
I’ve read lots of articles, used the approaches that are recommended. Implemented pages and sites that use the approach. But I still have this niggling doubt that I just don’t know what I’m doing.
It just seems to be so haphazard, that you implement a design and then see when it breaks… then fix it up. It just doesn’t feel very clean.
It also seems like there’s so much more work to do, so many browsers to support on many different platforms, and an ever growing set of resolutions.
Everyone is jumping in to do this, but no one seems to have stopped to plan how, or what the implications should be. Is Photoshop the best way to design this way? how can we test on so many devices and platforms?
I’m writing this article at a point where I feel that the penny is starting to drop, I don’t have all the answers but I think I can finally start to see how the process works. The penny started to drop, when I decided to work over Christmas, and use some of that time to investigate some emerging trends in frontend development.
The problems that I see, boil down to the following:
- How do I need to think when it comes to a Responsive Design?
- How can I test on so many devices, browsers and resolutions?
- Isn’t all this just going to increase my workflow?
The conclusions I’ve reached boil down to:
- Think in terms of grids that become a linear column when the site gets small.
- There are web services available to help you test, they cost money but they save time and effort.
- My workflow may increase, but not as much as I think, as long as I work smarter and reduce wasted time.
How did I reach this point? Before Christmas 2012 my workflow was fairly similar to what it was for the last 5 years. Code something up in HTML, CSS and JavaScript then open up my browser of choice to see if it matched the design. Fix up any problems using whatever debugging tools are available to me. Then manually duplicate those changes over to my files and refresh the browser.
This approach was great when we lived in a world of 2 browsers, 1 or 2 operating systems and one screen size, still fairly good when we lived in a world with 7 or 8 browsers 2 or 3 operating systems and one screen size. But those days are over, and I can’t even begin to imagine how many combinations of browser + operating system + screen size we have.
Our world as Frontend Developers has changed, and if we look back on 5 years ago as a golden age and wish to return to it, it’s not going to happen. If anything, it’s going to get more fragmented.
The first thing I would say to you is this, don’t panic. Whilst you were churning out site after site, page after page. Other people were having the same problems as you, and have built tools to help you. You will have heard of some of these, but you may have dismissed them because they seem like fads, and you have work to do. I’d ask you to take some time to play with these tools and then see how they will benefit you.
Here’s a rundown of the mental shift I had over Christmas, I’m not going to cover things like CSS pre-processors, or JS validators. As they are a given.
For a responsive design, the linearisation of the grid is key to getting smaller and looking good.
I’ve always loved grids, as they can save you so much time in coding and testing. They can also make the design QA process much easier, as they help the developer understand how a designer wants things to line up.
My mental problem:
If I’m doing something responsive, what happens to my grid when it gets squished?
Penny drops:
When the grid reaches a certain point, it becomes linearised. If you view the example page on (Twitter) Bootstrap http://twitter.github.com/bootstrap, you’ll see this happen (resize your browser so it’s around the same size as a phone browser and watch all the columns collapse into 1). The YAML CSS framework http://www.yaml.de/docs/index.html#yaml-grids takes this an extra step by allowing you to set when linearization takes place, more than once if you like. View this YAML demo http://www.yaml.de/demos/flexible-grid.html at the size of an iPhone, and iPad and then a larger size to see linearisation take place in 3 steps.
Before linearisation breakpoint
All columns in their expected places
After linearisation breakpoint
All columns are stacked under each other
Tools that reload your CSS automatically are really useful
Tools such as CodeKit http://incident57.com/codekit/ and LiveReload http://livereload.com/ seem to work like magic, reloading your CSS as you save the files.
My mental problem:
This is what I do anyway but I do it with elbow grease and a reload button, this kind of thing will just add another layer of complexity.
Penny drops:
How much time do you waste imagining how the CSS will look, transferring CSS from debugging tools to files and waiting for resources to reload within the page? YOU DON”T NEED TO WASTE THIS TIME! Yes, you’ll still need to load up older browsers, but that’s not the point. Your old workflow would only get you 80% of the way there, so why not do that 80% in half the time?
You can even restyle those pesky JS widgets without having to click 5 times to get it into the right state.
With this set up, I feel that I could even use it to design a site from scratch because the feedback is so quick. Although I still want to use Photoshop to thrash out a few ideas first.
Services that give you VMs as a service are useful
There are many cloud based services that provide you with VMs within your browser. Services such as Sauce Labs https://saucelabs.com/, Adobe Browser Lab https://browserlab.adobe.com/en-us/index.html, and Browser Stack http://www.browserstack.com/. These VMs are fully interactive and come with debugging tools. They’re not as quick as your computer though.
My mental problem:
I’ve always been a believer that you need to use the real hardware with the real software. This was fine when it was Windows XP with IE6 or FireFox 2, I could just use my development box. It was even OK when I had a Mac and Parallels running Windows 7. But now I need to reach more devices, and I no longer want to run everything on my development box. I used some cloud services a few years ago, and they only offered screenshots of pages and were generally slow and pretty much useless for doing any testing.
Penny drops:
I don’t need the device to run at full speed, just enough to see it and use it is enough for many of the devices I need to support. I can still run VMs on my dev machine for the devices I want to have 100% confidence with.
Conclusion
These are the things I’ve learned over Christmas, they’re not answers to our problems but they are forming the path I’m going down to make me more confident in the work I do.
Updates:
After I posted this I received this link which makes good reading (Thanks Fiona): http://cognition.happycog.com/article/beyond-binary-grids
Another link with some great resources to lose your self in: http://bradfrost.github.com/this-is-responsive/resources.html