cforms contact form by delicious:days

What is “Fun?”

“I’ll know it when I see it.”

In 1964, in Jacobellis v. Ohio, the US Supreme Court needed to decide whether the state of Ohio could ban a film it called “obscene”—a concept people understood but were hard-pressed to define. Justice Potter Stewart, in his concurring opinion, wrote: “I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.”

As designers, we get a lot of similarly elusive adjectives from clients, as they tell us what they want their sites to be: “The site needs to be ‘cool,’” “It should be ‘exciting,’” “I want it to ‘pop.’” When we ask them to clarify, the answer we get back sounds a lot like “I can’t tell you what it is, but I’ll know it when I see it.”

“Fun” is a particularly difficult concept to define. And we’re starting to hear it a lot more from clients as we design for different contexts of use.

The good news? We all have an idea of what “fun” is. The bad news? The nuances in these ideas—among designers, clients, and most importantly, users—can mean the difference between a successful project and an unsuccessful one.

So what’s a designer to do?

Fortunately, it’s possible to create designs that are “fun” without resorting to the old “I’ll know it when I see it” method. There will always be an element of subjectivity in designing fun, but by defining, researching, building, and measuring, we can develop a long-term approach for incorporating “fun” into our designs. And maybe even have some fun in the process.

Designing for fun

In my experience designing for kids, I’ve had success designing for fun by using a specific set of activities. While there’s no perfect formula, these steps have helped me (and my clients) move past the “I’ll know it when I see it” phenomenon.

Steps for designing fun

• Define It
• Rank It
• Research It
• Task It Out
• Test It

Define It

In the late ’90s, I designed a kids’ website for Georgia Public Television. We had great requirements, a motivated client, a fabulous group of kid collaborators, and super-cool content. We conducted loads of research and iterated through paper prototype tests to make sure we were on the right track. But when we showed our client—we’ll call her Barbara—the first round of design comps, she looked crestfallen. She said, “It’s nice, but it’s not ‘fun.’” We were shocked. What about our beautiful, colorful, inviting screens wasn’t “fun?”

We found out that Barbara’s definition of “fun” was different than ours. She wanted something with movement, and our designs, lovely as they were, didn’t move. Fortunately, in 1998, adding “movement” meant throwing a couple of animated GIFs on the home screen, so we were able to fix the problem pretty quickly. But the larger issue—that we didn’t agree on what “fun” meant—put us at risk of making our client (and potentially our young users) unhappy.

What we should have done at the beginning of the project was operationally define “fun”—to come up with an agreed-upon definition and set of expectations to guide us—and then evaluate that definition with users during research.

Here’s an example of what an operational definition might look like for a similar project:

Operational Definition: “FUN” means engaging six–eight year-old kids and parents in unexpected ways, using characters and videos from XYZ TV show to amuse, inform, and entertain.

For this site to be “fun” it must include:

• motion and sound (both user generated and non-user generated),
• bold colors and background textures,
• imagery instead of text (where possible),
• short, action-oriented copy blocks,
• video clips embedded in the design,
• opportunities for “unexpected” interaction, and
• “game-like” exploration.

You’ll want to evolve the expectations based on what you learn from users, but defining “fun” before you start designing it helps set you up for success.

Once you agree on a definition, look for examples of sites, products, or apps that illustrate that definition, as well as examples of things that don’t. These examples will help clients understand the definition and decide if they agree. They’ll also give you materials to use during research.

Rank It

Figure out how important “fun” is to the site as a whole. Will it fail completely if it’s not fun? Or will adding fun elements distinguish it from its competitors and make it more pleasurable to use? You don’t need complex calculations and quantitative ranking here, just a quick prioritization exercise to see how much or how little you should emphasize fun during the design process.

Here are some questions to use when ranking fun:

1. Why do you want the site to be fun?
2. How will a fun site influence your users? (Will it help/hinder people from completing tasks or getting content?)
3. How does “fun” fit in with the site’s content, message, and actions?
4. How will a fun site affect how people perceive the product or brand?
5. How will your site fare against competitors if it is (or isn’t) fun?

Based on your answers to these questions, rank “fun” on a scale of 1–3, where one is the highest priority and three the lowest.

1. A rank of one means fun is essential to the site’s success. Conduct extensive user research to see if your definition is correct, revise if necessary, then laminate your definition and hang it on the walls of everyone involved in the project. Add the definition to your requirements and enlist project stakeholders in ensuring it is met through the design and functionality.
2. A rank of two means fun will enhance your users’ site experience and differentiate you from competitors. Do some interviews to see if users agree with your definition, and then add it to your requirements as a medium-priority item. Make sure the team keeps the definition in mind when designing.
3. A rank of three means fun will improve the site experience, but users won’t feel a tremendous impact if it’s not fun. Do some quick surveys to see if users define “fun” in the same way you do, and add your definition to the requirements as “nice to have.”

Research It

Once you’ve defined and prioritized “fun,” you’ll need to see if your users feel the same way. The research technique(s) you choose for this depend on your definition and ranking.

Some research options include:

• Surveys: Surveys will give you self-reported informational trends about how people feel. You won’t get a lot of insight into how fun affects user behavior from surveys, but you’ll be able to learn if your users define fun the same way you do. Surveys can also help you quantify and rank user attitudes.
• Interviews: Interviews let you observe users’ reactions as you show them the examples you gathered. You’ll also be able to ask follow-up questions when you need more information. You won’t get statistically relevant results, but you’ll have a chance to see users’ thought processes in addition to understanding their definition of “fun.”
• Observational Studies: If you’ve ranked “fun” as highly important to the site’s success, you may want to conduct observational studies. These let you watch people use the example sites you’ve selected. You’ll be able to see first-hand how users define fun. More importantly, you’ll see how and if fun affects their behavior.

It really doesn’t matter what technique you use as long as you evaluate your definition with the people who will be using the site.

Task It Out

A design itself isn’t fun. It’s how the elements and actions come together within the design that makes it fun. If you think about fun in terms of activities that could enhance your users’ primary goals, you’ll have an easier time designing the flows and processes to fit your definition.

First, come up with a set of actions that imply fun. You’ll want to tailor these to your users and site goals, but here are some good ones to start with:

• Play
• Explore
• Create

Then, figure out ways to incorporate these activities as part of the main user tasks.

Play

Let’s look at two examples from the travel industry: Wanderfly and Orbitz. Wanderfly does a nice job including elements of “play” in its trip-finder design. Instead of standard click-and-select drop-down menus and text entry fields, it invites users to play via selectable buttons and draggable sliders. This makes the travel-planning process easier and more enjoyable.

Fig 1: Wanderfly’s trip finder invites users to play.

Providing opportunities to play increases Wanderfly’s “fun” quotient. What’s important to note here, however, is that Wanderfly uses play to facilitate—as opposed to detract from—the main user goals. That’s pretty hard to do. You’ll need to evaluate, during usability testing, whether your design uses the concept of “play” to make tasks easier and doesn’t take users’ focus away from what they’re trying to do. People will come to your site for a reason; they aren’t looking to just mess around with cool interactions.

Orbitz’s trip finder, while functional, isn’t exactly “fun.” Users can easily make travel arrangements, which is the main site goal, but the site doesn’t go out of its way to make the experience pleasurable.

Fig 2: In contrast, Orbitz doesn’t go out of its way to be playful.

If you’ve identified “fun” as a site goal, see which tasks (if any) would lend themselves to elements of play.

Explore

Discovering and uncovering unexpected functionality as part of a goal can make the overall experience more enjoyable for users. Let’s take a look at some examples from the world of finance.

Reuters invites exploration with its lovely world markets infographic:

Fig 3: Reuters’ world markets data infographic invites exploration.

Reuters uses a map of the world to invite exploration. By placing data geographically on the map, the site lets users achieve their goal—seeing market stats—in a fun and engaging way. The red and green circles show users whether the markets are up or down, and by how much. Rolling over the market name reveals percentage information. Reuters uses exploration and discovery to help users get the information they need in an easy and pleasurable way.

Let’s look at similar data from Bloomberg:

Fig 4: Bloomberg’s world markets data, less exploratory in design.

Nothing’s wrong with Bloomberg’s design, but it’s not especially enjoyable to use. I would argue that the absence of “discovery” here removes a layer of information available on the Reuters’ map. Users can’t as easily visualize the market area they’re looking for.

“Fun” may not seem like an important goal for a finance site, but incorporating elements of play and exploration can make it easier for people to find and understand data.

Create

Allowing users to create something—be it a product, a service, or the site itself—introduces fun into the design. This works especially well on commerce sites, where users are looking to buy a certain product.

Let’s look at sites selling engagement rings. Blue Nile’s interface lets prospective brides and grooms create their own designs.

Fig 5: Blue Nile’s “Build Your Own Ring” interface lets users build and create.

By allowing users to build and create a product, the site adds an element of fun to what can otherwise be an overwhelming shopping experience. Fun in this instance not only helps people accomplish their goals, it also keeps them engaged by “revealing” prices as they move through the creation process.

Contrast that with Kay Jewelers’ engagement-ring commerce design:

Fig 6: Kay Jewelers’ engagement ring display forces users to choose from existing designs.

Kay shows users page after page of row after row of engagement-ring settings. Other than filtering results by price and metal, users can’t really do anything to make the process more personal, inviting, or fun. Even if Kay just added more robust sort or filter functionality, like Tiffany’s does below, it would give a sense of creation and exploration.

Fig 7: Tiffany’s engagement ring finder provides additional “creation” options.

Inviting people to use your site to create increases the fun factor and can make it easier for them to complete their main goals.

When designing, see how these activities can compliment the site’s key tasks and goals. If you find incorporating these actions into the interaction design makes it harder for users to accomplish tasks, you’ll want to either select different activities or re-evaluate how you’ve ranked fun in importance to the site’s success.

Test It

So, you’ve defined, ranked, evaluated, and tasked, and you’ve come up with a great design you and your clients agree is fun. How do you know if you’ve succeeded without falling into the “I’ll know it when I see it” trap?

You can evaluate “fun” along with usability during standard task-based testing. But it takes shrewd listening, observing, and questioning skills to do this without leading participants.

Since “fun” is not a behavior, it’s difficult to observe and interpret. You’ll need to lean heavily on the talk-aloud protocol. Listen to the adjectives participants are using as they’re completing the tasks you’ve given them, and watch their facial expressions.

Context is really important here. You don’t want your site to be so much fun that users don’t accomplish their (and your) intended goals. You also don’t want the fun aspects to get in the users’ way. Ask users to complete different, yet similar, tasks multiple times, where they have to use the same mechanisms and see similar design elements. If they seem annoyed or frustrated, chances are the “fun” is holding them back from doing stuff quickly. If they enjoy the process and can complete tasks quickly, the design is probably working for them.

After you’ve finished the task-completion activities, ask follow-up questions about the site as a whole. Listen for “positive” adjectives like fun (obviously), interesting, cool, unexpected, easy, engaging, and simple, and for “negative” or “neutral” ones like boring, fine, as expected, normal, difficult, and annoying. The adjectives won’t tell the whole story, of course, but they will give you insight into how users view the overall design.

It’s also a good idea to post a self-selecting survey when the site launches, and then again 3–6 months later. Include a question about how often respondents use the site on a daily, weekly, or monthly basis, depending on site goals. This will give you initial feedback on how users respond to the fun aspects of the site and whether or not they’re still fun after several months of use.

