This is a part two! If you came here directly, I’d strongly advice you to head to part one and get some background on what this is even about!
Remember the good old days of the internet? Geocities? Angelfire? . If you do, chances are that you’re quite aware of what a fluid layout means. Back then, almost all web content was fluid, and by that I mean that as screen sizes got smaller/bigger the content would shrink/grow accordingly. Copy would flow in columns and images would scale.
2010 and 2011, you saw very few fluid layouts that weren’t Flash. There are a lot of reasons why the industry shifted to fixed width designs. The general gist of it is that it’s easier (and thus cheaper) to both design and develop intricate designed sites to a fixed width.
Fixed width really means that the website is made a certain size, for anything above it centres, for anything below you get scrollbars. http://www.jetstar.com/ is an example.
Responsive design is grounded in the same theory that Adaptive Design follows. Layouts/Breakpoints dictated to the major device targets that the demographic dictates. However, instead of leaving it there, all breakpoints are structured using a fluid layout.
So, as a brief example, if you have a breakpoint for iPhone 4S (640×960) but view the website on a Galaxy Nexus (720×1280), it won’t centre on the screen, but instead make use of all the extra screen real estate.
I’d like to take a moment here for you readers to look at one particular website which has captured this methodology in an excellent way. http://www.bostonglobe.com/.
Have a click around, resize the browser window from largest to the absurdly small and observe how every single design element goes through 6-8 major shifts, and in between the website responds by making the best use of the screen.
The benefits of this are massive. It essentially means you ‘bias’ certain devices that have a high traffic figure to your content, and structure a perfect layout for that. Other devices that are around a similar screen resolution will get served that breakpoint, but because of the fluid structure of Responsive Design it will adapt to gracefully cover the screen.
Now, there are a few caveats. Firstly, to do this properly, it requires a drastic shift in process from how a lot of agencies work. The waterfall methodology just doesn’t fit the agile nature of responsive design, and we’ve found that ultimately this requires UX, design and development to collaborate a lot more than before. It’s really a great story, because not only does it solve a lot of business and technical problems, but also mixes things around in the agency model.
Change is good. And change is most definitely here.
Here at Isobar we’ve started to make that shift already, and are looking to Responsive Design as a best-practise for web solutions where it’s feasible. When you take a step back from the intricacies of web development and look at the current state of a lot of web content and combine that with the trends, Responsive Design really does come across as a no-brainer.
Obviously there are more challenges, both visual and technical, but that’s a whole other chapter.