As responsive design continues to develop as a best practice for creating websites, there are a growing number of articles published about improving your workflow and design approach. There doesn’t seem to be one right way in designing responsive websites and I find it very helpful to hear from a variety of people and distill their advice into a tailored approach that works best for my team.
I was fortunate enough to get introduced to Chris Brauckmuller a couple months back. Chris is a brilliant front end designer/developer at Fundrise, which you’ll learn little more about a few hundred pixels down.
Responsive web design will continue to evolve for the better as more talented designers and developers contribute their discoveries to the community at large. So, without further ado, let’s hear from Chris!
Tell us a little bit about Fundrise. Why is it so awesome?
Fundrise is an investment platform that lets you invest directly in real estate. We apply the crowdfunding method to real estate investment, empowering a large number of individuals to pool their money and invest in a single property. We’re the only company in the United States that has offered and successfully funded a public crowd equity real estate investment.
What do you think is the biggest challenge when designing a responsive website? Is there a common error or weakness you see in responsive websites today?
I think the toughest thing is ordering content in such a way that it makes sense on any device. Trent Walton wrote about this in his article on content choreography. It's not much of an issue if it's just an article or blog post, as it is usually just a single stream consisting of title, body, and comments / meta. However, if you have a more complex UI like the investment offering page on Fundrise, where there are multiple calls to action or paths a user could conceivably take through the content, things can get tricky.
How do you solve this problem?
The most important thing is establishing a sound hierarchy of content before you start designing anything. Allison House, one of the most talented UI designers I know, has an amazing article where she covers her method for categorizing and laying out interface elements. I usually start out any new UI by employing some variant of the method she covers.
The other thing to remember is that you can do some neat things with CSS to re-order content depending on the device. To bring up the example of the Fundrise investment offering page again, at first glance it looks like a standard two-column layout when you pull it up on a tablet or desktop. When you go over to mobile, you might think the entire right column would slide under the left. However, we are actually putting the call to action with the meta-data from the right column immediately under the photo because that’s more important than the extended description / documentation about the investment. This kind of thinking and application of CSS can ensure that more important information is closer to the top of the page on any device.
There’s a lot of talk in the design community about ‘mobile first’. Do you design for mobile devices and work up to the larger layouts? Or the vice versa?
I personally design for desktop first, while trying to think the whole time about how the layout might look on mobile. If you have a large mobile audience or have reason to believe that by doing a redesign you will gain one, it may make sense to pursue a mobile-first strategy.
Do you design directly in the browser or Photoshop first?
It really depends on what I'm designing. If it's a UI, especially something data or text-heavy, I often do a paper sketch and then go directly into mocking something up in the browser. Also, if it's a new UI for an existing product, like Fundrise, I definitely lean more heavily on the browser because I have instant access to all the CSS styles for the existing UI components. A lot of times I will hash something out quickly in the browser, then screenshot it and refine in Fireworks – I hate Photoshop.
That being said, for a new brand or a thorough aesthetic overhaul, I always start in Fireworks as it offers you much greater freedom to branch out and explore alternatives. Starting in code tends to keep your thoughts and UIs pointing in the same linear direction as where you’ve been already (which can be a good or bad thing).
What are your favorite responsive websites to date?
trentwalton.com is one of the most beautifully executed responsive blogs/personal sites I’ve seen. Wonderful reading experience across devices and of course has Trent’s hallmark clean, iconic style and attention to detail.
bostonglobe.com does a wonderful job of presenting an extremely rich and varied collection of data in a clean, pleasant and consumable format across devices. This is truly one of the quintessential examples of responsive web design done right. It manages to do with one set of code what many newspapers (with their mobile-specific versions) fail to do in two or three.
What are a few of your favorite RWD tools, frameworks or plugins?
I was actually frustrated with what was available as far as frameworks go, so I wrote my own framework for responsive design called Helium, which is used on Fundrise as well as on my personal site. I was honored to have it picked up by Hacker News and featured as one of GitHub’s trending projects.
Another thing, which isn't really a tool so much as it is a process, is setting up my local machine with a virtual host (e.g. chris.local/fundrise) so I can easily test my designs on my iPhone and iPad while I'm working, without needing to upload anything to a web server.
What’s one piece of advice you would give to someone about to design a responsive site?
It sounds cliche, but my main advice would be to keep it simple, especially if it’s your first time. Also, whenever you come across a design problem that seems impossible to crack, it’s likely that someone else has encountered it, so check out one of the many responsive design galleries and get some inspiration to get you over that creative hurdle.
What advice would you give to someone trying to decide between designing responsive websites and a native mobile app?
I look at a responsive web app as a good “testing the waters” solution for exploring the possibility of developing a native app. You can offer a solid experience across a range of devices at a fraction of the cost to develop a suite of native apps. Once you’re live, if you notice an uptick in usage from a particular device(s), you might consider if there is a business case for developing the native app. This approach of course assumes that access to core hardware functionality (camera, GPS, etc.) is not necessary for your product.
Do you give much thought to designing for high-density (retina) displays? Do you think this is something web designers should worry about yet? If so, how does this effect RWD?
I try to pick the low-hanging fruit when it comes to optimizing for high-density displays. I think this is more of a pure aesthetic consideration than a usability concern at this point in the life cycle of high density displays. Text (the most important component of any design) is automatically rendered at high density, so it’s really just a matter of how much of a perfectionist you want to be when it comes to images and graphical assets. As support for vector graphics becomes more thorough and CSS takes care of things like gradients and shadows, the only thing that will really need to be optimized is photos.
I think what the web needs is a “smart” photo format. Depending on a combination of user-defined settings, connection speed and display density, a device would request higher or lower resolution versions of the same file.
What would you say to a company concerned about the financial implications of having a responsive website created? Is RWD a cost effective solution, or should they stick with a fixed width site?
You have to look hard at analytics when making that decision. The question is more and more often becoming “can you afford not to have a responsive site?”. If 20% of your users are coming in on mobile and you expect that number to climb, are you willing to give them a less than optimal experience to save money? The reality is obviously far more nuanced than that, but if you can afford it, a device-agnostic product sitting on a single codebase makes a lot of sense.
Not very long ago companies used to invest in creating a completely separate mobile website. Do think there is ever a need to do this today with existing RWD technologies?
I think this route will go the way of the dinosaurs in most cases. However if you have an extremely data-rich product like Amazon or Facebook where you need a very distilled experience on mobile, it may still make sense. Obviously this raises the question of whether or not a native app might serve those purposes better.