At the beginning of our discussions regarding the overhaul of our own DEG website, it was the consensus among our team that responsive Web design was destined to be the norm, not the exception. Working on that internal project was the perfect opportunity for our group to grow our skill sets while quickly identifying how our then well-entrenched processes would need to be amended and augmented for the challenges responsive development presented. Since that time, we’ve iterated our processes and addressed many of these challenges in order to better serve the needs of our client partners. One element that has proven integral to this new normal is our adoption of responsive wireframes.

 

What are Responsive Wireframes?

Some people create a single static wireframe for each viewport when drafting wireframes for a responsive website. Typically this involves “desktop”, “tablet”, and “mobile” versions that assume screen widths similar to various Apple products. However, there are a few shortcomings with such an approach:

  1. Each screen has to be wireframed multiple times to address each viewport
  2. A change to one wireframe turns into a change to multiple wireframes
  3. It completely ignores viewports that may appear between each set
  4. Identifying major changes to layout (i.e. navigation) becomes difficult to clearly communicate.

Thankfully, an alternate approach was theorized by James Mellers where HTML and CSS is used in place of static wireframe tools like Balsamiq or Axure. His approach, responsive wireframes, took the principles of responsive web design by using basic HTML and CSS to illustrate the layouts. While his concept was a simple one and posed its own set of challenges, it demonstrated a wealth of opportunity for us. With responsive wireframes, we had the ability to communicate and test responsive designs faster and more clearly than we ever had with traditional wireframes.

 

What the Responsive Wireframe Process Looks Like

When we adopted responsive wireframes, we quickly discovered our core process did not need to change dramatically. All wireframes are still based on persona analysis, user stories, and business requirements. In addition, we still sketch most of our interfaces with paper and pencil; however, we focus only on two viewports at this stage: a “hi-res” and “low-res” version. The sketches at these extremes are not set to any specific dimensions. At this stage, we aren’t designing experiences for just an iPhone or a 1280×1024 laptop; we’re now designing experiences at two ends of a spectrum. By doing this, we can begin to understand how subtle or dramatic the various elements on a page will ultimately need to change with different resolutions.

Once these sketches are established, we move to forging the wireframes using HTML, CSS, and a touch of JavaScript. Common page elements like the main layout of a page, the header, footer, and sidebar are all created in separate files to provide a single point of maintainability on each of these elements. Afterwards, each page (or subset of pages if sufficient) is created in a similar fashion. As pages are finished, they are hosted on a web server where stakeholders may access them from any device connected to the network. Lastly, additional testing is done by creating screenshots of the pages at various screen sizes of devices we may not have available to ensure the screen appears correctly.

 

Tools of the Trade

The process is not vastly different from a traditional cycle of Design > Present > Review. The largest differences come from the flexibility the underlying technologies provide. One of the main challenges we had adopting responsive wireframes was finding a way to streamline the coding process. Most designers that I’ve met are not coders, so lowering this barrier was vital. Thankfully, we found a number of tools that work for us.

The first of these is Jade. Jade is to HTML what SASS is to CSS. It is a streamlined template language for writing HTML fast without all of the syntax annoyances (i.e. closing tags, angle brackets, etc.). In addition, Jade allows for components to be packaged into their own, reusable files. This allowed us to change a single file for a page header or a product thumbnail without requiring us to change every file in which such appears. This has allowed us to reuse components across projects and build our own asset library.

Next, we began to adopt Foundation, a responsive front-end framework by Zurb. With Foundation, the responsive nature of our layouts was predefined (for the most part). It provided us an easy-to-learn set of CSS rules to add to our Jade files so we did not have to worry about writing a custom responsive grid for every project. While we had to expand the rules a bit, the concept of Foundation provided us what we needed to focus on the details faster.

After those, we sought ways to add placeholder images and icons to our wireframes. For images, we gravitated towards the Placehold.it service. Placehold.it is a simple service where you craft a URL as the source of an HTML image, and it returns a gray placeholder image of the specified dimensions. After images, we began using Fontello, an icon-font package generator.

Another challenge we faced was the ability to host these wireframes. We began to compile Jade to straight HTML; however, the process was daunting and not an ideal experience for designers. Because of this, we looked to hosting the files using Express.js, a web framework which uses Node.js. Express.js can serve Jade files without the need to first compile the files to plain HTML. This makes deployment as simple as copying files from one location to another without the need of extra steps.

Last, hosted responsive wireframes allowed us to test and interact with the designs directly on devices. This was a great advantage in being able to get feedback early; however, we also began wondering how to test on devices we may not have available or that don’t exist on the market yet. We solved this challenge using Phantomjs. Phantomjs is what’s called a headless web browser – a web browser with no visual component. With Phantomjs, we can request a web page and then interact with it all through a command line. While such has its uses, Phantomjs has the ability to request pages based on specific screen resolutions and take screenshots of what’s returned. This allowed us to specify any device resolution that we wanted to see how it would appear. While not as good as having the device in hand, it allows us greater visibility into how the design appears on any number of device resolutions.

This process is still evolving. With each iteration, we discover new challenges and opportunities. Through responsive wireframes, we’ve been able to develop a communication process that clearly articulates the intent of our interactive designers while providing a greater opportunity for delivering feedback. We’ve developed a methodology for managing new assets related to wireframes so we can reuse pieces from project to project. Lastly, we’ve explored (and still evaluating) the benefits and challenges related to reusing the code from these wireframes in our final products. As responsive web design continue to serve an ever-growing list of devices and resolutions, having a process like this will help us remain responsive to our clients’ needs.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments

  • Scott Rarden

    Scott Rarden

    7 years
    Reply
    Thank you for describing your process. I'm working for a company that is a bit behind the times on its processes, and its exciting to see some of the tools others use to spark ideas on how we might improve. Thank you for sharing!