Category: Technology

One of the things I liked about movable type is that you could choose the formatting on a post by post basic. That doesn’t necessarily work well in a dynamic environment, but I did add an option in the post edit page to choose whether you want the content formatted (using default formatting as per WordPress/Wordform, or plugin), or if you’ll apply your own (X)HTML.

This is a test to see how it works

This is a test

update

I’m tired of splitting my focus between 3 or 4 projects and never quite finishing any of them. Instead, I’m going to focus on one–coding Wordform–so I can put the first release of the code out on the street for the daring of you to trip over. I have some writing to do, and the store and Tinfoil to finish, and I want to spend time in the Ozarks in the next couple of weeks finishing my photos of mills — but I’ll feel better doing all of these things if this one item is checked off.

What this means is this weblog and my others may be going through some interesting times in the next few days as I start modifying some of the core infrastructure elements. Expect things to break; copy your comments before posting; ignore the purple paint, broken glass, and hole in the floor.

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.