Content Prototyping In Responsive Web Design

Advertisement

Michelangelo once said,

The best of artists has no conception that the marble alone does not contain within itself.

Translate this to the world of Web design and you might say,

No matter how great a designer you are, you’re only as good as your content.

While the reality of client work sometimes makes it challenging to gather and produce content prior to starting the design, this is now widely accepted as being necessary. You may have heard this referred to as “content-driven design1.” I’m not the first to suggest2 that our current approach to responsive Web design could be improved by imparting a bigger role to content3 in determining how our websites respond. However, I haven’t seen many (if not any) practical explanations on how to do this. I’d like to start this conversation by introducing a theoretical concept called a “content prototype.”

What Is A Content Prototype?

A content prototype is an HTML-and-CSS-based fluid-grid prototype, consisting of layout and typography, that consists of the project’s actual content. Its greatest usefulness may be in determining where to apply media queries to make the Web design responsive.

For centuries, we have shaped our layouts and typefaces according to the meaning of the content. This has traditionally been done on fixed-width pages. We have inherited a fixed-width mentality in designing for the Web, when in fact the Web is not fixed-width. Users come to our websites for content. We should strive to present this content in the most appropriate and readable way possible.

Let’s Get Theoretical

The following is a theoretical walk-through of how one might use a content prototype in real life. Again, this is intended to begin a conversation on how we can marry the concepts underlying content-driven design and those of responsive Web design.

Imagine that you are about to begin designing a website. The website will consist of a single page, which contains a block of text and a few short excerpts of related text. You’ve done your homework, and the content is fully written. You have solid documents of the architecture and wireframe that establish the priorities for this page. You also know that the website will be responsive. You’ve opened up your design tool of choice, and you’re now looking at the “FileNew” dialog. What to enter in those pesky little “width” and “height” fields?

Photoshop’s new file dialog box
Photoshop’s new file dialog box.

Perhaps it doesn’t matter.

Consider this. The goal of this process is to create a website that begs to be read at any resolution. So, start at whatever resolution you’d like, whatever you’re comfortable with. Every resolution is important, not just the resolutions that last month’s analytics say are the most popular.

Because we’re following the principles of content-driven design, start with the highest-priority content on the page (the real content). Don’t worry about anything other than the typeface, font size, column width and layout. Make it a pleasure to read. This is about as basic as you can get, because you haven’t yet created icons, textures or illustrations; those elements are important, but they should support the content, and you can work on them later.

Next, code the simple page that you’ve designed using a fluid grid4. This is critical; when your browser’s window is about the same width as the canvas that you started with, the content prototype should look very much the same. This gives you the chance to play with the prototype in a browser and make informed decisions about where your media queries should fire. Using this method, the content will dictate where your fluid grid breaks down. These breakages are where you should apply media queries5; they are opportunities for more dramatic changes. Make these changes, always focusing on the legibility of the content.

Following this pattern, you would add media queries at points where the fluid grid falls apart. Soon, you will have a full spectrum of resolutions, with beautiful and appropriate reading experiences. Once this is done, you will have a finished content prototype that demonstrates the readability of your content outside of the context of any device-specific resolutions.

Benefits Of A Content Prototype

Thinking this way about the process of responsive Web design makes the content a filter through which all other decisions are made. The goal is to add a degree of cohesion between the message and the design of the website that would be difficult to achieve without such an approach.

Another challenge with responsive Web design is in testing usability across all resolutions. A round of usability testing with a completed content prototype could quite possibly give an early glimpse of problems with changes to the layout. The sooner you can identify these problems, the lower the cost of fixing them.

Additionally, content prototypes give you an opportunity to show that layout changes are possible before spending days designing every detail. The iterative nature of content prototyping invites collaboration between designer and coder — even if they happen to be the same person.

Design In The Browser

If you are one of those designers who also codes, then you’ve probably recognized that this can all happen right in the browser. If you have the skills to do both, then by all means, start in the browser. With the emergence of CSS3 features6 like border-radius, text-shadow and gradient, designing in the browser7 is more feasible today than ever before.

