Mobile version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer


Weblog Entry

A Horror Story

February 26, 2003

Picture if you will, one peaceful Friday afternoon at work. A conversation with the boss about a new client, Thomson Widgets, Inc., who is a customer of marketing firm Catchy Marketing. A URL is given where you can view a few JPGs of Thomson’s new site that were comped by Catchy. How long will it take you to convert to XHTML and implement content?

A fairly simple job, you ask for about 20 hours. It was wanted for the Friday of the following week, so that affords you plenty of time. What could possibly go wrong?

Seemingly, plenty. For starters, you aren’t contacted until Monday afternoon. A meeting is arranged with Catchy for Tuesday. It goes well, things are discussed, and the result of the meeting is that Catchy will send content and Photoshop source to begin work that afternoon. This being Tuesday.

Wednesday at 4:30pm, the source arrives. Being the diligent web designer you are, you start work that evening and continue Thursday morning. All day Thursday you spend converting the template to xhtml and testing in the major browsers.

Naturally, Catchy is a marketing firm, so they don’t need to understand browser–compatibility issues. They view everything on Netscape 4/Mac. They expect pixel–perfect code.

Your insides scream. You curse the monitor and smash your head against your desk every time your fix for NS4/Mac breaks IE5/Win. You’re damn good though, and you eventually get it just so. This is good, this is very good. Now for the content.

You receive a half–completed PowerPoint presentation to work from that cross–references information that isn’t there, and you start hearing rumour that Thomson Widgets wants to see something for Friday afternoon. Being but a subcontractor, you redouble your efforts and make Catchy look good if you ever want work from them again. By Friday afternoon, you have fleshed out the 2 major content sections that were at the top of the priority queue, and Catchy is able to show Thomson the work–in–progress. By Monday morning you complete the rest of the content according to the PowerPoint document and inform Catchy who then, theoretically, get back in touch with Thomson for the content.

Monday PM, no content. Tuesday AM, no content. Tuesday at 5 minutes to noon, you receive a few short pages of content from Catchy, and appended to the same e–mail is a note telling you that Thomson has a conference that day, and needs to have the site launched at 4pm.

This is the first you’ve heard of this conference, or this requirement. A mad rush during the afternoon to get everything in place, while Catchy keeps calling with additional design changes because “this item should be up a little higher” or “we need a bit more white space here.” Eventually things are ready to go, as incomplete as they are (you even spend the time removing the bold, red text that specifically points out missing content areas that Thomson was supposed to provide) and so now you need login information to do your thang.

3:30pm — You call Catchy and request the login needed to connect to Thomson’s server and upload your files.

3:40pm — You try logging in using your FTP program of choice… and… no such luck.

3:42pm — You try again. Nothing. The server is not responding.

3:45pm — You call Catchy back and ask for a port number. They say it should be standard. You tell them there is no FTP server responding. They ask what that means. You swear. But only in your head. The information they’ve given you is great, provided there’s FTP software running on the server, but it doesn’t look like there is, so you can’t do a bloody thing, and you tell them so.

4:10pm — After asking Thomson what’s up, they call back. It turns out Thomson uses some obscure copying program that works on the same principle as FTP, but is obviously more “secure.” This would have been handy information to have ahead of the fact, and you tell them that. Not a note of sarcasm or malice in your voice. You’re a professional.

4:48pm — After grabbing the new software, you login, things are looking good. You make a backup of their existing site (why the hell is that your job?) and upload your files. You refresh your browser and… nothing.

4:49pm — Nothing? What the… oh. Oh. OH CRAP.

Your shop is Microsoft–based. You run everything on IIS, and that’s what you’re used to developing for. Up until Monday morning, you had no idea where the site would eventually end up, and just assumed you’d be hosting it. That’s standard procedure around your office. Well, funny thing, Thomson runs their own web server, and surprise surprise, it’s Unix–based.

4:55pm — 5 minutes before you should be leaving, you realize that all your scripts, all your include files, and all your links have to be changed in order to get this site live today. You panic. You calm down. You panic again. You refrain from authorizing The Destruction of All Life, Everywhere, but it’s a close call.

5:55pm — After madly copying and pasting include file content into the .asp files themselves, then renaming them as .html files, you thank your choice of gods for Find & Replace. That takes care of links. The scripts? You drop ’em and static–ize everything that was dynamic. Screw it, You’re not re–writing your random image and date/time scripts in PHP, a language you don’t even know, they will live with that till Wednesday.

You finally get the site uploaded, live, tested, and by 6, you have put out all the major fires. Screw those guys, you’re going home. Let’s summarize what this project required of you, shall we?

  • Knowledge of XHTML
  • Ability to work with Photoshop and convert .psd files to .gif/.jpg
  • Ability to tell a non–web designer why his ideas won’t work on the web, and suggest alternatives that he’ll be happy with
  • Knowledge of W3C standards, the quirks of the major browsers, and how to fix them
  • Javascript
  • ASP scripting
  • Ability to diagnose why you can’t connect in a standard way to someone else’s screwy network, and how to fix the problem.
  • Why uploading an ASP file to a Unix server doesn’t work
  • How to fix an ASP file so that it works on a Unix server
  • The ability to keep your cool while having to put up with horse manure from not one, but two seperate parties

…and you know what the kicker is? You’re the company’s designer.

Taken from the Real Life Horror Stories file. It’s all true. But you knew that. You’ve lived it too.


Reader Comments