Tagged in-browser design

The case against gratuitous Lorem Ipsum text

Caslon-schriftmusterblatt

My Lorem Ipsum tattoo on CheckOutMyInk.com

Let me preface this article by clearly stating that I’m not a designer. My background is solidly in the implementation side of things, which might be why I’m approaching this issue from what seems like a very biased viewpoint. If you are a designer, and you feel I’ve made some sort of horrible mistake, please don’t hesitate to let me know in the comments. Also, most of what I’m discussing here applies specifically to WordPress sites, which tend to be heavily publisher-focused and therefore contain user-generated content that the designer and engineer cannot control.

We’ve all seen the perils of using Lorem Ipsum or generic placeholder text to build static Photoshop mockups. Things like “Sample Title” never seem to work out right when translated to the web. A real headline, like, for example “The case against gratuitous Lorem Ipsum text” is a heck of a lot longer than the example, and forces the developer or web engineer to deal with the fallout.

The reason for this fallout, of course, is that the original design doesn’t account for flexible title lengths, and requires whoever implements it into the dynamic environment of the web to “guess” as to how the title element should flex to accommodate real-world content. In other words, by using generic text, the idea that the static mockup is just that–static–is reinforced to the client and even to the designer who created it.

Of course, as web design moves solidly away from static mockups and towards in-browser design, there’s a tendency to assume that the issue of design being too static is automatically eliminated. I’d argue this couldn’t be further from the truth. If an in-browser design uses generic titles and Lorem Ipsum content, anything can happen.

I’ve seen markup created that relied on a fixed-height title element. This created a huge problem when editors wanted to write an article with a title over 30 or so characters. I’ve also seen elements that relied on minimum content length that the generic copy provided. Once that markup intersected with real-world (sometimes very short) content, the sidebar collapsed underneath it. These are just a couple of examples–there are many more out there, and I’m sure everyone has their own stories about problematic user-generated content.

All of these problems end up being discovered during the implementation process, well into the process of designing and building a website. As a subscriber to Kevin Hoffman’s “iterate early” methodology, this late-round revision of markup and (maybe) design strikes me as highly inefficient and a major risk to on-time, on-budget project delivery.

So what’s the solution? Well, if you’re redesigning an existing site and have access to content, it’s probably best to use several examples of that content to test your in-browser design. It also helps (and this is admittedly difficult without trial and error) to think through possible content outliers and how they can affect design. While there are some seriously esoteric CSS bugs that will inevitably surface when a design is implemented into a dynamic website, testing a few common things can really help with most publishing-style sites:

  • A really short headline, e.g. “49ers Win
  • A really long headline, e.g. “Local residents up in arms over county officials’ stated desire to begin eradicating local mongoose population
  • Content that spans length from a few hundred characters up to several lengthy paragraphs
  • Enough navigation links in various nav bars to represent the actual number of options that will be on the site
  • A photo that is wider than it is tall; a photo that is taller than it is wide.

The good news here is that all of these things can be tested easily in your in-browser designs using some simple JavaScript. For example, by setting the text of the article title to several different lengths, you can easily test whether your design can handle flexible titles.

Similarly, if you’re unable to obtain actual short and long content examples (e.g. if you’re building an entirely new site), creating a small paragraph of sample text that you can then clone to create longer and longer articles is a handy trick for testing how your design handles different article content. I’ll be posting a couple of examples of these JS snippets in a follow-up to this article.

If you’re looking for some additional tips,¬†this article¬†provides a great walkthrough of how to overcome the Lorem Ipsum “crutch.”

Image source: http://www.checkoutmyink.com/tattoos/marquin23/my-lorem-ipsum-tattoo