Why recipe sites shouldn’t be in Flash

It is, officially, canning and pickling season. Every year for the last four, I’ve spent most weekends in August canning a variety of pickles, salsas and other nummies to preserve the massive amount of produce that comes out of New England in late summer. One of my favorite recipes is from Hubert Keller’s terrific show on PBS, and it’s a sweet pickle with a bunch of different summer veggies. I discovered this one last year and made about a half dozen pints with the last of my farm share. I have yet to bring it somewhere where it doesn’t disappear five minutes after it’s opened.

Recently, a friend of mine had an abundance of zucchini (like you do) and wondered what to do with it – so I wanted to send her the recipe for Hubert’s excellent mixed pickle. I always make it with zucchini, as well as small carrots, radishes, white turnips, pearl onions and cauliflower. Should be easy enough, right?

Unfortunately, Hubert Keller’s website is done entirely in Flash.

There are several reasons why this is a phenomenally bad idea. For all the benefits that Flash can bring when well executed, on its best day Flash brings with it three important and tragic flaws:

  1. It forces all of your content into a specific height on the screen, which forces you to use scrollable boxes for any content that is longer than your screen height;
  2. Scrollable boxes in Flash don’t behave the way that we’re used to online. Rather than being able to use our fingers on the trackpad (for Mac) or the little roller thing on our mouse, you have to actually click on the scrollbar and manually drag it down – a process that is almost always unreliable.
  3. The entire site exists as a single movie – which means (and this is the most important issue) you can’t bookmark a single page for later reference.

In practical terms, this meant that, in order to get the recipe for my friend, I had to send her to his site, and tell her to navigate to the PBS show, then Recipes, then scroll down to the episode on Charcuterie, so that she could then download a PDF of the actual recipe.
And, I had to apologize to her for the fact that music would be playing the entire time she was doing this. And the fact that, because it was Flash, there was no way to actually just search for the recipe.

This experience brings me back to a fundamental point – and one that I rant about often. The first questions that should be answered before starting a web project should always be these three:

  1. Who are the people coming to your site?
  2. What are they coming there for?
  3. How are they used to finding that information?

If you don’t answer those three questions before you even touch things like what it should look like or what types of functionality you want, this is the kind of thing that happens. And you don’t want that to happen.

By the way, should you actually want the recipe, I’ve shared my adaptation on the recipe blog.

If your users need an instruction manual, you’re doing it wrong

On last night’s Top Chef (come on, you didn’t think that I wouldn’t be obsessed with that show, did you?), in one of those random throwaway segments that they throw in just before or after the commercials, two of the chefs got into an argument. The argument was about whether customers should need instruction on how to eat a chef’s food.

One chef was loudly insisting that customers need to be told how to eat their food, as if humans hadn’t perfected the art of ingesting calories over the last several thousand years, or as if their food was so bold, so innovative, so completely unique in the way that the flavors were integrated, that there was no way a layperson could possibly understand the proper way to consume it.

Likely, you can guess by now that I was pretty solidly in the other chef’s camp. Food can be innovative, it can be full of surprises, but it should always be *food* – that’s the point of it. Food is not your “artistic vision,” it’s not some intricate puzzle to solve, but a fundamental human experience that you’re creating for another human, and that human should be allowed to experience it without needing a tutorial. To behave otherwise is an insult to the customer.

The reason I mention this is because lately, in my business development research, I’ve been coming across website after website that requires an instruction manual to navigate. Literally, one website I came across *did* have an instruction manual – and the site still didn’t work.

This is the curse of “artistic vision” parading as design. In their enthusiasm to create something visually stunning and innovative, some designers simply forget that they are creating an experience for another human – and that the human they’re designing for has a specific need which has absolutely nothing to do with “exploring the site.”

I’d like to be able to blame this on Flash. Truthfully, many of the worst offenders I’ve seen have been all-Flash sites, or worse, Flex sites (shudder). But it’s not just Flash, it’s also CSS3 and JQuery. Digital experiments are fine; terrific, actually. But when you start doing things like recreating the Fail Whale in markup, using roughly 372 lines of code (most of which were empty <div> tags) and 1273 lines of CSS code in the process, you start creating the same situation that web standards were meant to solve: you’re putting form ahead of function, and tying content to presentation.

Mind you, the CSS3 Fail Whale is an extreme example. But imagine a day when more sites will behave like this – where a client’s logo is no longer an image, but a series of empty divs positioned and rotated in CSS, all of which is placed in markup before the content. What happens on mobile browsers, when they try to download all of that code before they show the page? What happens when a blind person visits the site and the screen reader tries to read all of those empty divs (which can happen in some of the stricter modes)?

Are in-post links and pagination causing a lack of concentration?

As more and more information is being proliferated and consumed over the Web, it seems that our attention spans have taken a hit. I recently came across some interesting musings by Newfangled’s Chris Butler on the subject:

In a recent WIRED article summarizing some points from his book, The Shallows, Nicholas Carr argues that hyperlinks may actually disrupt concentration and weaken comprehension—effectively hindering our ability to engage in “deep reading.” When I read this last week, it immediately struck me as true—I know that the more links I encounter in an article, the more likely I am to feel overwhelmed with options that I am inclined to follow up upon.

