Digital Web Magazine

The web professional's online magazine of choice.

Process Design

Got something to say?

Share your comments on this topic with other web professionals

In: Columns > DigiSect

By Stephen Van Doren

Published on May 14, 2001

The Trials and Tribulations

Every designer/developer team goes through a process when designing and implementing a web site. That process is the topic of this column—not because I don't think you know how this process works, however. In fact, I will assume that you know a certain amount of web technology and "why things are the way they are."

Additionally, if you are one of the other four people working on this project with me, don't come beating on my office door after reading this. I only speak the truth, and you know it.

I guess that was a disclaimer. Weird. Why did I need that?

This is all intended to teach about one particular phrase that simply isn't heard enough here in the Web World: "Process Design." When we design a site, we have to traverse a defined process, or it's simply not going to work; you're going to be stuck with confused visitors, and your client isn't going to make enough money or prestige to pay you the money or prestige you've earned. Is this important? Yes. Don't believe me? You can't buy your cheese and crackers with good intentions. Trust me.

If No One Uses It, It's Not Useful
Building a System that Works and is Appreciated

If that's not pointing out the obvious, I'm not sure what is. Such a statement could easily be called the mantra of the Web. It's either that or "Grab it While You Can," but that latter motto seems a bit too cynical. The Web is for everyone.

The client in question, Culturehaus.com, badly needed a complete overhaul and redesign of their Web Site. When we started the re-design there was little-to-no functionality, and few people were using the system. We didn't like the fact that we put together this initial site (nearly a year ago) and no one was using it. Of course, I wasn't here to do that, or it would've been done correctly. But we won't discuss my ego here.

It was originally designed in ColdFusion with a SQL database. That part of the spec wasn't going to change, no matter how hard I tried. The developers that I was working with were going to stick to their guns there, as they firmly believe that ColdFusion is the way to go in terms of web technology. No argument there, I suppose. If it weren't for the messy code chunks that ColdFusion outputs, I would be more than pleased to work with it.

The client had a relatively high level of control over the people that would be using the system, so we didn't have to design the site with v4 browsers in mind. This impacted how the design was going to be implemented: I didn't need to limit myself to some of the regular conventions of markup. If I could use CSS to drive the bastard, I was certainly going to.

The administrative end of the site required a major overhaul, increasing usability and options for the one person that would be taking care of all that stuff. Since the initial launch of the site, my company had been doing all the updates, and sometimes that took too much time and money away from us.

Oh, did I mention that this client is a non-profit group? So time was of the essence. That's an important part of this narrative.

Fiddle my Features
What's In & What's Out

The first step, of course, was the feature-gathering session. A developer, a DBA and myself sat down with the client to decide what features were in, and what features were out. You'd be amazed at some of the stuff that was written down and then thrown out at a later date for one of a million reasons. One of our initial concerns with the JAD session was that the client would want a lot of work done and we wouldn't be able to peacefully coexist with the loss of money that would be soaked by the company.

Then again, we might've made things a touch more complicated than we really needed to. Yes, we needed a member's area, and one of the issues with the previous site was that non-members couldn't really access much in the way of content. So we beefed that up. And then we just made it nasty-big. Then we cut back a little bit. I'm sure you understand.

We had to settle on a site map for how the system would function. From this we needed to put together how the database would talk to the application, and how the flow of the site would be put together. Ultimately, this was the most important step. Like any business, a proper information architecture map is integral to the success of the system. Otherwise, you get several different people working on one thing with several different ideas in their heads—it gets confusing really quick.

During the feature-gathering session, the client explained how the site fell short of many of the initial purposes. He's a crazy guy, but we like him. We figure he'll be buying us all Scotch later on when he learns just how amazing his new system is going to be.

Fortunately, the client's foremost priority was that the system be as dependent on his people as possible once the launch was successful—meaning that it wouldn't depend on our work.

What a nice guy. He appreciates us. Originally, every new member, every new event, and every new piece of information had to be manually added by us into the database. Bad system. Looking back, I don't even know why the original system was written with a database and CF at all—it could've just as easily been HTML for all the dynamic content it was driving.