We’re all frustrated with our tools. Perhaps this is because they are all fixed-width tools! But regardless of whether we have the right tools for the job, we cannot continue to rely on common device-specific resolutions if we want to build websites that work well into the future. A content prototype gets our content into the browser as early as possible.

Problems With Content Prototypes

Obviously, this approach does have some limitations. Foremost, not every website is content-driven; many websites are workflow-driven. Without getting sidetracked by the whole question of what content is, we can recognize that this process wouldn’t necessarily work if you don’t have the content first.

Also, if you’re a designer who is not also a front-end developer, then a lot of back and forth will be required to complete the content prototype. This is not necessarily bad, but it will certainly take time.

Then there is the problem of what to do once you have a completed the content prototype. You could continue designing and adding to the code that you have. But if you do choose this route, then you will need to start with the smallest resolution first8, because this is the best practice for coding a responsive website.

Alternatively, you could use this process merely to determine where your media queries should fall. In this case, this would be a lot of work just to find the proper breaks in the content’s readability.

Alternative Approaches

There are other ways to make these decisions. Using traffic data, some people might build a graph to determine the breaking points in their design.

Breaking point graph
Using traffic data to determine where to apply media queries.

Ethan Marcotte9 describes a similar process in his book Responsive Web Design10, but he also suggests resolutions that are common among popular devices these days. Also, coding a responsive website that has already been fully designed could cause problems if you’re not sure whether the layout can be achieved with CSS alone. As mentioned, content prototyping lets you experiment with these layouts before fully committing to a change for a given resolution.

The point of all this is to make our content more readable, independent of what device it’s being viewed on. If content prototyping doesn’t work, maybe we could find some way — other than relying on which devices are currently popular — to make content-driven decisions about the design and layout. The guys at Front have been experimenting with this as well, calling it “The Goldilocks Approach to Responsive Design11.” Their technique is to use an em-based layout (instead of the typical fluid-grid approach of percentage widths) to create a great reading experience at all resolutions.

A Helpful Tool

One of the developers on our team recently created a media query bookmarklet12, which displays in real time your browser’s width and height and any media queries that have been triggered. This tool can be very helpful when doing responsive Web design. Feel free to experiment with it; I hope it simplifies the process for you as it has for us.

Building For The Future

The aim is lofty, designing for the future. Just as we build websites to be accessible to the widest audience possible — because that is the right way to build them — we should build websites that embrace the fluidity of the Web. A challenge is before us to find ways to present our content appropriately without knowing which devices it will be viewed on. We must shift our focus back to the user. A content-out approach is a user-centered approach.

It won’t be long before we’re interacting with the Web in ways we never imagined13. We may be near a time when fixed-width websites are considered outdated. Whether or not that happens, our websites should be flexible enough to present readable content to all of our users. Moreover, assuming what a user with a small screen wants from your website can be dangerous14. Mobile-specific websites are certainly appropriate at times, but there are a few reasons why a website should not (at a minimum) be built responsively.

In order to get better at what we do, we must keep pushing the process forward15. If you have other ideas on how to separate our decisions about a website’s design from popular device resolutions, or even knowledge of the benefits or problems of content prototyping, please share.

Further Resources

Further articles and resources related to this article can be found here16.

(al)