While I won’t paraphrase my entire comment on this blog (if you scroll down, mine is the first comment), one of the things that I can say from my own experience (and those of several posts I’ve read recently about time management and maintaining productivity) is that yes, links are distracting. Very distracting.

To people like us, who love to absorb information and learn new things, a couple of reference links within a short blog post can easily turn into a half hour of reading a bunch of different stuff on a topic that has no relation to what you’re immediately doing. In my own life, I’ve noticed that this tendency causes me to work late into some evenings just to finish up the work that I had to get done that day.

Here’s the thing: information is valuable. It is. It’s important to learn new things and stay on top of what you’re doing. But the time we spend clicking on all of these links and reading this interesting stuff? It’s not billable. And as the creators of this content, it’s important for us to respect this fact and enable our readers to absorb the information we have for them, not send them off in a million different directions because someone on Twitter thought that our post was cool.

I don’t know that there’s an immediate solution to this. Chris mentions a couple of good suggestions, and I have a few thoughts that I’ll be implementing in the zen kitchen‘s website sometime soonish, but at the very least, it’s something to think about.

Web Design: getting down to what’s really important

Over the last few years, I’ve woken up almost every day with insane neck pain. I’ve tried a bunch of different solutions for this: yoga, chiropractic, massage, and so many new pillows (some quite expensive) that my fiancé Nick frequently jokes about my “pillow quiver” – the two Tempurpedic pillows that I switch through every night depending on what position I’m in.

For those who don’t remember the Sobikawa pillow, it is a Japanese pillow that is filled with buckwheat husks. The idea is similar to memory foam, but with one key exception: the husks actually conform to your shape and stay there, making sure that your neck is completely in alignment all night. I had one years ago that I’d bought for $20 at a Walgreens, and I always regretted getting rid of it. But apparently, you can still get them pretty cheaply at target.com.

Cost: around $50, including shipping and tax. Result? The best week of sleep I’ve had in years, and while my neck still has some tightness, the pain that I used to wake up with has already started to go away. The super-expensive Tempurpedic pillows that I’ve been sleeping on for the last couple of years are now sitting in a closet. This simple pillow, filled with organic stuff that would have been thrown away anyway, was what I needed all along.

This experience exemplifies an important component of good design. Sometimes when we decide that we need a new marketing campaign, website, etc. it’s very easy to get caught up in the technology, or in the physical components that we’re looking to create. But often, when this happens, we lose sight of the most important goal of truly effective design: solving a specific business problem.

I see this most frequently in website RFPs. The RFP will list a wide array of technical features that the client wants on the site, but it won’t mention anything about the reason those features are important to them, or what the site itself is meant to accomplish. When we speak with the client contact prior to crafting the proposal (we don’t answer RFPs without having at least one conversation with the client contact to confirm goals and scope), you often find that the client doesn’t actually have a specific reason for that feature; they included it because they thought it was interesting, or because their competitors are using something similar.

For any design project to actually do the work you want it to, it has to start by identifying the real problem that you’re trying to solve. It’s extremely rare that your problem is not having enough technical whiz-bangery or Flash on your site. Much more often, the problem comes down to this:

your website doesn’t communicate your brand in a way that is meaningful and authentic to the people you want to connect with.

That’s it. That’s all. Really.

This is why things like user experience, audience testing and discovery are such a large part of good website design. It’s also why, if you haven’t taken the time to properly think through what you genuinely provide for your customers and craft a brand that properly reflects that, it’s useless to worry about creating a website.

Unless you can approach your project with this level of awareness around who your customers really are, and what they really want/need to hear from you, interactivity and fancy widgets become nothing more than meaningless decoration. Extremely expensive meaningless decoration. Fancy pillows gathering dust in a closet.

Does this mean that you shouldn’t add interactivity or technical features to your site? Not at all. 

But every feature on your site, just like every image, shape, type or color choice in a printed piece, must be there for a specific reason.

It must serve a specific need that your customers have. And, most importantly, it must be presented in a way that inspires trust, confidence and an interest in exploring further.

This is the benefit of iterative design, and of open source systems such as Drupal that allow you to evolve your site as your customers’ needs evolve. These approaches allow you to do something very important: start simple. Figure out the basics. Who are your customers? What do they get from you that they can’t get elsewhere? What is their reason for being at your site? What do they need to accomplish there?

For most businesses, there are certain common things that users need. They need a phone number where they can contact someone if they have a question, or if something goes horribly wrong. They need to get a quick overview of what you do, and how it might benefit them. If you’re a retailer, they need to know that they can find what they want at your site easily, they need to trust that their credit card information is safe in your hands, and they need to feel that they’re buying something from a business that is credible. For a food company, they need to know where they can buy your product in their local store, or how to get it for their store, and it would be great if they could buy it online. More importantly, they need to be able to imagine what the product actually tastes like, and that imagining should make them want to try it enough to add it to their cart.

In both of these cases, the last need is the most important. And unfortunately, it’s the one that’s most often overlooked in favor of the technology required to meet the first few needs.