Of course, perhaps I would've taken it more personally if I had actually had a hand in the development of the first site. Fortunately, I did not. We already spoke about that.

It also came about that the whole system, since we weren't charging him for the work, needed to be a showcase for our talents. Have you ever heard that from a client? It was like a busnigasm (for a definition, don't consult Webster—consult your imagination). It was that good.

So I left the meeting with clouds in my head and flowers at my feet. I sat down at my machine and banged out some of the best designs I've ever done. Felt great. Did a little, tiny bit of Flash (as it's not supposed to be IN YOUR FACE) and did some interesting things with Illustrator/Photoshop mixes. Felt good. Sat down with my team and picked through, together, what parts we liked and what parts we didn't. We eventually arrived at a complete design, and we were all happy. It turns out that we all loved my initial conceptualization. Armed with the designs, strong site architecture, a knack for CSS and ColdFusion, and the drive to get the project done as quickly as possible, we sat down to code the bastard.

But like any good fairy tale, the fun had to become "interesting" sooner or later. "May you lead an interesting life"—now that is a threat.

Start At The Top
Front Page News!

Of course, I wanted to leap on the implementation of this thing as quickly as possible-and the rest of the team agreed. We wanted to take the eyesore-that-was-CultureHaus off the Net and replace it with this, our new object of beauty. Being the HTML guru that I am (despite claims to the contrary made by someone whose surnames rhymes with jink, nudge-nudge-wink-wink), I hacked out several bits of code to start off the journey. While I was doing that, the DBA and the ColdFusion lead were putting together their portions. CF and HTML have a great deal in common, so this was perfectly natural. I wanted to save as much time as possible on this.

The front page included a table with nine square boxes, each measuring 28 pixels on a side. Each one was a slightly different color. They were extremely decorative, and extremely slick because four of them were to be Flash animations. Flash, you say? Yes. I can't explain it here. By the time this article is published, hopefully the database of this system will have been populated and it'll be public. Otherwise, just wait patiently. You'll understand once you see it. It is slick.

Since my client had control over the users that were coming in, I wasn't initially worried at all about any table translation errors. I figured that the stray NN6 user was going to be able to see the site just fine. So I tested. It broke.

"...Take off every zig for great justice."

It wasn't too bad, really. I just fixed the widths, put clear GIF files in the cells, and called it a day. That works fine in NN6. But NN4 eats it alive. Why does that happen? Though the cry for help from the web development community has been loud, and some browser-developers have actually taken some aims to fix it all, I must still cry out in the darkness. I must still ask, "Why, Mister Netscape, must you eat this? There's no CSS involved with the placement! There's no CSS involved with the display of these boxes at all! Why must you render this improperly? I've told you their widths. I've told you their heights. Why must you remove all my work from your screens?" I've always respect Netscape as a company, and I've feared for Microsoft over the years—there was a time when Navigator was on far more machines than Explorer. Those were good days. I remember designing pages that were meant for NN and would break in IE. What happened?

The answer is simple: Explorer got smart all of the sudden.

Translation: Explorer started shipping in every new machine.

It's lamentable, true, but I've embraced the idea that backwards-compatibility is simply wasted work, for the most part. A wise sage by the name of Zeldman once mentioned that pointing out browser problems to the user is like walking through the fourth wall of the stage actors' field. It's just not supposed to be done. And it sucks to do it. But we're doing it. And it's helping.

And I feel ill.

Once the front page was finished, it was time to get the secondary pages implemented into their proper templates.

Stylesheets of the Brave New World
The Poison and Remedy of CSS

