Experimenting with Options for Responsive Wireframing
At Blueprint, we are actively working to revamp our processes to better accommodate our clients' needs for mobile-friendly and responsive web design solutions. It used to be effective to create one wireframe and design comp to show clients what a final, developed homepage would look like. But these days, that approach only goes so far toward helping us plan — and communicate to our clients — how a site layout and design will look and change when viewed on different devices.
The industry is experimenting with lots of different solutions, all in an effort to avoid having to create a separate wireframe and design comp for every display size (and in fact, that's not a practical nor cost-effective solution as the number of popular display sizes continues to grow). In-house, we have been testing out some programs and approaches to see what works for us. Here are some initial insights:
Historically, Blueprint has used Adobe Illustrator to produce wireframes. I'm not sure about the origin for that solution, and while it has worked fine for very small sites and lets us produce some very nice-looking wireframes, they are fixed-width — not responsive — meaning we need to create separate wireframes to demonstrate page layout on different displays. Beyond that, Illustrator's primary objective is not page layout, so its support for text styles and master page templating is lacking. In the past, when I've had to change something, like a header, that appears on all pages, it's been a manual process — and a total headache. Recently I read that Illustrator has symbol capability that can achieve a similar effect as master page items, but I haven't explored it to know the ins and outs.
We thought we'd try InDesign after we learned the Boston Globe used it in their process for achieving their industry-renowned responsive redesign. We figured the template issue we ran into with Illustrator wouldn't be a problem here, since InDesign *is* a page layout program with master page capabilities, and we knew the text styling would be efficient. The templating came in handy to a point, but one of my main complaints was the inflexibility of master pages in accommodating the varied lengths of content on different pages.
There's a healthy debate in the industry about whether Fireworks or Photoshop are better for web design, but what about wireframes? After all, Fireworks does have master-page templating capability. While I haven't spent much time exploring the Fireworks approach, I'm mid-way through a series of Lynda tutorials on wireframing with Fireworks, and I came across a set of steps for exporting a responsive prototype from Fireworks, but without investing a bit more time (which is hard to come by!), I haven't been able to determine if it is (or isn't) the optimum solution for us.
Meanwhile, Blueprint is in the process of redesigning our own website. After we got some preliminary feedback from clients on two homepage wireframe options, which we quickly whipped up with our trusty Adobe Illustrator, it was time to wireframe out some interior pages and think through how the site would be responsive. As luck would have it, I came across an article about Zurb's Foundation as a tool for creating responsive wireframes. I've been intrigued by the idea of coding wireframes, rather than using programs that generate static output, so I figured I would give it a try. I love to code, but it's not something I do on a daily basis, so I was a little apprehensive about how far I would get with this approach. I was especially skeptical that I would have enough mental bandwidth to make wireframing decisions if my brain was focused on figuring out how to get the code to work.
That last concern was easy enough to resolve by quickly sketching out my wireframe ideas on paper before starting to code. With the wireframe thinking out of the way, I could jump into the code. The learning curve will differ for everyone, but for me, it was pretty small (I just had to figure out things like how Foundation dictates column width). And before long, I was happily coding away and creating an interactive — and by-default, responsive — set of wireframes for our site redesign. I spent most of my time in the HTML and only a small amount of time adding custom CSS to Foundation's existing stylesheet. Semantic purists won't like that Foundation's code is not completely semantic, but since I was only using it for wireframes, that didn't concern me — I was looking for efficiency! I spent more time tweaking the out-of-the-box responsive approach to address content priority and a few other elements in a way that makes sense for Blueprint, but it was great to have a responsive foundation to work from. Oh, and to address the templating issues that plague some of the other approaches described above, I just created some include files for common elements, like the header and footer.
All in all, it's hard to say that any one approach is the silver bullet, but with Zurb's Foundation, I ran into the fewest hiccups and was able to generate the most responsive output in the shortest amount of time.
Most Popular Posts
Blueprint on Twitter
Follow us @BlueprintTweets!
@fredgatesdesign There is a param for "link" which is what you need. You can actually do a print_r on the result to see all available data.