Project: Web (part one)

Back in January, the folks at the Community Software Lab were asked by a university-based non-profit if we could translate an artist's Photoshop mock-up into HTML and CSS. Eager to please (and needing some money to keep the budget balanced), we said "sure" and submitted our estimate for 20 hours of work. It's March, and we're still working. What's the deal?

For my part, I gratefully ignored things until the last week of February, content to let Dan, my boss, manage the project. He had subcontracted the work to Erich, our soon-to-be VISTA, and for the most part, let things be, receiving changes from Erich every few days. It worked great--as long as changes didn't need to be made immediately. Erich put together some pretty good code and certainly earned his 20 hours' paycheck. Then things began to pick up.

Dan and I met with our clients and their contractor, hired to handle eZ publish, the content management system (CMS) behind the existing website. At this point, we were asked to clean up a few errors in our code, and Dan asked me to take over managing our end of the project.

"Sounds fun!" I thought. This initial enthusiasm has kept me at times from tearing my hair out.

First task: talk with Erich and find out how many hours he's worked. Seventeen. Cool. He can fix the styling errors and fill out his 20 hours. I can stay detached from the actual coding and work on learning server virtualization, adding Gallery to another client's website, debugging our Samba server, and installing SMTP authentication on our mail server. It hasn't turned out that way.

Behind every website is HTML. Perhaps that's a bit of a simplification, but it's not too far off. HTML is the end product of every website designed for a personal computer. The web browser knows HTML, and the web browser is boss. It then stands to reason that a large part of any website's success is based on what sort of HTML it gives to the browser. Wonderful HTML doesn't guarantee a good site, but improperly written HTML throws a wrench in the works. It causes some browsers to balk while others work fine. Text turns into links; links turn into text. Cats and dogs live together. Well, it's not quite Ghostbusters-bad.

A big chunk of the issue hinges on the very first line after the server tells the browser "Content-type: text/html<CR><CR>" -- that pesky <!DOCTYPE> declaration (man, I hope Drupal escapes this sentence correctly!). This guy tells the browser which version of HTML is being delivered. There a few different versions these days, but the big ones are XHTML 1.0 and HTML 4.01. XHTML is newer and more programmer-/machine-friendly; HTML requires fewer tags. The crux of the issue, though, is how the browser handles each. Most browsers these days display content differently depending on the <!DOCTYPE> declaration they receive with each page. Give them an XHTML 1.0 declaration, they do one thing; give them an HTML 4.01 declaration, they do another. Thanks to the trial and error of many web developers, this behavior is pretty well documented. Give a browser one declaration, but give it code corresponding to a different declaration--then you have problems.

The old site used the HTML 4.01 declaration, but which declaration to use for the new site? We chose XHTML. It's definitely easier to spot flaws in an XHTML page, and stylesheets work differently with XHTML than with HTML. Mostly, though, it's an aesthetic thing. With XHTML there is no ambiguity. Every tag has a beginning an and ending, and its content is determined by the beginning and the ending of the tag, not by the browser's interpretation of the tag, as is sometimes the case with HTML 4.01. Ask someone else, though, and you'd likely receive a different answer. The point here is that there are pitfalls involved with converting a site from HTML 4.01 to XHTML 1.0. Beware of this. Don't do it just because it's trendy. Even though we're using a content management system, we'll still be uncovering small bugs a month from now.

Back in January, I first received the artists' mock-up as an e-mail attachment. I was cc'ed on the e-mail. Trouble was, in addition to the mock-up, there were two other image attachments along for the ride--a pdf file of the entire mock-up and a gif file of five pictures, arranged in a row, artfully merged together. What to do?

Well, as a bystander, I did nothing for a month. Fortunately I kept the e-mail, though I must say I rarely delete e-mails. When I finally started working on the project, we were asked to smooth out the site's banner image. It seemed a bit blurry, but I wasn't sure why. I asked Erich to take a look and send me an updated image.

Still in error-fixing mode, we needed to keep the left-hand navigation links from resizing if a word got too long. We also needed to keep the main content from dropping below the left-hand navigation when the browser window got too small. Where it existed, we also needed to update the right-hand column.

(End of Part One)