With the results of the front-page testing under my belt (within the client's specifications, it works "flawlessly") I set out to develop the CSS that would drive the secondary pages.

One of the things that sat in the back of my mind was wondering about how people in non-standard browsers would feel coming here. I'm not talking about the v4 browsers (they usually just scream and run away, snot trailing from their noses), but rather the Braille browsers, the audio browsers, and the Yuppies browsing from Palm Pilots. What did they want to find here? Were they even going to visit?

So I wanted to make sure it was possible for them to access the content that was so important on this site. I wanted to make sure that the yuppie on the Palm could download the calendar from this site and always carry around with him that he has a dinner party to go to on the 17th. They're not really my people, but I want them to spend time with their people, right? It's about community.

We're developing a community on this site.

So my stylesheet had to take into account that there just might be an issue. So my developers and I sat down and agreed that making the thing run off the CSS would be a good plan.

My CSS was a thing of beauty.

My CSS was 100% compliant with W3C standards.

My CSS was eaten alive by NN6, and we don't know why.

Well, not completely. It savored a few choice morsels from the CSS and actually rendered them properly. So that was mildly okay. What we found was that NN6 has the same sorts of table-rendering issues that it's predecessors had. Namely, if a background is defined in the <table> level element, it was going to be repeated in the <td> level elements. Our first hack around that was to set in the <td> level a background of a clear GIF file. That works just fine, so long as the table background isn't being called from a CSS file. If it is, you're done for, because the clear GIF file defaults the <td> background to the background color of the <body> level definitions...

...But only in Netscape, and we don't know why. It makes me very sad to report this.

Our initial development had different background images going over different threads of action in the Web Site. We still have that. Before, the image was put in the table level. Now it's set at the body level, called through CSS (so that we can position it where we want, and is surreptitiously ignored by v4 browsers, mercifully), and it all looks pretty slick this way.

And we did it all for the love of a background-repeat definition. When used properly, in connection with background-position definitions, we can play with how our background reacts to the size of the window. I remember the 10th century of web development (read: 1999). Remember the NOTILE attribute? I do. I also remember that when used on the same page viewed through the same browser on the same computer three times would give you three different sets of results. Never really worked real well. But now, we can use our CSS do something even better that is more powerful... and we don't even get flayed alive anymore. I love the future.

Resolution, Implementation, and Final Thoughts
How the Designer Found Home

We had all of our ducks in a row, and we were feeling just great. There was nowhere to go but up and up, and that's what we saw. We saw great things for our site, and we just knew it was going to be well-received. I know you're all dying to know about this, so I'll just fill you in: The client loves the site. He's extremely pleased, and this designer, for one, is, for once, pleased that the client is happy. We weren't going to make any money off of this project—so it's actually a little like what we do when we post personal thoughts on the web. We're doing it for the purest of reasons, and we're getting the acclaim that we all deserve.

There are lessons in this project for me. The first and most important lesson is to always remember who your audience is. I cannot stress that enough. From now on, if ever a client asks me to do a site and gives me lots of specifications as to what it should act like and how it should look, I am going to immediately think about what's being asked. I'm going to ask what his brand is, whether he's fitting to the brand, and what the audience is going to feel like if they encounter that.

Another lesson is to always keep your head on your shoulders, even when faced with the inability of older browsers to digest what you've handed them. Towards the beginning of the problems with the CSS, it was literally crashing the v4 browsers that I threw at it. I've heard of this before, but I've never experienced it. To see it in action was not only exasperating, but also extremely dissatisfying. For years, we've thought that all browsers worked differently, sure, but that they had similar trends that made them part of the whole. It honestly hurt me to see something like NN lie down, cowering in fear at the mere sight of some of my work.

I didn't want to write a second site just for that. I didn't want to do the same thing that the browser was doing, in that frightened puppy-dog existence. I wanted to do something about it.

And finally, after saying that, the third lesson that I learned from this is that it is an egoist's dream to think that he doesn't have to support something. The web is all about community, as I stated above. The web is all about creating something that everyone can enjoy equally. It was presumptuous to believe that what I was doing was more important than my friend (that pays for Internet service by the hour) and his inability to upgrade the browser that came with his machine. I grew a lot from this site.

And I'm not romanticizing this, either. I'm just drinking a class of Scotch to salute the web and what it stands for. Perhaps I'm getting a little emotional, too. But if you don't feel it, you're not developing the web for the right reasons.

Got something to say?

Share your comments  with other professionals (0 comments)

Related Topics: Web Design, Graphic Design

 

Stephen Van Doren is a software developer and graphic designer from Denver, Colorado.

Media Temple

via Ad Packs