Footnotes

  1. 1 http://www.zeldman.com/2008/05/06/content-precedes-design/
  2. 2 http://www.markboulton.co.uk/journal/comments/a-richer-canvas
  3. 3 http://adactio.com/journal/4523/
  4. 4 http://www.alistapart.com/articles/fluidgrids/
  5. 5 http://www.w3.org/TR/css3-mediaqueries/
  6. 6 http://coding.smashingmagazine.com/2011/04/18/powerful-new-css-techniques-and-tools/
  7. 7 http://24ways.org/2009/make-your-mockup-in-markup
  8. 8 http://www.broken-links.com/2011/02/21/using-media-queries-in-the-real-world/
  9. 9 http://ethanmarcotte.com
  10. 10 http://www.abookapart.com/products/responsive-web-design
  11. 11 http://www.designbyfront.com/workinprogress/article/the-goldilocks-approach-to-responsive-design
  12. 12 http://seesparkbox.com/foundry/media_query_bookmarklet
  13. 13 http://gizmodo.com/156257/samsung-smart-zipel-refrigerator
  14. 14 http://mark-kirby.co.uk/2011/the-mobile-context/
  15. 15 http://seesparkbox.com/foundry/you_say_responsive_i_say_adaptive
  16. 16 http://www.smashingmagazine.com/content-prototyping-related-resources/

↑ Back to topShare on Twitter

