Category: Technology

When I first went to work at the dot-com, Skyfish, too many years ago, I was faced with an application that had a partial interface, little back end development, and that had cost the investors 1.5 million dollars I believe it was (might have been 2 million — hard to keep track in those days). Where did the money go was the question, and the answer was: it went on building lots of graphics and a really fancy Dynamic HTML (or DHTML or HTML and script) page navigation.

Well, the first thing we had to do, after firing the design company, was pull the DHTML out and revert to plain links for the menu. Why? Because DHTML menus don’t degrade gracefully.

I first heard about DHTML from Scott Isaacs at an invitation-only author introduction to the technology held at Microsoft’s campus. I remember when he–or actually, I think it was the program manager who did the demo–clicked on a name in a web page, and the space beneath opened up and more content was shown.

I was floored. I was astounded. I was in love. Up to that point, the only dynamic component of a web page was BLINK or an animated GIF, and neither of these was particularly helpful from a professional stand point.

In the months that followed, as the technology of CSS-P, as it was known then, was released, I spent an amazing amount of time working with it; I was sure it was going to revolutionize everything we knew about web page design. In fact, it was at that time that I became heavily involved with ASP, and between the two–DHTML for the front and ASP for the back–I felt that this was it: we could close the book on innovation, tell the other contenders they could go home now.

Well, it wasn’t long before cracks in this little nirvana started to develop. Whatever cooperation existed between Microsoft and Netscape at the rollout of CSS-P died a rather painful death, and we started having to deal with a thing called “cross-browser compatibility”–making stuff work in multiple browsers.

Microsoft really drove the browser market, too. Too fast and too far, and sucking people in right and left away from the Netscape browser, Navigator, to IE. The frenzied pace splintered the browser market and left us with a legacy of non-standard, proprietary extensions that haunted us for years. And then when Microsoft had us, they dumped us.

Compatibility across browsers wasn’t the only problem; we also had to worry about making pages work across browser versions. I remember about two years ago, when someone using Navigator 4.x asked me to change something in my weblog and I said, enough is enough, I’m no longer supporting a browser that was released six years ago. Now, I feel that way about IE.

Compatibility issues aside, other problems started to pop up in regards to DHTML. Screen readers for the blind disabled JavaScript, and still do as far as I know (I haven’t tried a screen reader lately). In addition, security problems, as well as pop-up ads, have forced many people to turn off JavaScript–and keep it off.

(Search engines also have problems with DHTML based linking systems.)

The end result of all these issues–compatibility, accessibility, and security–is a fundamental rule of web page design: whatever technology you use to build a web page has to degrade, gracefully.

What does degrade, gracefully, mean? It means that a technology such as Javascript or DHTML cannot be used for critical functionality; not unless there’s an easy to access alternative.

For instance, the main use I make of JavaScript and DHTML in my weblog is the live preview and spell check for comments. Now, neither of these is critical for people wanting to leave comments, and this means my site meets one requirement of the fundamental rule: the page can degrade. However, I made a design error when I added the live preview text area and Check Spelling button, in that I didn’t degrade gracefully: the Check Spelling button still shows, as does the live preview area. If JS is not enabled, these should not show. (It’s now an item on my to-do list.)

Whatever holds for DHTML also holds for Ajax. Some of the applications that have been identified as Ajax-enabled are flickr and Google’s suite of project apps. To test how well both degrade, I turned off my JavaScript to see how they do.

Flickr was a delight and an example of a web page that not only degraded gracefully, if it were a dancer, it would be the prima ballerina. As an example of this, there is an option on each photo page for the photo owner to add tags. Clicking the option instantly opens up a set of text boxes to add new tags. This is using DHTML, and very handy.

However, when you turn JavaScript, and hence DHTML, off, this option isn’t there, but you can easily edit tags and other information by clicking the edit link below. Flickr used DHTML to enhance the user experience, but never once built a dependence on the technology to drive the user experience. More, if you access the page without JavaScript, you’ll never know that you’re ‘missing out’ by doing so. Lovely use of technology.

Google’s gmail, on the other hand, did degrade, but did not do so gracefully. If you turn off JavaScript and access the gmail page, you’ll get a plain, rather ugly page that makes a statement that the primary gmail page requires JavaScript, either turn this on, get a JS enabled browser, or go to the plain HTML version.

Even when you’re in the plain HTML version, a prominent line at the top keeps stating how much better gmail is with a Javascript enabled browser. In short, Google’s gmail degrades, by providing a plain HTML alternative, but it didn’t do so gracefully; not unless you call rubbing the customer’s nose in their lack of JS capability “graceful”.

You don’t even get this message with Google Suggest; it just doesn’t work (but you can still use it like a regular search page). As for Google Maps? Not a chance–it is a pure DHTML page, completely dependent on JavaScript. However, Mapquest still works, and works just as well with JS as without.

(Bloglines also doesn’t degrade gracefully — the subscription is based on a JavaScript enabled tree. WordPress, and hence Wordform, does degrade gracefully.)

If we’re going to get excited about new uses of existing technology, such as those that make up the concept of Ajax, then we should keep in mind the rule of degrading gracefully: Flickr is an example of a company that understands the principle of degrading gracefully; Google is an example of a company, that doesn’t.

I’m in the middle of preparing my annual “Burningbird’s Bash of Etech” presentation. It will have the usual: laughs, tears, and passionate outrage and sad reflection in equal measure–not to mention, intense inspection of photographs with an accompanying “is the one with a shaved head, tattoos, bulgy chest, and eye liner a boy or a girl?” discussion. You know. The usual.

First, though, thanks to Rogi, I found out my host has created its first “Movable Type” free server, named Circe. (Hee, good name.) The thread to discuss this can be found here.

I’ve been watching the processes the last week or so, on the server and in my logs, and what I’m seeing is a lot of hits for trackbacks. And I mean a lot. Many are to Movable Type weblogs but the WordPress weblogs are getting their share, too. Now, because of whatever spam protection you have, these may not be showing up in your pages; but the pings are creating a significant strain on the database, which in turn strains the CPU and the disk I/O.

For instance, if I had trackback enabled, even with spam protection in place, each trackback requestion would still generate, at a minimum, four requests to the database and over thirty function calls. This isn’t that big a deal–until you multiply that several times a minute, and across many, many weblogs. Then repeat this daily, once in the morning and once in the afternoon, because that’s how often it’s happening.

Of course, since I’ve pulled every aspect of trackback from Wordform, the most that happens is that the web server returns a “404″ whenever one of my pages is accessed with “/trackback” appended.

I have no doubts that if this much activity is happening with WordPress, which is relatively stripped down as these types of applications go, much more is happening with the increasingly complex comment spam management in Movable Type. In addition, as Annette details in the HM thread — CGI applications such as MT spawn a new thread for each trackback request. I can say that the most limited resource on a server are these threads of execution.

I most likely will ask that my site be switched to Circe, as soon as I can. And to be honest, I’m feeling pretty damn smug for deciding to yank trackback out of Wordform, right about now. For you MT folks — if you’re not running the PHP version by now, you should be. And you also need to start pressing Six Apart into providing a PHP-based comment and trackback management system.

Or switch to new software.

Or continue dealing with problems.

Your choice.