Build for the Future: Bend, Don’t Break

In: Columns > View Source

By Garrett Dimon

Published on April 24, 2006

If you’ve been building Web sites or applications for any period of time, chances are you’ve maintained one or two as well. If you didn’t create bulletproof markup like the great stuff advised by Dan Cederholm in his new book, you probably had a little extra work to do in order to accommodate some new additions or changes. As they say, the only constant is change, and online, this couldn’t ring any truer. Content changes, stock photos become outdated, and of course different browsers tend to display your work a bit differently.

Like structural engineering, constructing a Web site or application is about balancing the need for flexibility with the need for pure solid strength. While the consequences of poor structural engineering are a bit graver and depend on factors such as load and forces of nature, the need for flexibility in order to create structures to last is clear. Just like a change in wind could bring a poorly constructed building or bridge to its knees, a change in requirements or other variables can severely affect the future of your site. Like reinforced concrete it may not be as easy or cheap to build in that flexibility, but the long-term benefits are usually well worth the investment.

Why Bother to Bend?

If it’s more expensive to build in that flexibility, we’re going to need some good reasons to justify the additional effort. Before we get started, it’s important to remember that flexibility isn’t always required, and knowing when to build for it and when to overlook it is important in getting good value out of your time.

Lower Maintenance Costs

Remember the time you sliced up that beautiful comp with the wonderful typography and stock photos only to have the messaging and photo change the day before going live? No? Well, it happens. Content changes, messaging gets updated, and marketing campaigns come and go. If your site is built to accommodate only the current content, you’re going to have some significant rework to do for that next campaign. If you need the flexibility, it’s cheaper to build it in up front than it is to tear everything out and rebuild it later. Save the initial throwaway effort and just do it right from day one.

Scalability and Accessibility

Building for dynamic content usually means minimizing image-based text in favor of text styled through CSS or methods like sIFR when a higher level of typographic control is needed. Both of these methods enable you to offer scalable and accessible text that’s easy to quickly change without an additional program like Photoshop or Illustrator.

Of course, using these methods is only the first step in supporting scalable text. Assuring that the surrounding design will expand gracefully is equally important to the longevity of a design. However, by writing markup and styles that gracefully accommodate varying amounts of content, you’re implicitly creating a design that also supports text at different sizes.

Browser Variations

It’s a tough truth, but browsers tend to all do things a bit differently. While there are methods for keeping font sizes consistent across browsers, you’ll almost always be faced with some level of variation, so while your final HTML may render great on most browsers, that last browser that renders text slightly larger or smaller may visually break your composition. Planning for and expecting this allows you to build for a wider audience with less effort.

It’s Long Term, Baby

The true benefits of bending are heavily dependent on the future. If you’re building a page that’s only going to be used for a day or two, you’re probably wasting your time by making it flexible. However, if you’re going to be creating different variations in the future for monthly promotions or specials, it’s in your own interest to spend the time up front to save you time on the flip side. Of course, only you can make that decision.

How to Pull It Off

Markup is the Foundation

If there’s a direct correlation to construction in all of this, it’s that markup is your foundation. Your CSS, JavaScript, and content changes will all be tied to this markup. That means the benefits of choosing the right elements might justify some extra time to think about using a definition list instead of an unordered list with headings and paragraphs. Knowing your options and being able to choose the right markup now can make it much easier to enhance or modify the content later. At the heart of the matter is a simple task. Invest the time to make sure your markup accurately represents the structure of your document.

In addition to the markup, planning and thinking through your class- and ID-naming conventions can significantly help the future of your markup. For instance, the phrase left_bar might not be as accurate as feature_list. Even if left_bar is an accurate name today, it might be wrong tomorrow when you move it to the right side. Additionally, while that content may be a list of features this week, it may be a pricing chart next week. In that case, you might want to name it additional_info.

By naming appropriately for the future, you can easily change the content and style without having to rename the element everywhere. You weren’t planning on changing it to a pricing list but leaving the ID as feature_list were you? Good, I didn’t think you’d do something silly like that. Of course, every situation is different, but the first ID or class name that comes to mind doesn’t have to be the one you use.

Expect and Embrace Change

Like we discussed earlier, the only constant is change. By looking at everything with the expectation that things can change, you’ll have a new perspective to help you think twice about writing markup that only accommodates a certain set of content. Remember, content could easily become longer or shorter, or it might change from being a headline and paragraph to just a headline. However, if you’re on the lookout for those situations, you’ll write code that’s flexible enough to handle those situations.

Think Modular and Minimize Dependencies

It’s common practice in traditional programming, but to many markup ninjas coming from backgrounds in design, building modularly and minimizing dependencies may not be a natural thought process. By modular, we’re talking about widgets or pieces of markup that can stand alone and easily move around. By doing this, we’re minimizing unnecessary dependencies on the surrounding markup and enabling ourselves to reuse or move around the bits and pieces in the future.

This might mean wrapping that unordered list in a div instead of just dropping it in the page as a list. This way, you can set the main styles on the div, and if that list ever changes to a heading and paragraph, you can easily swap out the content. You’ve removed the dependency that the content always be in list format and enabled yourself to make the change easier in the future.

Minimize Environment Assumptions

While a large part of expecting change is minimizing assumptions about your content, it also involves minimizing assumptions about your visitors’ environments. Some may have a higher resolution, a browser that renders text larger than you expected, or browse with CSS on and images off.

If a significant portion of your users browse at a large window size, you may want to create a more flexible layout that enables them to make better use of their larger real estate. (Note: Window size is very different from resolution. Just because your visitors have a resolution of 1280 doesn’t mean they have their window maximized. That is another example of dangerous assumptions.)

Whether we like it or not, text size tends to vary from browser to browser depending on your sizing method. This can make your normal-size headings larger than expected, or it might make them smaller and barely fill the allotted space. Either way, knowing that the scenario might arise and designing for it is the safest way to go.

The images off and CSS on situation, while not extremely common, is an easy scenario to support nonetheless. The problem here lies in the text color relying on a background image for enough contrast to make the text readable. If images are turned off, there may not be enough contrast to read the text. You can solve all of this by providing a background color as a fallback.

Minimize Your Reliance on Images for Text

As you’re pretty aware by now, copy changes over time. In some cases, it may change less frequently, but it’s fairly commonplace to make regular text updates. Making the effort to separate your text from your images lets you make those updates in the markup or wherever the content is stored. While it’s not overly difficult to open Photoshop for image updates, the more you can keep it to a minimum by styling your plain text or using sIFR, the better off and more flexible your site will be.

Good Separation

Finally, if good markup is your foundation, good separation of the different layers is your finishing flair. By clearly separating your style from your structure, you’ll be free to make updates to one area without severely impacting the other.

Summary

See, that’s not so bad is it? With a little awareness and adjustment, you’ll be building bulletproof sites in no time. Updates will be easier, visitors will be happier, your code will be a thing of beauty, and your life in general will be more fulfilling. Well, I can’t guarantee the last part, but with the time savings, you might be surprised.

If you’re interested in finding more detailed solutions to help your code bend instead of break, I suggest checking out Bulletproof Web Design by Dan Cederholm. He does an excellent job going into detail describing solutions for many of the common problems.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Web Standards, Web Design