President and Founding Partner of Sparkbox, a web studio building sites that are just as brilliant for mobile as they are for the desktop.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    @dcuffman, great point—the article is intentionally void of tangible answers like this. The intent is to start a conversation about how to use content to drive our designs (specifically, in responsive/adaptive web design).

    To try and answer your question, I might suggest that each unique page template would need this kind of approach. Thoughts?

  2. 2

    Great article but it left me wondering just how much/how many pages would be needed to make a solid determination. Sure, it depends upon the project but I wonder if a simple guideline like three or four pages at minimum, representing the typical templates for the project would be a good measure.

    DC

  3. 3

    As responsiveness becomes the norm instead of an extra in the average marketer’s mind and most of the page’s look and feel being generated via CSS/SVG/Canvas I expect the browser to replace Fireworks/Photoshop as the primary web design tool. What we’re missing, as you mention, are the ridiculously fast and easy in-browser tools we want. Somewhere in a dark room right now that Adobe killing bit of genius is being crafted.

    Great work Ben, and thanks for representing the Heartland!

    • 4

      Francisco Inchauste August 15th, 2011 6:43 am @RaSh There aren’t any plans at the mmonet. However, it’s an interesting idea!

  4. 5

    With modern Content Management Systems there’s NO excuse for doing anything but agile content prototyping. We’ve been doing this for years for client of all sizes (20-200 pages) and it works great. Within a few hours you can have enough content to find your breaking points and while your designers and programmers work on the “responsive” questions your content people (and your client) can work on EVEN MORE exemplary content. Here’s a Six Revisions article which summarizes our real-world agile content development, which dovetails nicely with Ben’s development process: http://sixrevisions.com/web-development/agile/

  5. 6

    I’m using a “design in browser” approach for a new web-app and I can attest it’s invaluable when employing responsive design. Starting with html mockups featuring actual content to validate application flow and behavioral response to media queries allows for quick identification of problems and considerations for visual design elements. You can then phase is visual design with css3 or via photoshop once layout responsive breakpoints have been finalized.

    As an additional tool, i’d highly recommend utilizing dropbox for hosting html mockups so they can instantly be viewed on multiple devices with differing viewing contexts.

    • 7

      Great to hear feedback from some folks trying these techniques. And I love the idea of throwing static HTML/CSS into Dropbox for easy testing… Thanks!

  6. 8

    You should keep in mind that screen size does not necessarily equal browser size and does not function as media query basis. Chris Coyier does a good job pointing it out in this article: http://css-tricks.com/9778-screen-resolution-notequalto-browser-window/

    Also, midwest represent :)

    • 9

      Love Chris’s stuff—thanks for contributing to the conversation. Also, proud to be crafting sites in the Midwest!

  7. 10

    With modern Content Management Systems there’s NO excuse for doing anything but agile content prototyping. We’ve been doing this for years for client of all sizes (20-200 pages) and it works great. Within a few hours you can have enough content to find your breaking points and while your designers and programmers work on the “responsive” questions your content people (and your client) can work on EVEN MORE exemplary content. Here’s a Six Revisions article which summarizes agile content development in a real-world scenerio: http://sixrevisions.com/web-development/agile/

  8. 11

    I love your articles, I only wish your sharing functions were more obvious. For a web design blog, you should know about the importance of social media sharing buttons better than most! Not everyone shares content on Twitter.

  9. 12

    I was new to the concept of content-driven-design, and to tell the truth, I was kind’of doing it before knowing it.

    I specifically liked the link of the media query bookmarklet and it was amazing. I recommend others see it too.

    • 13

      Great to hear that you’ve naturally gravitated toward allowing your content to drive your design. Have you had trouble getting content from customers before you begin design?

      Hope the Media Query Bookmarklet is helpful for you!

    • 14

      Hey. I want to to iuniqre one thing…is this a wordpress blog page as we are planning to be transferring across to WP. Also did you make this theme by yourself? Regards.

  10. 15

    Very much not true, for me at least:

    > Users come to our websites for content.

    I’ve seen the web. I’ve read it. I know it. Now I want it to be beautiful and awesome. I’m not reading all that content anyway. Let’s be honest, nobody is.

  11. 16

    Thanks for starting the stimulating the discussion around this. @Preston Williams I don’t think Adobe is the only web ‘giant’ who’ll be driving new CMS tools.
    cmsreport.com/blog/2011/10-new-content-management-systems-cms-focus

    But the overall picture I see is a shift from code-led website design to “Designer-led” websites. The tools are being built and prototyped now are enabling designers to move away from coders so that old-style graphic design skills can actually be implemented on a website.

    • 17

      It seems to me that this trend—of visual web development tools—is one that’s been around a while. Being a front-end developer probably makes me biased, but I haven’t seen any that generate the same kind of HTML/CSS/JS that a human can. So, while these tools are great for some, and even create code that will work in production, I don’t think the “hand crafted” nature of the front-end will allow them to take over.

      What we really need, which Preston alluded to, is a design tool (not a development tool) that allows us to work in a way that mimics the fluidity of the web. This is what Jason spoke about here: http://v4.jasonsantamaria.com/articles/a-real-web-design-application/.

      The multitude of devices out there are only highlighting a problem we’ve had for years—that we need a more dynamic way to craft and communicate our designs given the flexible nature of our medium. We’re behind the curve on this which is why I believe we need something like “content prototyping” or “design in the browser” to fill the gap until the right tools are available.

      Thanks for joining the conversation!

    • 18

      “Put these very dratsiape bits of inspiration together and what do you have? That there is no single average player in your game, and that reducing complex behavior down to a single number to describe that non-existent average player is meaningless.”Agreed. And yet we do it so often it’s rote at this point, isn’t it? Because we’re constantly seeking that single quality that has universal appeal. One game to rule them all. But imagine if an MMO spent parallel amounts of time in both tool-building =and= analyzing Venn diagrams of their target audience. They’d never launch =) Which is not to say they shouldn’t be looking for the overlap between person 1 and person 2, it’s just that they end up with the same 50% chance to fail by thoughtful analysis as by having the wrong gut feeling about features. For amount of effort required, it’s cheaper to go with one’s gut.

  12. 19

    Interestingly, coming from the opposite perspective, that of an (unsuccessful) content provider, I notice that approaching the design first, structuring a semantic form, is providing an equally unique experience. I think that the convergence of form and content is essential if you want to make something artful. No one takes the lead. The reader reads what I write in the context of a form that makes reading easy and enjoyable and when her interaction is easy too we are talking today.

    As a note, I think in the postscript to the Name of the Rose, Umberto Eco gives an example of consistency in storytelling. A protagonist cannot have a 5 minutes discussion in an elevator. The author has to live the rhythm of the reality (s)he presents. In digital content the author has to live the rhythm of the reader’s reality too. And if you ask me why, it is because the medium gives this ability.

    I am trying to write an article on these thoughts…

  13. 20

    Hi, very nice explanation. Responsive design is a web design and development technique that creates a site or system that reacts to the size of a user’s screen and it will optimise a user’s browsing experience by creating a flexible and responsive web page, optimized for the device that is accessing it. Thanks a lot!!

↑ Back to top