In Conclusion

“Fun” is always going to have an emotional component. No matter how closely you follow the above process, someone is going to disagree—with your definition, ranking, tasks, or design decisions. However, by thinking critically about what it means for a site to be “fun,” and by taking the time to define, evaluate, task and test, you’ll be able to move away from “I’ll know it when I see it” to “I’m confident you’ll design something I think is fun.”

Editor’s note: A List Apart readers can use the discount code ALISTAPART to save £150 off the regular conference rate for Content Strategy Forum, London which takes place from September 5th—7th.

The web’s hit the big time in a way few of us imagined possible. So as people who make websites, you’d think we’d be celebrating our repeated successes in designing amazing user experiences, as the organizations we work for become increasingly successful. But many of us have noticed a problem in our work: the user experiences we deliver don’t meet our expectations. Here’s the problem: organizations are the context for our work, and when it comes to the web, organizations are broken.

Consider these common project scenarios: a website redesign, a web application, or an email or social media campaign. We keep hitting brick walls because the organization has problems with strategy, governance, execution, or measurement. We know that the project won’t achieve its objectives, because we’re working on the wrong horizon of focus. To fix this problem, we need to start talking about web governance.

Defining web governance

What is web governance? That’s a difficult question to answer, because business language is slippery and organizations and modern web management are complex. Luckily for us, Lisa Welchman has pioneered this space. She’s already defined the areas we need to learn about.

We’ll use “web governance” as an umbrella term to cover the four components of web strategy, web governance, web execution, and web measurement. Let’s take each in turn.

• Web strategy should be created by senior management to establish guiding principles for the web: high-level objectives and metrics based on the organization’s business strategy. It also formalizes authority and funding for the web within the organization.
• Web governance defines decision-making processes for the web, and sets policies and standards for web content, design, and technology—in a way that respects subject-matter expertise. (For example, your CEO shouldn’t be setting standards for markup or tone of voice.)
• Web execution ensures that the organization has an appropriately staffed and resourced web team that can realistically execute the web strategy. (This is where most A List Apart readers work at the moment.)
• Web measurement measures web performance against the high-level objectives and metrics set by the web strategy. While web analytics help to achieve this, we should be careful not to confuse the numbers we read in analytics tools for web measurement—we need to relate those numbers to business objectives to truly measure success.

One more definition: Key Performance Indicators, or KPIs, is business jargon for the numbers managers use to measure the success of their organization. The point of a web strategy is to relate the success of the organization’s web properties to its overall performance—in other words, to engage senior management with their online successes or failures. To do that we need to talk about the KPIs they care about. Unsuck It defines KPI as, “Measurement (of success).”

The web changed the world and organizations are in denial

Organizations have been using the web for more than 15 years. During that time, it’s grown from being one channel among many to being the channel: the website is now the digital manifestation of the organization, critical to marketing and sales, communications, branding and reputation, and customer service and support. The internet revolution has created huge social change: it’s changed the way people relate to organizations and it’s already destroyed several once-mighty industries, like newspapers, travel agents, and music publishing.

Although we’re comfortable with the idea that the web is critical to organizations, we often miss the corollary: the web has changed the way organizations operate, and in many cases it’s changed their business models, too. When executives can’t see that, it causes a crisis. Welcome to your daily web-making reality.

Organizations manage the web badly

To stay competitive, modern organizations need web strategy, web governance, web execution, and web measurement. But most organizations suffer from:

• organization-centric thinking and widespread denial about web-related change, combined with no formalized authority for the web, resulting in weak web strategy,
• a lack of standards, policies, and decision-making processes for the web, combined with turf wars between organizational silos, resulting in no web governance,
• inappropriately staffed and resourced web teams, resulting in lackluster or patchy web execution, and
• a lack of appropriate web metrics linked to KPIs, resulting in no realistic web measurement.

Denial isn’t a strategy

By sticking to what they know—that is, pre-web operational practices—executives are crossing their fingers and hoping that time will run backwards. This is crazy. Consider some of the risks they’re taking:

• legal and regulatory risks caused by out-of-date, inaccurate, or poor quality content (i.e., no content strategy),
• reputation and brand risks caused by lack of web policy (e.g., for the corporate social media presence),
• compliance risks like violating regulations about accessibility, data protection, consumer protection, or disclosure caused by lack of standards and policies (web governance),
• risk of losing market share to more agile competitors who can respond more quickly to events, caused by poor web governance (which leads to slow decision-making),
• customer relationship risks when customers have difficulty completing top tasks, caused by a lack of web measurement, and
• financial risks associated with wasting customers’ and employees’ time, caused by poor web strategy.

Organizations are like oil tankers headed the wrong way as if the web never happened. And we can see the approaching iceberg.

We need to tackle organizational change

As web professionals, we strive to serve users’ needs while simultaneously achieving business goals. Although that sounds great, nowadays it’s actually impossible to achieve without tackling organizational change.

We’ve learned that effective user experience work isn’t about taking a single channel, campaign, product, or website, and designing the smoothest possible experience. To actually improve user experience in a sustainable way—that is, while achieving business goals—we need to help organizations deal with the revolutionary changes that the web has created in their business models, operational structures, and customer relationships. As Adaptive Path argues in their book, Subject To Change, organizations need user experience design as a core competency.

You might call this approach service design, multi-channel user experience, or top task management, all of which are valid labels. Today we’re calling it web governance.

Aside: why everyone’s talking about content strategy

This helps to explain the huge impetus behind the discussion of content strategy. Web content is the one thing you can’t touch without involving every part of the organization, which is why most organizations are in denial about it—they’ll do anything to avoid talking to each other. It also explains why so many web teams attempt to bypass the thorny issues surrounding content by repeatedly redesigning, launching short-term tactical campaigns, or spending money on technology. Smart web professionals realize that we can’t deliver great user experiences without content strategy, so it’s our most obvious blockage. But it doesn’t follow that getting better content will solve the web governance problem. It’s the other way around: we can’t sustainably create, publish, and govern quality content unless we start to solve the organizational problems around web governance. As Karen McGrane puts it, content strategy is change management.

Web governance is about changing working practices to match reality

Simply telling the organization that it needs to change won’t have any effect. We have to become change agents ourselves.

More specifically, we can’t change organizational culture on our own. That culture is being forced to change by outside forces, so our job as change agents is to help to change working practices so they start to match the organization’s reality. It’s about pointing out risks, shining a light on organizational denial, overcoming resistance, and facilitating constructive discussions about change.

We’re facing a stark choice

If that doesn’t sound like what you want to be doing with your career, stay with me. There’s a huge upside: actually shipping user experience work that meets user needs while achieving business objectives. How much of your work so far has achieved that over a sustained period? Speaking for myself, not much. As web professionals, we’ve always wanted to make meaningful change in the world. Tackling web governance will get us there, even if the journey scares the hell out of us.

We’re facing a stark choice right now: keep whining or start leading.

Are you crazy? Why me?

You might be thinking: “There’s no way I can do this. I’m a designer, developer, or copywriter, not an organizational change maker!” But we can do it, and we should. Because nobody else will do it for us, and if nobody deals with the problem, we won’t be able to do great work.

Today, the critical skills of a web professional aren’t technical. They’re skills like advocacy, facilitation, diplomacy, pragmatism, and patience. Technical skills still matter, but they don’t differentiate us in the market anymore, and we can’t use them effectively without tackling organizational change. To be effective, we need to leave our comfort zones.

The skills market is changing

The choice is stark because the skills market itself is changing. The era of charging a premium simply for knowing how to code HTML and CSS, install a content management system, design wireframes, or write for the web are behind us. And if you live in a high-cost location like North America or Western Europe, sticking to your professional comfort zone will likely lead to commoditization, low pay, and ultimately frustration and depression.

Another way to look at the problem is through the organizational context for our work. Until recently, we got away with a Wild West approach to web management: anything goes, no accountability, no measurement. As Christine Pierpoint argues, executives won’t put up with this attitude for much longer.

It’s time to broaden the scope of web standards

We learned from the web standards movement (and parallel campaigns to demonstrate the value of information architecture and user experience) that we have the power to make a difference, if we do the work of articulating why the practices we advocate can help people achieve their goals. It’s time to broaden the scope of web standards beyond interoperable, accessible markup and scripting languages for web content. Organizations need web standards that cover these areas, but they also need web standards for editorial considerations (see content strategy), design (see user experience design), and technical considerations (see structured content, interoperability, data governance, hosting, etc.).

As a community, this is something we know how to do. Let’s rise to the challenge.

Start a web governance campaign

So we’ve decided to give this web governance thing a shot.

The most important step we can take is to get started, which means leaving our comfort zone. Becoming a change agent means getting used to doing things that we find scary: challenging assumptions, asking questions about business goals and risks, and facilitating discussions about change. We need to articulate the problem so that our stakeholders will understand it and find it difficult to ignore. To get there we need to do some homework. Here are some questions to get started:

• What are our business goals? Do we have a written web strategy? (We need one.)
• How does the organization make money (or equivalent for non-profits), and how are web operations linked to that? How is that measured?
• How much do our web operations cost, and how much money do they make? (In most cases nobody can answer this question, which is a problem.)
• Has anyone documented the decision-making process for the web? Do we have any standards and policies?
• How are our web teams staffed and resourced? Do we use external agencies, or is everything in-house?
• How are we measuring success on the web? Are web metrics linked to the organization’s KPIs?
• Has anyone documented the legal, financial, and reputation-related risks we’re taking on the web?

As well as asking questions, we’ll work with what we’ve got: web analytics, sales numbers, data from annual reports like KPIs, and web case studies like A/B test results, especially anything that demonstrates how a design change influenced customer engagement or profitability.

Articulate the problem

We’ll attempt to articulate the problem in a way that relates directly to:

• the executives’ actual jobs, e.g., their targets and renumeration,
• the risks we’re taking (legal action, lost customers, competitive advantage, profitability), and
• what the competition are doing, and how that might impact profitability and market share.

In short, sell to their pain. For maximum influence, we must speak in management-friendly language, making them feel smart by avoiding tech-speak and jargon and being as clear as possible.

Build a business case

As bland as it sounds, organizational change happens when people build a compelling business case.
If we can put dollar signs behind every recommendation we make, our stakeholders will be more likely to listen. We need to combine the scare tactics of pointing to risks and lost revenue with specific, positive suggestions of next actions that will start to address the problem. For example, check out Melissa Rach’s guide to putting a dollar value on web content.

Get help from the outside world

We can get help from the community outside of our organizations by attending meetups about web strategy, content strategy, web management, or intranets, to share our knowledge and learn from other people’s experiences. If there’s no meetup in your area, start one. We can also attend relevant conferences,
pitch presentations to those conferences, and blog about our experiences (without revealing anything confidential, of course.)

Another way to get an outside perspective is to commission a study from consultants. We could also try some targeted usability testing to demonstrate the influence our web governance problems are having on real, live customers. Once our stakeholders understand that effect on a personal level, they’ll find it easier to see the bigger picture.

Build support for change within the organization

Get a sponsor: someone senior in the organization who cares about this problem and wants to fix it. Let’s find that person, and get them to teach us how change happens: who should we speak to, when, and how should we present our case?

Make allies

