Joel Spolsky recently pseudo-attacked simplicity. I say pseudo because he makes great points and is only really down on being totalitarian about simplification.

Expressing simplicity is not always simple. What some call the simplicity cult have attempted to boil down good strategies for making things easy. The problem is that this can lead to generalizations that are misunderstood.

37Signals is a company with simple, lean products. They preach “less software,” but that doesn’t mean they never add features. As I’ve been noting in my Laws of Simplicity series, it’s a balancing act. There is no perfect approach.

Spolsky continues:

What works for bootstrapping, I believe, will not work as a good long term strategy, because there’s very little to prevent the next two-person startup from cloning your simple app, and because eventually you can’t fight human nature: “The people want the features,” says Norman. Just because handheld video was perfect for Blair Witch, doesn’t mean every Hollywood blockbuster will use it.

Again, I think this is just a misinterpretation of what it means to be simple. It also assumes that it’s easy to do something simply. A lot of people try and fail to copy the success of simple products. It’s hard to copy the balancing act. Having already achieved the difficult task is an advantage.

This is part of a series looking at John Maeda’s ten Laws of Simplicity.

“Simplicity and complexity need each other.”

If everything was simple, nothing would be simple. We appreciate simplicity only because we can compare it to complexity. The iPod and Google, ever the popular examples of simplicity, would not have succeeded if there weren’t some pretty bad (read: complex) competition.

Like many opposites, simple and complex aren’t that different. Many times, the simple thing just disguises very complex things going on behind the scenes. Millions of non-programmers type words into search engines every day. These same people have no idea about what it takes to create an index that is able to return results in a fraction of a second.

In the first law, we learned about thoughtful reduction. In that process, we consider what is most important. Then we highlight those things. Similarly, organizing is about deciding what groups are important and what they should contain. If everything is important, nothing is. The law of differences acknowledges that in order to achieve simplicity, we must have complexity.

This is part of a series looking at John Maeda’s ten Laws of Simplicity.

“Knowledge makes everything simpler.”

One reason I really like the Laws of Simplicity is because each one is important to the whole package. When I first read this law, I thought it was a cop-out. As a Web developer, I accept at least a partial truth to the claim that people don’t read directions. At a glance, this law says, “just tell them how it is and suddenly it’s easier because they know now.”

Learning has to happen somehow. It’s not the responsibility of this law to say how that happens. Hopefully the other laws make the knowledge transfer implicit.

It’s also worth acknowledging how much our users already know. Most sites don’t need to explain how to click links or fill out forms. Instead, the basic navigation style and layout of sites are similar because that’s what the users expect.

To me, the law of knowledge says to consider what your users already know. Once you have a group on their current knowledge, you can use the other laws to help them learn what they don’t know.

I think of the small technical lessons I have given my father. Perhaps the biggest was copying and pasting. The next biggest might have been the shortcuts to copy and paste. Those small bits of knowledge create a much simpler experience.

Two years ago, The Wheeze encouraged me to read Web sites in a feed reader. Taking the time to learn that process greatly changed the way I consume information. Now I probably track five times the sites in half the time.

As these examples show, this fourth law of learning works in tandem with the third law, time. Once you know something, you save time, which directly equates to simplicity.

This is part of a series looking at John Maeda’s ten Laws of Simplicity.

“Savings in time feels like simplicity.”

Web design gurus have preached this law since the mid-90s. Watch your file sizes! Beware the total site “weight!” they warned. These are still excellent strategies for savings time, though broadband penetration means we don’t have to be quite as militant.

Ajax has opened up a whole new time-saving tool bag. Using Javascript, developers can limit the apparent roundtrips to the server that require an entire page to reload when only a small portion has changed.

In reality there is still a roundtrip going on, but it happens in the background. And it doesn’t have to return the header graphic, navigation, and other items the user already is seeing. Instead, it returns the smallest amount of information needed, saving time.

Better yet, it feels like we’re saving even more time. With a traditional roundtrip, the screen goes blank for just an instant, but it feels longer. What simplicity really gets down to is perception. If it seems slow, then it can’t be simple.

Taking perception a step further, Ajax developers have added small animations to display during the short wait:

Here’s a whole gallery of them.

Of course, progress bars aren’t new. They existed on Expedia and their ilk well before Ajax was around. Travel sites didn’t invent them, either, as they’ve been a staple of slow desktop operations for years. Heck, maybe old school programmers got the idea from “please take a number” signs at the deli.

In all these cases, we have a glimpse of action. When the end is in sight, the wait seems shorter. The shorter, the simpler.

(What I’ve left out here, for simplicity’s sake, is a whole other side of time savings. Fill in the gaps yourself by considering how online banking has saved us all so much time.)

This is part of a series looking at John Maeda’s ten Laws of Simplicity.

“Organization makes a system of many appear fewer.”

This law comes down to basic cataloging. Find like elements and put them together. Maeda uses the ol’ screenwriter trick of placing one thought/item on an index card. Then the cards can be moved around until you find the right groupings.

At BestPlaces we’re continually honing in on the best way to show all the data we have on every city and zip code in the US. The most important step was organizing the data into categories. To show air quality, average precipitation, and unemployment rate right next to each other would be confusing. Organizing them into health, climate, and economy sections goes a long way to simplifying what we’re showing.

USDA’s Haynet was able to boil their entire site down to two links: have hay and need hay.

I’ve harped on this before as being too simple. My main beef with it is that it’s not a template that translates to other sites very well. When architects have emulated the Haynet approach, they lost something in their simplicity.

A later law does a good job of explaining my problem with Have Hay / Need Hay. As far as organization goes, one can’t get much simpler.

As I mentioned yesterday, Maeda explains many of his laws with continuums between conflicting factors. It seems to me that as we nudge one way with one law, we cause a reaction that moves other laws. It’s a delicate balance that should be embraced, because with the process comes simplicity. Organizing is a big part of that process.