Keep it Simple
By Peter-Paul Koch
The first site I made as a professional web developer used 17 frames.
My first professional assignment was coding the World Press Photo site. In those days sites had to be compatible with Netscape and Explorer 3 and 4. That wasn’t a problem – that’s what I’d been hired for.
The site needed three content areas inside a static design of navigation and decoration. Nowadays we might use iframes for the content areas, but back then only one of the four popular browsers supported them. So I coded the site in frames and found that… I needed more than expected.
The cause was Netscape. It was impossible to be certain that in Netscape a frame had the exact width and height you defined, so I devised a workaround to make sure all frames fit snugly, whatever their actual width and height might be. I ended up with 17 frames.
Nothing wrong with that, I thought, and proceeded to add boatloads of JavaScripts to make sure the frames cooperated properly (and without which, incidentally, the site wouldn’t work).
When the site went online, I felt proud. I’d proven to myself and to the world that I was a web developer.
Complexity
One year later all of the photos on the site had to be republished. I’d gained a lot of experience meanwhile, was promoted to head of Client Side Programming at my company and consequently made responsible for the cleanliness of our code.
I looked at the site anew and had a vague feeling of unease. Mightn’t it contain slightly too many frames and scripts? Unfortunately the budget didn’t call for a redesign, merely for new content. I nonetheless spent an entire day in study and judiciously merged two frames, making for a total of 16. I couldn’t remove more frames without destroying the cross-browser compatibility of the design.
It took me another six months to realize that the whole thing was too complex. Since I was paid to worry about such matters, I thought long and hard. What had gone wrong? Could we avoid making the same mistakes again?
At first I blamed the design. In a literal sense this was correct: if the design hadn’t called for three content frames and one very problematical line, the coding could have been much cleaner. But this only meant shifting the blame from myself to the designer, so it wasn’t a real answer. Why had the design been so complicated? Why didn’t we keep it simple?
The answer I found is that for most people <code>simple = dull</code>. A site made by a creative web development company must never be dull, ergo it should be complicated.
KISS
People were already protesting against this point of view. “Keep It Simple, Stupid!”, they said. Of course other people disagreed. One mail succinctly stated: “KISS leads to LOVE (Leave Out Virtually Everything)”.
This reaction accurately mirrored my fears. If we’d leave out the newest technologies, the well-designed Flash movie, the nifty DHTML script, what kind of site would remain? Just text and the tiniest bit of HTML? Booooring.
But then I discovered two things.
First of all sites should be exciting only when their purpose is to be exciting. An entertainment site should be exciting, sure. But what about an e-commerce site? A corporate site? A government site should be a bit dull, I’d think, to underline the importance of the information it provides.
Secondly, the whole idea of exciting vs. simple is a beginner’s mistake, and in 1999 I was very much a beginner. Clients make this mistake all the time because they are beginners by definition. They (and many developers) are misled by the magic words “interactive multimedia”. A site should be interactive! It should be multimedial! (whatever that may mean) The site should move, dance, prance, and who cares whether the subject calls for it? We’re creative, right?
Simplicity
The old World Press Photo site was a typical example of this school of thought. It didn’t contain any moving stuff, but to make up for that we used a tiny Java applet to mimic a dropdown box navigation – why keep it dull if we can make it complex? I replaced it with JavaScript during the review a year later. It can be argued that the site is still too complicated.
The good news is that in 2001 I got the chance to completely recreate the site, this time on better principles. We stopped using frames, and we changed the complex navigation scripts to slightly less complex DHTML scripts that enhanced the site but didn’t contain vital functions. The result is a site that fulfills its purpose: showing the World Press Photos of the Year.
This made me rethink the whole complex-but-exciting approach and at the moment I’m on the move toward simplicity. I keep the purpose of the site firmly in mind and don’t add unnecessary stuff just because it’s possible. The newest browsers help a lot: CSS goes a long way towards creating appealing but simple sites.
In the next months, I’ll share my thoughts on simplicity in this column on Digital Web Magazine. Why do people make complex sites? When does a site become too complex? How should you judge whether a site needs to be complex? What techniques should you use to avoid complexity?
To make it absolutely clear, at the moment I write this I don’t have the faintest idea what the answers will be. Let’s hope they’ll be simple…