Web governance isn’t about getting our own ideas implemented—it’s about building support and awareness among other people in the organization. Why not treat our web governance campaign like a communications project, complete with target audiences, key messages, and business goals?
For example, Sarah Marx Cancilla’s team built support for content strategy within the
engineering-led hacker culture at Facebook with their “Friends of Content Strategy” campaign of group lunches, practical tools, targeted case studies, and cool tee-shirts.

Get people talking about governance in a positive way

We’re trying to create an open, non-confrontational context for stakeholders from different organizational silos to start talking to each other, so they can align around goals, work to find differences of perspective, and clarify objectives, metrics, and challenges. Once people get used to talking about the issues—and they see that alignment is actually possible—it’s easier to convince them that working together on web governance will help them achieve their goals.

Keep your eye on the prize, but be realistic

It takes a long time to turn an oil tanker. Instead of setting ourselves up for failure by trying to fix everything at once, let’s make our objectives realistic. For example, in a large organization we might need to spend weeks on the road visiting different teams just to get alignment on a project.

Start a pilot project

Choose a pilot project that has a good chance of getting results: an easy win. For example, is there
a section of the website with dire analytics, or a piece of content that’s clearly losing
money because of poor web governance? Once we’ve found our pilot project, we’ll state what we’re going to do, and set a clear metric so everyone knows what success looks like. Then we’ll start the pilot project and measure the results. If it succeeds, we can make a big deal of it, write a case study, and use that to build a business case for broader change. If it fails, we’ll reframe the problem incorporating what we’ve learned, and then try again.

Keep up the momentum

Once the boost of our initial success fades, we’ll enter a dip in enthusiasm. Lesser mortals would give up at this point, but it’s crucial that we keep going. If that sounds like too much work,
ask yourself how committed you are to this organization. If you don’t genuinely care whether the plan works, consider your options. This place might not deserve you, and there are hundreds of other places that desperately need your help.

The opportunity of a lifetime

We’re living through a revolution as significant as the industrial revolution—as Clay Shirky has pointed out—and it’s already had a huge influence on our personal and social lives, the way our organizations operate, even our politics and civic institutions. Although working on web governance might sound like the last thing we’d want to do, I think we’re lucky to have the opportunity: our skills and experience as web professionals mean we’re uniquely placed to do this work. Our parents never had it this good.

Let’s get out of our comfort zones and start to make some change within our organizations, so that they can begin to deal with their new internet-era reality. We’ll be glad we make that choice.

All you disco-dancing designers out there (no more anticipation of alliteration) have been loving the new features CSS3 provides for making websites look cool in an easier, less hackish, and more straightforward fashion. Features like CSS3 gradients, drop shadows, rounded corners, animations, and opacity are giving us the promise of less time spent in Photoshop, fewer horribly nested divs, more flexibility, and more fun! Not to mention more time down at the pub, excitedly showing your friends your latest cool experiments on your iPad, while sipping on a smooth glass of ale with an intense air of self-satisfaction and smugness. Face it, most of us have enjoyed such a moment!

The new breed of CSS3 shizzle even allows a self-confessed design amateur like myself to produce some fairly tasty looking designs. CSS3 is here, CSS3 is fun, and CSS3 allows us to evolve the look of the web as we go. At least, that’s the theory. But the reality is a bit different:

• On both desktop and mobile (and other alternative browsing devices) there are rendering engines out there other than Webkit. (Many designers out there forget this, and don’t consider the fact that it isn’t that hard to make the new CSS3 features work in other browsers, too.)
• Some browsers in use today support a reasonable set of features, while some support none at all.
• Some of us have real live clients who want their websites to look pretty much identical, even across older browsers.

Ok, I’m probably not saying anything that you don’t know already. But putting our fun experiments aside, what CSS3 stuff can we really start using in a wide variety of production sites, right now, without having to wait 10 years until IE6 finally dies of old age and we have to start learning CSS4?

I won’t cover anything approaching all of the features found in CSS3, as, well, I’d be here until Christmas and miss Coronation Street. For now, I will get down to business and look at some of the basic CSS3 yumminess we all know and love, and how to make it as cross-browser as possible:

• Linear gradients
• Drop shadows
• Opacity
• Rounded corners
• Web fonts

A suitable example?

To illustrate my points, I’m going to create a funky little bling box and use it as my playground. Here’s what it looks like in the latest versions of Opera, Firefox, Chrome, and Safari:

Fig. 1: CSS3 example as shown in a browser that fully supports CSS3.

We will make some updates as we go along. You can view the initial bling example running live: feel free to do some testing and updates of your own, as I’m sure you can get it looking tastier than I can.

In this example, I’ve taken a simple HTML5 page with a section element containing some content, and blinged up that section with some fairly gratuitous CSS. I’ll not walk you through all the code, as you would find that tedious; I will, however, point out a few of the more interesting features.

Web fonts

To start with, I went to Font Squirrel, found a fairly nice looking font, and then used the @font-face generator to create cross-browser code for including my font which will work across pretty much any browser:

@font-face {
  font-family: 'MEgalopolisExtraRegular';
  src: url('megalopolisextra-webfont.eot');
  src: url('megalopolisextra-webfont.eot?#iefix')
    format('embedded-opentype'),
  url('megalopolisextra-webfont.woff') format('woff'),
  url('megalopolisextra-webfont.ttf') format('truetype'),
  url('megalopolisextra-webfont.svg#MEgalopolisExtraRegular')
    format('svg');
  font-weight: normal;
  font-style: normal;
}

Rounded corners

To make my example Web 2.0 compliant, I made sure to give my box at least one rounded corner:

border-radius: 30px 0 0 0;

Text shadows

Next, I included several text shadows on the h1 to give it a rather nice-looking 3D effect:

text-shadow: 0 0 1px #000,
  0 0 1px #aaa,
  0 0 2px #999,
  0 0 3px #888,
  0 0 4px #666,
  0 3px 3px rgba(0,0,0,0.5),
  0 4px 10px rgba(0,0,0,0.5);

I also included a simple text shadow on the paragraph to ensure readability if darker colors are chosen for the background color:

text-shadow: 1px 1px 1px 

(Note: inspiration for my text shadow effect was taken from the rather masterful Jan Henrik Helmers.)

Box shadows

I also added multiple box shadows, including multiple outer box shadows to give the box a more natural feel with multiple light sources, and an inner box shadow (specified by the inset keyword) to give the box some depth:

-webkit-box-shadow: 5px 5px 20px #000,
  1px 1px 1px #000,
  10px 10px 70px #333,
  inset 10px 10px 20px rgba(0,0,0,0.4);
box-shadow: 5px 5px 20px #000,
  1px 1px 1px #000,
  10px 10px 70px #333,
  inset 10px 10px 20px rgba(0,0,0,0.4);

Note: I’m including the -webkit- prefix version; as of the time of this writing, Safari still needs this for box-shadow support. You should always put the non-prefixed version last when using vendor prefixes, so that when browsers stop using the prefix and support the final version, the non-prefixed version will override any different behavior exhibited by the prefixed versions earlier in the source.

Linear gradients

Linear gradients are currently supported across all of the newest browsers with vendor prefixes. We therefore need to add a few lines to get them working cross browser. For my blingtastic example, I have added a white gradient going diagonally across the box at 60 degrees to give the box a nice bit of texture:

