When making the transition to building responsive websites, the hardest part can be getting started.
I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.
Consider RWD From the Beginning.
I believe this starts with a shift in perception. Whether massive or minute, this shift usually involves letting go of a lot of assumptions that center around desktop-centric browsing. There is so little that we can actually count on: mouse pointers vs fat fingers, hover states, screen sizes, connection speeds, device capabilities, etc. What good is initial planning (content strategy, IA, sketching, prototyping) without considering all of the variables the multi-device web provides?
If a team is knee-deep in .PSDs before considering layout changes and alternate viewports, opportunities for optimization and innovation will be overlooked. I’d rather proactively embrace a new approach than try to shoehorn an old one.
Benefits of a Lengthy On-Ramp
If I were on a team organized around fixed-width desktop-centric production I wouldn’t want to be expected to immediately start building responsive sites at the usual pace. Taking time to fiddle with devices, hack code, and perhaps most importantly, time to think pays off in the long run. Giving teams and individuals a cushion to get back up to speed after taking a new direction helps instill a sense of purpose instead of panic.
This cushion could be in the form of extra time for reading and research, extra time budgeted into a project, or even better, a responsive hack week project. Imagine teams of 2-5 that build a responsive site on any fictitious topic they want.
We had to uproot a lot of what we were used to at Paravel, and there are only three of us. Processes and roles will change. Not everyone will be delighted about these changes all the time, so ease in and give team members time to learn by doing.
De-compartmentalize workflows.
I’ve mentioned this before, but ditching the assembly line method of site building for a more communicative, iterative process will be helpful. Team members learn from each other (fatten those T’s) and arrive at solutions more quickly when they work closely. Rather than a more traditional design and development departmental split, why not create small teams with both design and development talent? That way, when someone has a good idea, it can be designed and prototyped without the hassle of multiple handoffs.</div>
On Content
No amount of design or code can adequately fix content problems. It can be tempting to think about content in terms of mapping it to a desktop-based frame in your mind, but it’s important to separate content and hierarchy from any single layout possibility. Now is the perfect time to embrace the web’s unpredictability as well as the mobile first line of thinking.
Research from Google (PDF) shows that 90 percent of people start a task using one device, then pick it up later on another device—most commonly, people start a task on smartphone, and then complete it on the desktop.
Karen Mcgrane’s thoughts on content parity and consistency nail it for me. In many cases, it seems as though over-engineering and over-thinking take the place of good ol’ fashioned editing and restraint.
On Design
When content and hierarchy are set, where to next? I still use Photoshop, but I use it differently. It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.
That said, no one should feel like he/she has to drop photoshop or any other tool cold turkey. To me, it’s less about how I get there and more about ensuring that old habits aren’t triggering reversions in my perception or wasting time. I think browser-centric workflows and style guides are the future, but don’t be shy about casually assembling components in a .PSD for comprehensive evaluation if you want.
On Code
Whether it’s CSS for a single component or an entire site, I finish in a mobile-first fashion by using min-width media queries to set the smallest view and move outward from there. However, I start much differently. I begin with wide views because the layout is usually more complex. I find it easier to ensure columns and spacing are set wide and work my way down to a single column.
All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion. As I continue to fidget with various layouts, I shuffle code for larger views down into alternate media queries as needed. I’m not saying this is the most efficient practice, but at the end of a project this somehow helps me feel like every view has been well considered, which is most important to me.
On Breakpoints
It’s good to plan, design, and test with all sorts of devices in mind, but it’s become standard to let media queried breakpoints be defined by content/layout rather than any specific device. Whenever things don’t fit or hierarchy breaks, add a media query. My favorite example of this is if we set a max-device-width media query at 480px to target an iPhone 4, the iPhone 5 wouldn’t display any of the targeted styles because the screen is larger. Fine-tuning breakpoints to the design rather than the device will make your responsive layout ready for just about any new device the market may throw at it.
On Grid Systems and Frameworks
One of the most important skills in RWD is the ability to control the layout (how content shifts and reflows at various widths). Grid systems can be extremely helpful, but I’d say it’s good to avoid counting on them too much. To me, using these tools in a drag & drop fashion takes the fun out of the process because the framework then determines the content choreography and not the designer.
Get help.
Most of our learning at Paravel has been through our mistakes. Whether it’s determining if a design might paint you into a corner when things begin to scale or how best to code a new feature out, getting help saves time and money. Don’t be afraid to reach out to teams with specialized experience, whether in the form of production work or introductory consulting.
Above all, the key is to not get frustrated if the process gets sloppy or less efficient than we’re accustomed to. While projects may take longer at first, the effort put forth to ensure that teams are headed in the right direction will pay off exponentially. And remember, it’s less about how we start than where we end up. The trick is simply to get going.
For additional tips, check out Chris Coyier’s Notes to an Agency Starting Their First Responsive Web Project.