background-image: -ms-linear-gradient(60deg, rgba(255,255,255,0),
  rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: -moz-linear-gradient(60deg, rgba(255,255,255,0),
  rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: -o-linear-gradient(60deg, rgba(255,255,255,0),
  rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: -webkit-linear-gradient(60deg, rgba(255,255,255,0),
  rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));
background-image: linear-gradient(60deg, rgba(255,255,255,0),
  rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));

Opacity

You’ll notice above that for the linear gradients and inner box shadow I’ve used RGBa colors, e.g., rgba(255,255,255,0.2). I’m not varying the color channels, only the alpha channel, so I’m using just pure white and black with varying transparency. The color you see is actually the background-color shining through from behind. This is a great technique in many ways: browsers that don’t support linear gradients will still show a background colour, which is important for readability, and you can simply vary the background-color value to create different color schemes with the effect maintained:

Fig. 2: The same code, but with background-color: .

Crashing down to reality

Great! The design looks cool, and we can go back down to the pub, to show off our groovy experiments again and perhaps break it up a bit by sniggering as we recount the World of Warcraft jokes in The Big Bang Theory. Right? Well, not really. We have a problem. The design is looking less than great in slightly older browsers, and terrible in really old browsers. What should we do?

To start, in order to get browsers to treat the new HTML5 elements properly, we need to set them to display: block; in our CSS:

hgroup, article, header, footer, section {
  display: block;
}

Next, to get IE to permit styling of these unrecognized HTML5 elements, we need to create instances of them in the DOM, like so:

script
  document.createElement('article');
  document.createElement('section');
  document.createElement('hgroup');
  document.createElement('header');
  document.createElement('footer');
/script

Here’s how things are looking in some older browsers:

Fig. 3: Firefox 3.6 on Windows: most of the features apart from the web fonts and text shadows are missing.

Fig. 4: Safari 4 on Windows: again, most of the features apart from the web fonts and text shadows are missing.

Fig. 5: Opera 10.60 on Mac: apart from the gradient, things are pretty good in Opera.

Fig. 6: IE 9: most of our design is there, but text-shadow is not supported, and the box shadows look weird.

Fig. 7: IE 6–8: pretty much everything is missing, except for the web fonts.

Your choice of testing browsers may vary of course, depending on your target audience and other factors.

Picking up the pieces

I am mainly going to worry about IE here, as most of the other browsers get updated pretty regularly, while IE suffers from “old version lock in” syndrome.

Given that, the most reliable way to fix our cross browser issues is to use JavaScript. Yes, I know: it’s less than ideal to use JavaScript to make up for a lack of CSS support, as some users may have it turned off, and you might also find that your pages suffer significant latency as a result of the extra number crunching. But I tend to think of it this way: if a user is browsing the web with JavaScript turned off, their web experience will be pretty crappy anyway, so the loss of a few visual effects is not going to dramatically affect them. In terms of slowing down your pages, you’ll have to judge this on a case-by-case basis.

If you’re antsy, you can test my updated version of the bling example now; let’s talk about how I got there.

CSS3 pie

The main little helper we’ll look at is CSS3 pie, a JavaScript library that adds support for border-radius, box-shadow, gradients, and RGBa colors to older versions of IE.

Read the CSS3 Pie getting started documentation for instructions on how to use it. The short version is that you download CSS3 pie, unzip it, upload it to your web server, then add the following declaration to all of the CSS rulesets that you want CSS3 Pie to make compatible with IE:

behavior: url(path/to/PIE.htc);

We also need to use a special -pie- prefixed version of the background-image property we are using to apply the CSS3 gradient, and change that particular property to read background, not background-image, as CSS3 Pie doesn’t support the longhand values, just the shorthand. The new addition therefore looks like this:

-pie-background: linear-gradient(60deg, rgba(255,255,255,0),
  rgba(255,255,255,0.2) 50%, rgba(255,255,255,0));

The old IE versions now render the design like this:

Fig. 8: The example as rendered in IE8 with CSS3 pie used to add support for the CSS3 stuff.

Now we’re getting there, but what’s with the background color? The answer I found, after a little bit of digging in the CSS3 Pie docs, is that while CSS3 Pie allows IE to render RGBa colors, it can’t render the alpha value; instead, it renders the RGB channels as fully opaque. We are using transparent white variants for the gradient, so it comes out as white. What we need to do here is change the -pie- prefixed background declaration to use solid, non-transparent colors that IE can read properly.

To work out which colors to use, I rendered my bling example in Opera with the inset box-shadow disabled and used the Opera Dragonfly color picker utility to work out which colors were at the edges and middle of the gradient:

With that information, we can update the CSS3 pie background line to:

-pie-background: linear-gradient(60deg, #a600a6,#b630b6 50%, #a600a6);

This does take away some of those flexible advantages we talked about earlier in the “Opacity” section, but it now gives us the following output in IE:

Fig. 9: The example as rendered in IE8 with CSS3 pie used and a fix for the gradient.

Much better! So the only things we are missing now are the text-shadows and the inset box-shadow, neither of which CSS3 Pie supports. This is a bit of a pain, but I’m sure you’ll agree that the result is now much nicer in old versions of IE.

Where do we go from here?

I don’t currently have an answer to the inset box-shadow issue; let’s hope CSS3 Pie improves its range of support soon. For text-shadow, there is a library called IE CSS3 that works in a very similar way to CSS3 Pie, and can add limited text-shadow support to IE; I’ve added it into my final example:

Fig. 10: The final example as rendered in IE8 with limited text-shadow support via IE CSS3 library.

As you can see, it only works on simple text shadows, and not multiple text shadows, so take it or leave it. You could also consider faking text shadows using IE filters, but you will be labelled unclean, and they are proprietary functions that can result in an additional performance hit. See Cross browser box shadows for an example of IE filters in action.

Why not just use jQuery?

This is a good question; you could probably achieve cross-browser support of CSS3 elements using a JavaScript library and be done with it. If you’ve got the skills, then go for it, but I’d argue this way is easier. All you need to do here is add some modified CSS and JavaScript links; you don’t need to write a bunch of JavaScript. This makes it more pure, and certainly more accessible to those of us who aren’t much good with script (like me). Think of it as a small stopgap until we don’t need to support those pesky old browsers any more.

Summary

I hope you have found this exploration useful. If you have more ideas about making this blingtastic stuff work across browsers, share them in the comments! 

While many desk-shackled students may wish they were napping rather than enduring yet another monotonous lecture, learning is by no means confined within the classroom. In fact, we engage in focused learning activities every day. Think of the last time you ordered a book, booked a flight, or bought a car. How did you choose which book to read, where to go for vacation, or which car was best for you? You may have searched online, read reviews, or asked others for advice to help you make an informed decision. In a word, you learned.

Learning is a complex process with distinct stages, each with corresponding tasks and emotions. Understanding how users learn can help us design experiences that support the user throughout the entire process. So let’s learn a thing or two about learning itself.

A hierarchy of learning

According to Benjamin Bloom’s landmark 1956 study, we can classify learning in a hierarchy of six levels, where each level forms the foundation for the next. At the base of Bloom’s Taxonomy lies knowledge and comprehension—the plain facts and figures we were quizzed on at school. Once the learner has knowledge and comprehends it, the learner can begin to apply her knowledge experientially as one might do when driving a car for first time. The highest levels of learning involve deeply analyzing ideas and combining them into something new—the realm of the expert.

Fig. 1: Bloom’s Taxonomy of Learning.

Learning as a process

While Bloom’s Taxonomy reveals the many levels of learning, understanding how these levels flow together in practice is crucial. Carol Kuhlthau, a professor at Rutgers University, studied how students researched topics for term paper assignments.. While roughly consistent with Bloom’s Taxonomy, her research yielded much greater insight into the sequential nature of learning and its implications on the digital environment. Let’s look at Carol’s key findings and see how we can apply them to design for learnability.

Fig. 2: A representation of the learning process from Carol Kuhlthau’s paper “Inside the Search Process.”

1. Initiation

   Initiation is the phase where you become aware that you need information. It’s often accompanied by uncertainty and apprehension. For example, my wife recently told me that she’s tired of taking the bus and wants a car. Hesitant at first, I eventually came around and agreed. Now I have a need to research vehicles.

2. Selection

   The selection phase involves committing to constraints that narrow the information search. In our case, we quickly threw out motorcycles, vans, and SUVs, deciding to look only at small, family cars. This phase tends to produce a spike in optimism once the learner makes the selection.

3. Exploration

   The optimism of selection usually gives way once more to confusion, uncertainty, and doubt as one realizes the many options still left to explore. Even though we had decided on small family cars, we still had to sift through dozens of makes and models, each with advantages and disadvantages. Kuhlthau’s study found that about half of her students never made it past this stage.

4. Formulation

   Formulation is the turning point where all the information encountered thus far is formulated into a specific, tangible requirement. In our car hunt we reached formulation when we decided that a four-six-year-old five-door Nissan Almera hatchback with 30,000–50,000 miles was the best fit for our needs and budget. The formulation stage is marked by less anxiety and increased confidence.

5. Collection

   Once the problem has been clearly articulated in the formulation phase, the next step is to evaluate the available solutions. Once we had a clear of idea of the model we wanted, we used automotive websites to search for cars in our area matching our criteria. Confidence continues to increase throughout the collection process.

6. Action

   The final stage of the process is to perform an action based on the newly acquired knowledge. For Kuhlthau’s students, this meant actually writing the term paper. For me, it will mean going to the dealership, paying, and driving home a new car.

Designing for learnability

Most websites invest the majority of their effort into streamlining the very last stage of this process: the action phase. It’s understandable: businesses make money through conversions. However, the company that best supports the user throughout the entire learning process has the upper hand in converting that loyal user into a paying customer. With that in mind, let’s look at digital solutions to seven learning-oriented tasks.

Explore

“Unknown unknowns” characterize the beginning of the learning process. Often, users have no idea what’s out there. Rather than expect the user to search for a precise make and model at this point, we must help the user explore. Browsing and flexible filtering options can expose users to serendipitous discovery, while personalized suggestions can help users set off on the right foot.

Fig. 3: Last.fm keeps track of the music you listen to and recommends new artists based on how your musical tastes compare with others.

Fig. 4:TravelMatch.co.uk doesn’t force you to fill in a date or a destination like most travel websites. Instead, they help users explore holiday options by providing flexible filtering, such as the destination’s temperature.

Re-find

Learning can be a long-term activity. Saving a page or item—whether in the browser, a shopping basket, or in a wish list—can help users return to something they found earlier. Showing a list of recently viewed items can also provide a more passive means for helping users re-find.

Fig. 5: Nutshell CRM shows a list of recently viewed items when the user focuses on the search box, but before they start typing.

Organize

While simple bookmarking helps users re-find, a higher-level task is to actually understand the information encountered thus far and how it fits together. Often this simply occurs in the mind; other times we may jot ideas down on paper. Whatever the medium, organizing items and ideas into categories is key to the learning process.

Fig. 6: Foodily not only allow users to save their favorite recipes, but to organize them into meal plans.

Compare

In addition to organizing items into categories, being able to view a side-by-side comparison aids in the analysis process, especially during the collection phase.

Fig. 7: Canon’s website allows users to compare up to three cameras side-by-side.

Annotate

An extension of organize and compare, annotation enables users to enrich collected items with their own notes and ratings.

Fig. 8: Globrix allow users to rate and write notes on each property that they’ve bookmarked.

Monitor

Toward the end of processing learning, the user typically has a decent understanding of what they want. And yet that ideal job, house, or car may still be elusive. The ability to save a search and receive an alert when something new appears can be priceless.

Fig. 9: Primelocation allows users to save a search, as well as to receive a daily email with any new properties matching the user’s criteria.

Collaborate

We don’t often make decisions in a vacuum. Friends, colleagues, and spouses often get their say as well. Unfortunately, the collaborative learning process is very poorly supported on the web today. During my car search, my wife and I often sent links back and forth to one another through email, a less-than-perfect solution. Shared bookmarks and collaborative annotations and ratings would go a long way in making learning on the web more social.

Fig. 10: Google Bookmarks allows users to create lists of bookmarks, share those lists with others, and comment both on individual bookmarks, as well as on the list as a whole.

From the classroom to the computer screen

Far from being monopolized by schools, learning is an essential human activity. Empathizing with and supporting users as they traverse the many stages of learning fosters happier users and a more profitable business. We could all benefit from psychologist Carl Rogers’s wise advice to educators:

A further element that establishes a climate for self-initiated experiential learning is emphatic understanding. When the teacher has the ability to understand the student’s reactions from the inside and has a sensitive awareness of the way the process of education and learning seems to the student, then again the likelihood of significant learning is increased. 

Proposals are difficult. They take too long. They’re usually an exercise in unrequited love. Is it any surprise creative professionals cringe when it’s time to put one together? Proposals are, however, often vital to being in business. Whether you’re running a solo shop or keeping a team of 25 busy, they lead directly to that next paycheck, enable us to keep the gears of business turning, and, ultimately, to make wonderful stuff.

Five critical questions

A compelling proposal requires more than a jumble of clichés and a nervous estimate of costs. It needs structure, organization, and joie de vivre.

We can provide that structure—no matter how complicated the final proposal needs to be—by providing the prospective client the answers to a few fundamental questions:

1. Who are you?
2. Why are you bidding on this project?
3. What do you propose to do?
4. When will it be done?
5. How much will it cost?

Using these questions as a foundation, we can craft a proposal to convince the client that we’re the right team for the job.

What, when, and how much?

“How much will it cost?” or “how soon can you finish?” are questions that no prospective client can apparently resist asking early in the process. Having already persuaded the client that the appropriate time to assess cost and timeline is once pre-bid discussions are complete, we now find ourselves post-discussion and smack-dab in the middle of writing the proposal, so it’s time to make those determinations. It is worth cautioning, however, that healthy client relationships, and consequently well-executed projects, depend not on answers to these relatively superficial questions but instead on deeper levels of compatibility that we will explore later. For now, we should consider how “what,” “when,” and “how much” will influence a well-balanced proposal.

At this point, the budget should at least be partially known, owing either to full and early disclosure by the client or by your persistent investigative work. A wholly undisclosed budget is a problem. No car dealer, realtor, or salesman of any type will waste his time throwing darts at an unknown target. Neither should you.

Exact dates and prices are naturally going to be hard to pin down before the project’s discovery and strategy phases are complete. In your proposal, try to get close—but make it clear that both parties will need flexibility at least through the early stages of the project. Accurately estimating how long a project will last, how large a chunk you will be removing from the client’s wallet, or how many widgets your team will crank is somewhere between a mysterious process and an utterly indecipherable black art. There will be plenty of time down the road to adjust if necessary. (Just don’t forget to include language to that effect in both your proposal and your contract.)

Regarding the “what,” the web industry rightly abhors speculative work. Designing, building, or consulting for free devalues your work and that of your colleagues. Of course that doesn’t mean you should ignore the project’s details. You absolutely need to demonstrate that you understand the context, the problem area, and potential solutions. Show your ability to intelligently discuss the essential aspects of the project. Show that you have, as David Sherwin advocates, pre-digested the problem. Whether you’re building a marketing site, a game, or a full-fledged application, you should be able to relate this project to the state of the industry as a whole and briefly touch upon the techniques you will use. Demonstrating insight into and maybe even excitement about client needs will be well received.

Who? Why?

Every successful proposal results in a partnership. You, the professional and the client team up to create an artifact, which is the product of your relationship. If they had the resources to complete the work in-house, they wouldn’t need you. Since they’ve come to you, clearly that isn’t the case. Therefore, you have an opportunity, an opportunity to describe yourself, your process, and your motivations. Do not take this opportunity lightly. Your words here will dictate the nature of your relationship. Exchanging the role of equal partner for servant is your choice. If you want respect, authority, and control, you must demand it. To do less is a disservice to the client and an altogether unprofessional attitude.

Beyond setting the tone for the relationship, of course, you’re also trying to win some business. The good news for you is that a prudent client—the kind you really want—will choose a web partner on the strength of the entire package. Doing otherwise, selecting on a matrix of numbers, dates, and line items, is an exercise in foolishness, akin to buying a car without knowing the make and model. Relationships, even in business, are founded on and strengthened by mutual compatibility. Proposing to work together on a project is remarkably similar to proposing marriage (despite the obvious and important differences): it ought to be a decision based on both emotion and reason, supported by a high degree of trust. In writing a proposal, you are making the case for the appropriateness of your new life together. These early, hesitant steps toward knowing one another better are crucial.

You might find it helpful to start simply by describing yourself. What’s different about your company? Why does your company exist? Who comprises the company? Where are you located? Don’t underestimate the importance of this narrative.

At some point later in the document, include the contact information for a few of your best clients. References reassure the reader that you are who you claim to be. You might also wish to provide a brief overview of some previous projects similar to the project on which you are bidding. Business is as much (if not more) about people as it is about dollars and cents, deliverables and timelines. If your company is difficult to relate to because your proposal is generic, it shouldn’t surprise you when you are inevitably forgotten.

Above all, don’t be timid. The proposal is where you lay it on the line. It is your ambassador, your emissary. It serves to screen you from undesirable clients and attract the good-looking ones. To do this, it should reflect and clarify the reputation you have already established. Be upfront about your business principles. Stand for something. Even if—especially if—your way is controversial or unique. Full Stop might not agree with Bold about whether the customer is always right, but it’s important that Bold’s potential customers do. Meticulously evaluate every client before issuing a proposal. Once you do, don’t panic if they walk because you stuck to your philosophical guns. You just saved yourself bucket-loads of stress and misery.

Finally, have a reason for offering your services and make that reason clear. Is non-profit work something you’re passionate about? Do you love sports? Is it your mission to help local companies? Realistically, it’s possible that you’re just trying to make payroll or ends meet. That’s okay. At the very least, you can state your commitment to fast, error-free code, clean and simple design, or intuitive content strategy. Find your reason.

Bonus materials

At minimum, to qualify for the job, you must answer the key questions. An outstanding proposal, and one that puts your company in the best possible position, needs more. A few tips:

• Read it backwards. If who, why, what, how much, and when are the scaffolding your proposal hangs on, conscientious attention to the little bits are what can elevate it over the competition. A poorly designed, sloppily worded, or generally slipshod proposal signals the client that your work is of the same poor quality. Don’t send a proposal full of typos and grammatical errors. Have a friend look it over. Try some of these proofreading tips from Purdue’s Online Writing Lab. You’re a professional. Make sure your proposal reinforces that.
• Under-promise. Don’t commit to anything you can’t deliver. It’s better to lose a project by leaving yourself room to over-deliver than to boast of your prowess only to find yourself in the weeds later. Managing expectations is critical to having happy clients.
• Have a template, but don’t be a slave to it. Reuse language about your company, but focus on making the parts unique to this project shine. Proposals ought to be preceded by a period of getting to know the client. Use that knowledge to shape the language, tone, approach, and content. This proposal may be shown to people you haven’t met personally, so make sure it conveys who you are without your presence.
• Shorter is better. Superfluous examples, references, and blathering on about “capabilities” are easily identified as boilerplate and possibly even a bit desperate. Make the client feel special.
• Solicit feedback. Win or lose, each proposal is an opportunity to improve your writing, to hone your story, to get better. What did they like? What didn’t they like? Sometimes your price will be too high. Sometimes you will be bidding against someone who is more suited to the job than you are. Sometimes you failed to write a compelling proposal that gave the client a reason to work with you. Don’t leave valuable information behind.
• Be confident in your work and in your proposal. For every project that goes your way, six won’t—at least in the beginning. Failure, however, is the handmaiden of success. Don’t lower your rates, exaggerate your abilities, or abandon your process in the face of rejection. Confidence—even confidence you don’t always feel—is attractive and will eventually beget results.

Win one for the team

Why should you be selected for this project? Because you’re the cheapest? The quickest? Because you promise to do more than the other guys? Maybe. Sometimes those are the reasons, but they’re also the levers you least want to rely on pulling. Website design and development are services and not, on the professional level, commodities. Providing a commodity is an exhausting, unsatisfying, deadening experience. Doing what you love, on the other hand, working as an equal partner with smart, respectful clients is invigorating.

Establish that collegial relationship at the outset of the project with a personal, brief, sincere proposal. You’ll be glad you did.

Remember high school? Let’s say (hypothetically, of course) someone passed you a note in class that was actually a secret invitation to a party at someone’s house. You learned that a bunch of people were invited, some you knew, some you didn’t, some you liked, and some you’d grown tired of talking to. You ended up going to the party anyway. Everyone was wearing their coolest clothes, showing off, and trying to be smarter and funnier than each other. But the real reason you went was simply to get the attention of a person you were interested in. You may have even scared up the nerve to actually ask them out, and on rare occasions, they may have even said yes. When that happened you were over the moon, but admittedly nervous. But most times, they just ignored you and they went to the dance with someone else while you sat at home and listened to Rush by yourself. (I mean, nothing.)

I thought those days were behind me.

If you work in any kind of service industry you’ve undoubtedly come across the Request For Proposal, or “RFP.” The RFP process has become a standard by which organizations solicit competitive bids. At its core, the RFP process is an attempt to level the playing field and minimize bias. Everyone is held to the same requirements—no special treatment, no rule bending. In return, the organization issuing the RFP is able to select a vendor by comparing apples to apples. That’s the theory, anyway.

Many non-profits, higher education institutions, and government agencies are actually required to issue RFPs.

For non-profits, the drive to secure competitive pricing is an economic necessity. Additionally, it’s important for non-profits to ensure that their donors and supporters are confident that their funds are spent in accordance with the organization’s mission.

As far as government agencies go, well, it’s like chocolate and peanut butter. The bidding process is pretty much automatic. I have always been curious about whether there are state or federal laws that require a bid process for government agencies. I couldn’t find any substantive information to support that for this article, so if you work for a government agency and can shed some light on this for us, please add your two cents in the comments area.

You’re often invited to participate in the RFP process by someone with “contract,” “procurement,” or “sourcing” in their title. Sometimes, you’re asked to access a secret website with a secret password where you find links to a bunch of secret documents. Or, you get an email with an attached ZIP archive loaded with goodies. You don’t know how many others are privy to the secret, but you know you’re not alone.

A Christmas sweater or a Big Jim Sports Camper

You start to weigh your options. This could be the best thing ever. The money could be amazing. It could keep your team busy for months. Or, the demands of the project or client could be impossible to meet. The number of stakeholders you’ll have to achieve buy-in from might fill a high school auditorium. And in the end, you may be forbidden from even promoting the work.

At Happy Cog, we see our fair share of RFPs. In fact, we’re responding to a few of them as I write this article, and we probably will be doing the same months from now. We’re always honored and humbled that organizations think highly enough of our capabilities to invite us to participate.

Despite this, I wouldn’t be entirely truthful if I said RFPs were a source of, shall we say, excitement. RFPs are like those odd high school party moments. It’s kind of like getting a sweater for Christmas as a kid. It’s a present, but it ain’t no Big Jim Sports Camper.

I’m not the only one I know who isn’t thrilled with RFPs. And it’s not because I’m lazy and I don’t want to do the legwork to respond to them. When it gets down to it, I feel that RFPs are simply the least creative way to hire creative people. The rigidity of the process, and the lack of meaningful dialogue makes this little more than a game of roulette.

Heartburn-inducing RFP hallmarks

Micro-details

An RFP, in addition to describing the business need to be fulfilled, can be accompanied by a number of requirements and specifications, including the need to provide or fill out:

• Immigration/security forms/clearances
• Historical financial reports (I have thoughts about that.)
• Proof of insurance coverages
• Tax compliance forms
• Staff bios/resumes
• Examples of similar project experience or case studies
• Lists of references
• Proposed project schedules and milestones
• Cost projections
• Rate schedules
• Non-disclosure forms
• Non-compete forms

And this is all before you even get to write your proposal.

RFPs can also specify a host of very peculiar stipulations. Examples include:

• Submitting multiple printed copies of the proposal via registered or express mail (often requiring the printouts to be labeled “original” and “copy”)
• Submitting PDF versions to a specific email address with a specific subject line, such as “RFP Response for offer TF-124453-G.”
• Requiring submission by a specific time on a specific date, with anything late (even a minute late) being subject to disqualification
• Requiring proposals to be double-spaced using a specific typeface and point size
• Requiring that the proposal response not exceed a certain number of pages
• Requests to know what your office square footage is (I know, right?)
• Requests for “photographs” (their words, not mine) of previous projects

I’ve heard of people receiving RFPs that require you to attach multiple copies of your proposal PDF to an email so copies can be provided to internal teams. Multiple. Instances. Of. The. Same. Attachment.

Are these details simply annoying, or do they actually hinder the process of engagement? Well, both. Business development is expensive. Every minute you spend estimating, writing proposals, developing strategies, and performing pitches costs money. When you waste time trying to satisfy meaningless or extraneous requirements on top of all of that, you inevitably end up having to charge more for your work.

Now don’t get me wrong, I’m not saying asking for things like references, bios, or similar project experience is unreasonable. But assembling that information and re-packaging it when it already exists for public consumption is. At Happy Cog, we publish bios of all of our people on our website, and we are very diligent about publishing case studies of our most relevant work. It’s the most accurate, up-to-date information we publish. There are times when I suspect some RFP issuers haven’t glanced at our website. They’ve simply heard of us somewhere and added us to the distribution list to fulfill an internal requirement. Or so I suspect.

Creativity squashers

Our team is made up of designers, developers, and strategists. We heavily rely on our proposals to perform “show and tell” for us when we can’t in person. We spend a lot of time honing our language, articulating our solutions, and actually making the proposals themselves beautiful. In fact, we spent several months overhauling all of our document styles to maximize readability, consistency, and adherence to our brand.

If an RFP specifies that you must deliver your thoughts in double-spaced, 12 pt. Arial in ten pages or less, isn’t that short-circuiting the creativity the RFP issuer seeks in the first place? It’s tough to articulate your thoughts with arbitrary page limitations in place, and it’s impossible to look pretty in double-spaced, 12 pt. Arial. There have been a number of times when we simply wanted to provide inline, Dribbble-esque screen grabs in our response, only to have that possibility forbidden by the RFP specs. In fact, we would have been disqualified had we chosen to do so.

If you’re issuing an RFP and you’re expecting a creative firm to provide a creative response, well, let them be creative. If they want to send a letter-pressed proposal or post a video to Vimeo, wouldn’t that help them stand out? That’s how people get on TV all the time.

Upfront “creative thinking”

Ah, the request for “creative thinking” as part of a proposal response. Some RFPs expect it, some don’t. You might consider this speculative or “spec” work. Our default stance has always been not to entertain requests for spec work, and the reasons are well documented. A prospective client asking a web designer to redesign their home page without knowing a thing about them is a slippery slope, and it inherently devalues your role as a creative professional.

However, there are instances where the issuer of an RFP has put some thoughts together themselves, and are looking for input or suggestions about them in the proposal. It could be to comment on some comps that they’ve assembled, or to offer some feedback based on some strategic goals. I think those instances are worthy of consideration, as long as the creative professional is not giving away their secret sauce or spending inordinate amounts of time.

Thoughts for those that issue RFPs

Bring back the golf course

To promote uniformity and consistency, RFPs often discount communication. I know of firms that have won very large contracts resulting from RFPs without ever meeting or speaking with anyone on the issuer side. It’s like marrying someone you discovered on an internet dating site after trading just a “wink.”

Speaking from experience, we’ve had our most meaningful business relationships when we speak with our clients-to-be first. Those conversations can happen in a number of ways. You can orchestrate a phone call. You can have a videoconference on Skype, FaceTime, or iChat. Or, in the best case scenario, you can meet them in person with real handshakes, awkward pauses, and all.

How about considering earmarking a few grand in your project budget to pay to bring potential business partners in to talk face to face? Or offer to split the costs? They’ll know you’re serious, and if you end up speaking the same language and even trade some laughs, you may have found yourself a match to feel good about.

Patrick Russell has an interesting take in his article What’s Wrong with the RFP where he states, “The [RFP] process is considered an improvement over the deals made between CEOs on the golf course.”

I guess I’m saying bring back the golf course.

Loosen up

Or, as Sergeant Hulka so eloquently stated in the movie Stripes, “Lighten up, Francis.”

You get more out of people when you let them do their thing. I have a friend whose parents raised him like veal. He couldn’t play outside for very long, he had to study four hours a day (even on weekends), he couldn’t watch TV, or talk on the phone.

To make him the best he could be, his parents actually stifled him by imposing so many restrictions, no matter how well-intentioned they were. When he left home for college, to say he blew off steam is an understatement. It was like watching a steam pipe burst.

Today, he’s not following one iota of the plan his parents established for him. He’s neither a doctor nor a lawyer, but he could damn well be. Instead, he’s living his life as he wants, and is successful on his own terms. Though it took him a while to settle down, he’s certainly hit his stride and he’s doing some amazing things.

My point is this: trying to make creative people fit some mold established as conventional wisdom or best practice may not always yield the best results. Lay the groundwork, but put the onus on the creative person to do what they do best—problem solve. Light the fuse and get away.

Thoughts for those that respond to RFPs

Own the process

I’ve often referenced the project planner we use at Happy Cog. It’s a comprehensive questionnaire we provide as a download on our website, and we require interested parties complete it before we consider working together. Feel free to borrow anything you see in there, as we feel it’s for the greater good.

The project planner is also a fantastic filtering mechanism. If prospects don’t take the time to thoughtfully answer the questions or simply leave them blank, that signals they may not be very invested in the process. On the other hand, if they answer the questions thoroughly, conversationally, or with a sense of humor, we know they are someone we want to continue a dialogue with.

Our planner often short-circuits the RFP process completely. Sometimes prospects issue RFPs because they’re simply trying to convey goals and expectations to you. If you provide the vehicle for them to do that, they may not even need to send you one. Or, if they do, they send it as ancillary material. The planner then becomes the working document. It’s RFP Kryptonite.

Be sel-ec-tive. Be-e sel-ec-tive!

You have to read that subhead as a cheerleader, BTW. Otherwise, just read it as “be selective.”

If you stick your finger in an outlet enough times, you’ll learn not to do it again. Look for what you consider warning signs in an RFP. If you feel it’s simply too arduous, nebulous, or widely distributed, don’t feel bad about passing. There will be other opportunities.

A lot of people say to me, “Easy for you to say. You don’t have to worry about getting work, you’re with Happy Cog. I’m an independent web designer, and it’s tough to find work.”

I hear you.

You know, Happy Cog does have to worry about getting work. Good work. We may see more lead volume than smaller shops or individuals, and we certainly see less lead volume than big agencies. But finding the right opportunity is tough at any scale. You can take what’s in front of you, but if you don’t consider happiness as part of the equation, you’re going to burn out.

If you want to see more opportunities come your way, there’s no shortcut. Do good work. It sounds cliché, I know. But doing good work, being diligent about promoting it, and getting away from your computer to network at conferences and events is, in my book, the holy trinity. The rest takes care of itself. Oh, and don’t steal other people’s work. That’s a decision you’ll regret forever.

Can we change the default?

I’ve shared some observations and thoughts about the RFP process as it applies to creative service providers in this article, and I have spent hours and hours talking with my peers about their own experiences. But I’ve never really considered a way to establish a grassroots movement to change the core thinking behind how business initiates and establishes relationships with creative people.

This is where I’m looking for your thoughts. My colleague Jeffrey Zeldman led a charge to get these things we call web standards in place, making the lives of web designers and anyone who publishes web content infinitely easier. Why can’t we establish a new set of standards dictating how new business relationships sprout? Or is that a pipe dream?

Let me know what you think. Or share your own RFP stories, because they’re fun too.

Now please excuse me while I print this thing in triplicate and send it via nationally recognized carrier by nine a.m.

It was just five years ago that this magazine and its design conference offshoot sought, with your help, to begin determining the precise professional dimensions of our shared craft.

Most serious professions take this kind of self-knowledge for granted. Architects and prospective architects know which are the best architecture schools; they can readily find out the average salaries of apprentice, mid-level, and senior architects in their country and region; they know what titles and honors they can aspire to, and have a generally accurate idea of how long they must toil as apprentices before they can expect to be promoted—or start worrying if they have not been.

Web design, if that’s what we call it, has had no such data. Moreover, no professional organization is dedicated to our field’s advancement in the way that, say, AIGA promotes, explains, defends, and takes the measure of graphic design.

With your help, we took the first steps to change that with the publication of our 2007 A List Apart survey and findings. We have published surveys and findings each year since. Here, admittedly a little late, we present our findings from 2010.

You’ll find plenty of matter in the pages that follow, but little that is unexpected—and that’s to the good, as it suggests that our profession is maturing and developing fairly consistent parameters despite the immense technological change and extraordinary market turmoil of the past four years.

As always, when our findings differ from those of previous years, we call your attention to those changes; when they are about the same as in years past, we point that out as well. And, just as we have always done, at the end of the present findings, we offer the anonymized raw data files for those who wish to slice, dice, and inspect the data their own way.

Our 2011 survey will come out in mid-summer. Watch for it! We can’t do this without you.

With the rise of mobile devices, web development and debugging is more complex than ever. We have more browsers and platforms to support. We have more screen sizes and resolutions. And we’re building in-browser applications instead of the flat, brochure-ware sites of yore.

Luckily, we also have better tools. The JavaScript console is a standard feature of most major browsers. Both JavaScript and the HTML DOM offer native error handling. We also have services and applications that help us remotely debug our sites.

In this article I’ll cover error thowing and handling, code injection, and mobile debugging. For more on debugging, see Hallvord R.M. Steen and Chris Mills’ 2009 article, Advanced Debugging With JavaScript.

Throwing and catching errors

JavaScript lets you report and handle errors through a combination of the throw and try…catch statements, and the error object.

Error throwing is useful for catching runtime errors—say, a function that has incorrect arguments. In the example below, add() accepts two parameters. It will throw an error if the supplied arguments are null, or are neither a number nor a numeric string. (Line wraps marked » —Ed.)

function add(x,y){
     if( isNaN(x) || isNaN(y) ){
          throw new Error("Hey, I need two numbers to add!");
     } else {
	      // ensure we're adding numbers not concatenating »
numeric strings.
	     return (x * 1) + (y * 1);
     }
}

Let’s try invoking add() using invalid arguments. We’ll then catch the error thrown by using a try…catch block and output it to the console:

var a;

try{
 a = add(9);
} catch(e) {
 console.error( e.message );
}

Fig 1: The Dragonfly console error

In Opera Dragonfly (above), we see the error message and its corresponding line number, relative to the script. Keep in mind in these examples we’re embedding JavaScript within our HTML page.

Fig. 2: The Firebug error console

Firebug also includes the thrown error message and line number, but relative
to the document.

All error objects have three standard properties:

• constructor: returns a reference to the Error function that created an instance’s prototype,
• message: the message thrown—the message you passed as an argument, and
• name: the type of error—usually error, unless you use a more specific type.

As of this writing, error objects in Firefox also include two non-standard properties: fileName and lineNumber. Internet Explorer includes two non-standard properties of its own: description (which works similarly to message) and number (which outputs the line number).

The stack property also isn’t standard, but it is more or less supported by the latest versions of Chrome, Firefox, and Opera. It traces the order of function calls, with corresponding line numbers and arguments. Let’s modify our example to alert the stack instead:

var a;

try{
 a = add(9);
} catch(e) {
 alert( e.stack );
}

Fig 3: The stack property revealing the throw error in the code

The stack property reveals where in the code throw Error exists (in this case, line seven) and on which line the error was triggered (in this case, line 15).

You don’t have to throw an error object. You could, for example, throw a message: throw "The value of x or y is NaN." Throwing an error, however, offers richer information in most browsers.

Using try…catch can, however, have a negative effect on script minification and performance. While handy for debugging, your production-ready code should use try…catch sparingly, if at all.

Handling errors using the window.onerror event

The Document Object Model also offers a mechanism for capturing errors: the window.onerror event. Unlike try…catch, you can set an event handler for window.onerror that captures errors you don’t throw. This can happen if you try to invoke an undefined function or access an undefined variable.

When the window.onerror event is fired, the browser will check to see whether a handler function is available. If one isn’t available, the browser will reveal the error to the user. If one is available, the handler function receives three arguments:

• the error message,
• the URL in which the error was raised, and
• the line number where the error occured.

You can access those arguments in one of two ways:

1. by using the arguments object that is native to and locally available to all JavaScript functions; or
2. by using named parameters.

In the example below, we will use arguments. For readability, though, you should use named parameters:

window.onerror = function(){
 alert(arguments[0] +'n'+arguments[1]+'n'+arguments[2]);
}

init(); // undefined and triggers error event.

Fig 4: What our error looks like as an alert in Internet Explorer 9

Here init() has not yet been defined. As a result, the onerror event will be fired in supporting browsers.

Now the caveat: support for window.onerror is limited. Chrome 10+ and Firefox (including mobile) support it. Internet Explorer supports it, but truly helpful error messages are only available in version 9+. While the latest builds of WebKit support window.onerror, recent versions of Safari and slightly older versions of Android WebKit don’t. Opera also lacks support. Expect that to change as the HTML5 specification evolves and browser vendors standardize their implementations.

Modify JavaScript on the fly using the command line interface

One of the more powerful features available in today’s debugging tools is the JavaScript console. It’s almost a command line for JavaScript. With it, you can dump data or inject JavaScript to examine why your code has gone rogue.

Launching the JavaScript Console

• In Chrome: View Developer JavaScript console
• In Safari: Develop Show Web Inspector
• In Internet Explorer 8 9: Tools Developer Tools (or use the F12 key)
• In Opera: Find Dragonfly under Tools Advanced (Mac OS X) or Menu Page Developer Tools (Windows, Linux)

Firefox is a special case. For years, developers have used the Firebug extension. Firefox 4, however, added a native console (Tools Web Console or Menu Web Developer Web Console).

Firebug fully supports the Console API, and has more robust CSS debugging features. I recommend installing it, though the Web Console is a capable tool for basic needs.

I’m using Opera’s debugging tool Dragonfly in the examples below (yes, I work for Opera). These examples, however, work similarly in Chrome, Safari, Firefox, Firebug, and Internet Explorer.

Let’s take another look at the code from our previous examples. We’re going to add a new line—var a = document.querySelector('#result');—one that assumes an element with an id value of “result.”

A quick note about the querySelector() method: it and querySelectorAll() are part of the DOM selectors API. querySelector() returns the first element matching the specified CSS selector. Both methods are supported by the latest versions of most browsers. You could also use document.getElementById('result'), but document.querySelector() is more efficient:

function add(x,y){
 if( isNaN(x) || isNaN(y) ){
     throw new Error("Hey, I need two numbers to add!");
 } else {
     // ensure we're adding numbers not concatenating numeric strings.
     return (x * 1) + (y * 1);
 }
}

var a = document.getElementById('result');

try{
     a.innerHTML = add(9);
} catch(e) {
     console.error(e.message);
}

Fig 5: The Dragonfly console

Our thrown error is still written to the console. But let’s inject some JavaScript that runs correctly. We’ll enter a.innerHTML = add(21.2, 40); in our console:

Fig 6: The Dragonfly console with injected code

As you can see, we have overwritten the innerHTML value of a:

Fig 7: A page with injected code

Now let’s change the value of a entirely. Enter a = document.querySelector('h1'); a.innerHTML = add(45,2); in the console:

Fig 8: Changing code in the console

You’ll see that 47 is written to the console, and it is also the new innerHTML of our h1 element:

Fig 9: Modifying the DOM

Now, we can even redefine our add() function. Let’s make add() return the product of two arguments and then update the h1. Enter function add(){ return arguments[0] * arguments[1]; } in the console, followed by a.innerHTML = add(9,9);:

Fig 10: Overwriting a function using the JavaScript console

The new innerHTML for our h1 element is now 81, the result of our redefined add function:

Fig 11: The results of overwriting a function

The JavaScript console offers a powerful tool for understanding how your code works. It’s even more powerful when used with a mobile device.

Remote debugging for mobile

Debugging code on a mobile device is still one of our biggest pain points. But, again: now we have tools. Opera Dragonfly and its remote debug feature provides developers a way to debug mobile sites from their desktop. WebKit recently added remote debugging to its core and Google Chrome has already folded it into its developer tools.

Independent developers offer similar products for other browsers. These include Bugaboo, an iOS app for Safari-based debugging; JS Console which is available on the web or as an iOS app; and Weinre for WebKit-based browsers.

Let’s look at two: Dragonfly remote debug and JSConsole.

Remote debugging with Opera Dragonfly

Dragonfly’s strong suit is that you can debug CSS or headers (see the Network tab) in addition to JavaScript. But it does require installing Opera on your desktop and Opera Mobile on your device.

Both devices should be connected to the same local network. You will also need the IP address of the machine running Dragonfly. Then complete the following steps:

1. open Dragonfly from the Tools Advanced (Mac OS X) or Page Developer Tools (Windows, Linux) menus,
2. click the Remote Debug button ,
3. adjust the port number if you’d like, or use the default and click “Apply, ”
   

   Fig 12: The remote debugging panel in Dragonfly

4. open Opera Mobile on your target device, and enter opera:debug in the address bar, and
   

   Fig 13: Opera Mobile debug console

5. enter the IP address and port number of the host machine and click “Connec,t” and
   

   Fig 14: The IP and Port fields of the opera:debug console

6. navigate to the URL of the HTML page you wish to debug on your device.

Fig 15: An alert on Opera Mobile

Dragonfly on the host machine will load the remote page. You can then interact with the page as though it was on your desktop. You will see the results on the device. For example, if you enter alert( add(8,923) ) in the host console, the alert appears on the mobile device screen.

Remote debugging with JSConsole

JSConsole is a web-based, browser-independent service. Unlike Bugaboo, Weinre, and Dragonfly, your computer and device don’t have to be connected to the same local network.

To use JSConsole:

• visit the site and enter :listen at the prompt,
• add the returned script tag to the document you wish to debug, and
• open the document on your mobile device.

Remote console statements will appear in the JSConsole window (you do need to use console.log() rather than console.error() or console.warn()). You can also send code from the JSConsole window to your device. In this case, alert( add(6,3) );.

Fig 16: Sending a command using JSConsole.com

Remote error logging

In the examples above, we’re logging to the console, or launching an alert box. What if you logged your errors to a server-side script instead?

Consider the following code that uses XMLHttpRequest(). In it, we are :

function sendError(){
     var o, xhr, data, msg = {}, argtype = typeof( arguments[0] );

     // if it is an error object, just use it.
     if( argtype === 'object' ){
     	  msg = arguments[0];
     }

     // if it is a string, check whether we have 3 arguments...
     else if( argtype === 'string') {
     // if we have 3 arguments, assume this is an onerror event.
          if( arguments.length == 3 ){
              msg.message    = arguments[0];
              msg.fileName   = arguments[1];
              msg.lineNumber = arguments[2];
          }
        // otherwise, post the first argument
          else {
              msg.message    = arguments[0];
          }
      }

     // include the user agent
     msg.userAgent = navigator.userAgent;

	 // convert to JSON string
	 data = 'error='+JSON.stringify(msg);

     // build the XHR request
     xhr = new XMLHttpRequest();
     xhr.open("POST",'./logger/');
     xhr.setRequestHeader("Content-type", "application/x-www- »
     form-urlencoded");
     xhr.send( data );

     // hide error message from user in supporting browsers
     return true;
}

Here we’re posting our error messages to a script that logs them in a flat file using PHP:

?php

// decode the JSON object.
$error = json_decode( $_POST['error'], true );
$file = fopen('log.txt','a');
fwrite($file, print_r( $error, true) );
fclose($file);

?

Now the disclaimer: please for the love of tequila, don’t let this script write to a world-readable directory. The potential for code injection due to spoofed headers or variables is not worth the risk. Logging scripts like this should only be used during development, and never on production servers.

Conclusion

As the web has evolved, so have our tools. Code injection, error throwing and catching, and remote debugging services are all helping us ship better, less buggy apps.

Things are looking good so far: we’ve got a grid-based layout, one that doesn’t sacrifice complexity for flexibility. I have to admit that the first time I figured out how to build a fluid grid, I was feeling pretty proud of myself.

Fig 3.0: Our flexible grid is finally finished. not a pixel value in sight, and we didn’t have to skimp on the aesthetics.

But then, as often happens with web design, despair set in. Currently, our page is awash in words, and little else. Actually, nothing else: our page is nothing but text. Why is this a problem? Well, text reflows effortlessly within a flexible container—and I don’t know if you’ve noticed, but the Internet seems to have one or two of those “image” things lying around. None of which we’ve incorporated into our fluid grid.

So what happens when we introduce fixed-width images into our flexible design?

Going back, back to markup, markup

To find an answer, let’s do a quick experiment: let’s drop an image directly into our blog module, and see how our layout responds. The first thing we’ll need to do is to clear some space for it in our markup.

Remember our little blockquote, comfortably tucked into our blog article? Well, we’ve got way too much text on this darned page, so let’s replace it with an inset image:

div class="figure"
  p
    img src="robot.jpg" alt="" /
    b class="figcaption"Lo, the robot walks/b
  /p
/div

Nothing fancy: an img element, followed by a brief but descriptive caption wrapped in a b element. I’m actually appropriating the HTML5 figure/figcaption tags as class names in this snippet, which makes for a solidly semantic foundation.

(Sharp-eyed readers will note that I’m using a b element for a non-semantic hook. Now, some designers might use a span element instead. Me, I like the terseness of shorter tags like b or i for non-semantic markup.)

With that HTML finished, let’s drop in some basic CSS:

.figure {
  float: right;
  margin-bottom: 0.5em;
  margin-left: 2.53164557%;  /* 12px / 474px */
  width: 48.7341772%;  /* 231px / 474px */
}

Fig 3.1: An appropriately botty robot pic, courtesy of Jeremy Noble.

We’re creating a nice inset effect for our figure. It’ll be floated to the right, and will span roughly half the width of our article, or four columns of our flexible grid. Markup: check; style: check. Of course, all this HTML and CSS is for naught if there isn’t an actual image available.

Now, because I love you (and robots) dearly, not just any image will do. And after scouring the web for whole minutes, I found a fantastically imposing robo-portrait (fig 3.1). The beautiful thing about this image (aside from the robot, of course) is that it’s huge. I’ve cropped it slightly, but I haven’t scaled it down at all, leaving it at its native resolution of 655×655. This image is much larger than we know its flexible container will be, making it a perfect case to test how robust our flexible layout is.

So let’s drop our oversized image onto the server, reload the page, and—oh. Well. That’s pretty much the worst thing on the internet.

Fig 3.2: Our huge image is huge. Our broken layout is broken.

Actually, the result isn’t that surprising. Our layout isn’t broken per se—our flexible container is working just fine, and the proportions of our grid’s columns remain intact. But because our image is much wider than its containing .figure, the excess content simply overflows its container, and is visible to the user. There simply aren’t any constraints applied to our image that could make it aware of its flexible environment.

Fluid images

But what if we could introduce such a constraint? What if we could write a rule that prevents images from exceeding the width of their container?

Well, here’s the good news: that’s very easy to do:

img {
  max-width: 100%;
}

First discovered by designer Richard Rutter, this one rule immediately provides an incredibly handy constraint for every image in our document. Now, our img element will render at whatever size it wants, as long as it’s narrower than its containing element. But if it happens to be wider than its container, then the max-width: 100% directive forces the image’s width to match the width of its container. And as you can see, our image has snapped into place.

Fig 3.3: Just by including max-width: 100%, we’ve prevented our image from escaping its flexible container. On a related note, I love max-width: 100%.

What’s more, modern browsers have evolved to the point where they resize the images proportionally: as our flexible container resizes itself, shrinking or enlarging our image, the image’s aspect ratio remains intact.

Fig 3.4: Regardless of how wide or small its flexible container becomes, the image resizes proportionally. Magic? Who can say.

I hope you’re not tired of all this good news because as it happens, the max-width: 100% rule can also apply to most fixed-width elements, like video and other rich media. In fact, we can beef up our selector to cover other media-ready elements, like so:

img,
embed,
object,
video {
  max-width: 100%;
}

Whether it’s a cute little Flash video, some other embedded media, or a humble img, browsers do a fair job of resizing the content proportionally in a flexible layout. All thanks to our lightweight max-width constraint.

Fig 3.5: Other media play nicely with max-width: 100%, becoming flexible themselves. Did I mention I love max-width: 100%?

So we’ve cracked the problem of flexible images and media—right? One CSS rule and we’re done?

Because this job is never easy

Time to let the healing begin: we need to work through the pain, the tears, the rending of garments, and talk about a few browser-specific issues around flexible images.

max-width in Internet Explorer

The cold, hard truth is that Internet Explorer 6 and below don’t support the max-width property. IE7 version and above? Oh, it is positively brimming with support for max-width. But if you’re stuck supporting the (cough) venerable IE6 or lower, our approach needs refinement.

Now, there are several documented ways to get max-width support working in IE6. Most are JavaScript-driven, usually relying on Microsoft’s proprietary expression filter to dynamically evaluate the width of an element, and to manually resize it if it exceeds a certain threshold. For an example of these decidedly non-standard workarounds, I’d recommend Svend Tofte’s classic blog entry on the subject.

Me? I tend to favor a more lo-fi, CSS-driven approach. Namely, all modern browsers get our max-width constraint:

img,
embed,
object,
video {
  max-width: 100%;
}

But in a separate IE6-specific stylesheet, I’ll include the following:

img,
embed,
object,
video {
 width: 100%;
}

See the difference? IE6 and lower get width: 100%, rather than the max-width: 100% rule.

A word of warning: tread carefully here, for these are drastically different rules. Whereas max-width: 100% instructs our images to never exceed the width of their containers, width: 100% forces our images to always match the width of their containing elements.

Most of the time, this approach will work just fine. For example, it’s safe to assume that our oversized robot.jpg image will always be larger than its containing element, so the width: 100% rule works beautifully.

But for smaller images like thumbnails, or most embedded movies, it might not be appropriate to blindly up-scale them with CSS. If that’s the case, then a bit more specificity might be warranted for IE:

img.full,
object.full,
.main img,
.main object {
  width: 100%;
}

If you don’t want the width: 100% rule to apply to every piece of fixed-width media in your page, we can simply write a list of selectors that target certain kinds of images or video (img.full), or certain areas of your document where you know you’ll be dealing with oversized media (.main img, .main object). Think of this like a whitelist: if images or other media appear on this list, then they’ll be flexible; otherwise, they’ll be fixed in their stodgy old pixel-y ways.

So if you’re still supporting legacy versions of Internet Explorer, a carefully applied width: 100% rule can get those flexible images working beautifully. But with that bug sorted, we’ve still got one to go.

And boy, it’s a doozy.

In which it becomes clear that Windows hates us

Fig 3.6: Seen here in IE6, our robot image has developed some unsightly artifacts. Guess Windows doesn’t much care for our flexible images.

If you look at our blog module with certain Windows-based browsers, our robot.jpg has gone from looking imposing to looking, well, broken). But this isn’t a browser-specific issue as much as a platform-specific one: Windows doesn’t scale images that well. In fact, when they’re resized via CSS, images quickly develop artifacts on Windows, dramatically impacting their quality. And not in a good way.

For a quick test case, I’ve tossed a text-heavy graphic into a flexible container, and then resized our image with the max-width: 100% fix, while IE6 and below receive the width: 100% workaround. Now, you’d never actually put this amount of text in an image. But it perfectly illustrates just how badly things can get in IE7 or lower. As you can see, the image looks—if you’ll pardon the technical term—downright nasty.

But before you give up on the promise of scaleable, flexible images, it’s worth noting that this bug doesn’t affect every Windows-based browser. In fact, only Internet Explorer 7 and lower are affected, as is Firefox 2 and lower on Windows. More modern browsers like Safari, Firefox 3+, and IE8+ don’t exhibit a single problem with flexible images. What’s more, the bug seems to have been fixed in Windows 7, so that’s more good news.

Fig 3.7: In certain Windows-based browsers, the image quickly develops too many artifacts to be readable.

So with the scope of the problem defined, surely there’s a patch we can apply? Thankfully, there is—with the exception of Firefox 2.

Now, this grizzled old browser was released in 2006, so I think it’s safe to assume it isn’t exactly clogging up your site’s traffic logs. At any rate, a patch for Firefox 2 would require some fairly involved browser-sniffing to target specific versions on a specific platform—and browser-sniffing is unreliable at best. But even if we did want to perform that kind of detection, these older versions of Firefox don’t have a switch that could fix our busted-looking images.

Internet Explorer, however, does have such a toggle. (Pardon me whilst I swallow my pride for this next section title.)

Hail AlphaImageLoader, the conquering hero

Ever tried to get transparent PNGs working in IE6 and below? Chances are good you’ve encountered AlphaImageLoader, one of Microsoft’s proprietary CSS filters. There have since been more robust patches created for IE’s lack of support for the PNG alpha channel (Drew Diller’s DD_belatedPNG library is a current favorite of mine), but historically, if you had a PNG attached to an element’s background, you could drop the following rule into an IE-specific stylesheet: (Line wraps marked » —Ed.)

.logo {
  background: none;
  filter: progid:DXImageTransform.Microsoft.AlphaImageLoader»
  (src="/path/to/logo.png", sizingMethod="scale");
}

This AlphaImageLoader patch does a few things. First, it removes the background image from the element, then inserts it into an AlphaImageLoader object that sits “between” the proper background layer and the element’s content. But the sizingMethod property is the clever bit, dictating whether the AlphaImageLoader object should crop any parts of the image that overflow its container, treat it like a regular image, or scale it to fit it within its containing element.

I can hear you stifling your yawns by now: after all, what does an IE-specific PNG fix have to do with our broken image rendering?

Quite a bit, as it turns out. At one point I discovered that applying AlphaImageLoader to an image dramatically improves its rendering quality in IE, bringing it up to par with, well, every other browser on the planet. Furthermore, by setting the sizingMethod property to scale, we can use our AlphaImageLoader object to create the illusion of a flexible image.

So I whipped up some JavaScript to automate that process. Simply download the script and include it on any page with flexible images; it will scour your document to create a series of flexible, high-quality AlphaImageLoader objects.

And with that fix applied, the difference in our rendered images is noticeable: in our example we’ve gone from an impossibly distorted image to an immaculately rendered one. And it works wonderfully in a flexible context.

Fig 3.8: Our image is now perfectly legible, and resizing wonderfully. A dab of AlphaImageLoader’ll do ya.

(It’s worth mentioning that many of Microsoft’s proprietary filters, and AlphaImageLoader in particular, have some performance overhead associated with them—Stoyan Stefanov covers the pitfalls in more detail on the YUI blog. What does this mean for you? Just be sure to test the fix thoroughly on your site, gauge its effect on your users, and evaluate whether or not the improved rendering is worth the performance tradeoff.)

With the max-width: 100% fix in place (and aided by our width: 100% and AlphaImageLoader patches), our inset image is resizing beautifully across our target browsers. No matter the size of the browser window, our image scales harmoniously along with the proportions of our flexible grid.

But what about images that aren’t actually in our markup?

Flexibly tiled background images

Let’s say our dearly esteemed designer sends over a revised mockup of our blog module. Notice anything different about it?

Fig 3.9: Our blog’s sidebar is now sporting a background graphic. Hot.

Up until now, our blog’s content has been sitting on a rather unassuming near-white background. But now the design has been modified slightly, adding a two-toned background to the blog entry to provide more contrast between the left- and right-hand columns. What’s more, there’s actually a subtle level of noise added to the background, adding an extra level of texture to our design:

Fig 3.10: A detailed look at our new background treatment.

So: how do we actually add this new background image to our template?

Back in 2004, Dan Cederholm wrote a brilliant article showing how a vertically repeating background graphic could be used to create a “faux column” effect. The technique’s genius is in its simplicity: by tiling a colored background graphic vertically behind our content, we can create the illusion of equal height columns.

In Dan’s original technique, the background graphic was simply centered at the top of the content area and then tiled vertically, like so:

.blog {
  background: #F8F5F2 url("blog-bg.png") repeat-y 50% 0;
}

And that technique works beautifully. But Dan’s technique assumes that your design is a fixed width, creating a graphic that matches the width of your design. Then how, pray, are we supposed to work in a background image that tiles over two flexible columns?

Thanks to some early research by designer Doug Bowman, we can still apply the faux column technique. It just requires a little bit of extra planning, as well as a dash of your favorite formula, target ÷ context = result.

First, we’ll begin by taking a look at our mockup, to find the transition point in our background graphic, the exact pixel at which our white column transitions into the gray. And from the look of things, that switch happens at the 568 pixel mark.

Fig 3.11: Our white column switches over to gray at the 568px mark. That’s our transition point.

Armed with that information, we can now adapt the “faux columns” approach to our fluid grid. First, we’ll convert that transition point into a percentage-based value relative to our blog module’s width. And to do so, our target ÷ context = result formula comes into play yet again. We have our target value of 568px, and the width of the design—our context—is 900px. And if we plug those two values into our stalwart formula:

568 ÷ 900 = 0.631111111111111

That’s right: another impossibly long number, which converts to a percentage of 63.1111111111111%.

Keep that percentage in the back of your mind for a moment. Now, let’s open up your favorite image editor, and create a foolishly wide document—say, one that’s 3000 pixels across. And since we’re going to tile this image vertically, its height is only 160px tall.

Fig 3.12: A monstrously large canvas that we’ll (shortly) turn into our background graphic.

In a moment, we’re going to turn this blank document into our background graphic. But why is it so large? Well, this image needs to be larger than we can reasonably assume the browser window will ever be. And unless you’re reading this from the 25th century on your wall-sized display made of, I don’t know, holograms or whatever, I’m assuming your monitor’s not quite that wide.

To create the columns themselves, we’ll need to apply the transition point percentage (63.1111111111111%) to our new, wider canvas. So if we’re working with a graphic that’s 3000px across, we simply need to multiply that width by the percentage, like so:

3000 x 0.631111111111111 = 1893.333333333333

We’re left with 1893.333333333333 as our result. And since Photoshop doesn’t deal in anything less than whole pixels, let’s round that down to 1893 pixels. Armed with that number, we’ll recreate our textures in our blank image, switching from white to gray at the 1893rd pixel.

Fig 3.13: We’ve applied that percentage to our oh-so-wide background graphic, creating our tile-ready columns.

How does that help us? Well, what we’ve just done is to proportionally scale our transition point up to this new, wider canvas. So we can take that new pixel value, and use it to create our columns: the white column will be 1893px wide, with the gray column filling up the remainder.

So now there’s only one thing left to do: drop our newly minted graphic into our stylesheet.

.blog {
  background: #F8F5F2 url("blog-bg.png") repeat-y 63.1111111111111% 0;
  /* 568px / 900px */
}

As in Dan’s original technique, we’re still positioning the graphic at the very top of our blog, and then repeating it vertically down the width of the module (repeat-y). But the ­background-position value reuses our transition point percentage (63.1111111111111% 0), keeping the columns firmly in place as our design resizes itself.

And with that, we’ve got faux columns working beautifully in a fluid layout. All thanks to Dan Cederholm’s original approach, augmented with a little proportional thinking.

fig 3.14: Our flexibly faux columns.

Fully flexible background images?

Of course, our flexible faux column isn’t really flexible: we’re simply using percentages to position a background image in such a way that the columns appear to resize with their container. The image’s dimensions haven’t changed at all.

But what about a background image that actually does need to resize with the layout? Perhaps you’ve placed a logo on an h1 element’s background, or used sprites to create rollovers for your site’s navigation. Can we resize images that need to live in the background?

Well, sort of. There is a CSS3 property called background-size, which would allow us to create truly flexible background images, but—you guessed it—browser support is still pretty immature.

In the interim, there are some rather ingenious JavaScript-based solutions out there: for example, Scott Robbin’s jQuery Backstretch plugin simulates resizable background images on the body element. And as you’ll see in the next chapter, CSS3 media queries could also be used to apply different background images tailored to different resolution ranges. So while background-size might not be available yet, the sky is, as the kids say, the limit.