Category: JavaScript

Flickr recently pulled its use of Flash in some of the pages and replaced it with DHTML (Dynamic HTML). If you’re not familiar with DHTML, it’s a mix of scripting language and underlying page ‘object’ model’ used to modify the appearance or behavior of the page without having to reload it from the server.

I was pleased to see this move, not the least because Catarina used the word “DHTML” to describe the technology used rather than the newer, hipper, AJAX. Doing so tied this effort into previous uses of the associated technologies: this, in turn, linked this new effort to a rich set of *existing tutorials, libraries, examples, books, and articles that are being missed when people searched using the newer terminology.

An additional reason I’m pleased is, of course, the fact that much of the functionality at the site is now no longer restricted to having Flash installed — something that prevented the page from ‘degrading gracefully’ with non-Flash enabled browsers.

Focusing specifically on each individual photo page, I like the fact that much of the photo annotating capabilities are now available for ‘in-place’ editing: capabilities such as adding a photo to a set, sending to a group, or blogging the picture. The sets and groups loaded a bit slowly at times, and I wonder if pre-loaded, or on-demand, client-side caching couldn’t be used to help this along a bit. Regardless, it’s much simpler now to use these functions without having to go to separate pages.

I also enjoyed that the Flickr folks didn’t try to obscure the JavaScript so we could look at the DHTML used; in particular seeing the interface between the new DHTML connecting with the existing API to handle much of the photo toolbar functionality (such as Send to Groups and Add to Set). I also appreciated the humor present in this script, when seeing the ‘george’ and ‘catarina’ objects. After all, if we can’t have fun with our work, what’s the point?

The new functionality is great, but returning to the original issue of ‘degrading gracefully’ what happens at Flickr when you turn off JavaScript? To test this, I turned off JS in my Firefox browser, and then accessed one of my photo pages; creating a snapshot of the page to use as reference in this discussion.

First, prominantly displayed in the page is a message (1):

To take full advantage of Flickr, you should use a JavaScript-enabled browser and install the latest version of the Macromedia Flash Player.

There isn’t anything wrong with letting people know there is an advanced script enabled interface to the page, but to do so in such a prominant manner disrupts the flow of the page. Making an assumption that people viewing the page don’t have JavaScript enabled for a specific reason–because they’re using a screen reader or they’ve had problems with JS in the past–also means assuming folks know they’re not going to be able to access the goodies. The message about an advanced interface should be placed in a less prominant place; certainly not between the photo title and the photo.

The positioning of messages such as this doesn’t necessarily imply that the page isn’t degrading gracefully. However, displaying a non-working toolbar (2) does impact on the overall positive effect of the page. If you turn off JavaScript, and try to click any of the buttons above the image, nothing happens. There are few things more disruptive to a page than to provide a button or functional icon that cannot be accessed.

Rather than display non-working buttons or icons, a more graceful approach would be to test to see if JavaScript is enabled at the server, and then output link-based alternatives (with or without associated graphics) for those functions that can be accomplished using more traditional web techniques. From the existing toolbar and from what I know of the API, this means including links to pages that allow a person to send to a group, add to a set, access a page with all sizes, delete the photo, and blog the photo.

The only item that would most likely be dropped is add a note, unless this can be managed using text-based coordinates (showing the photo layed out on a grid and having the person intuit and input where the note box would begin). Even the rotate image capability could be emulated using server-side graphics utilities and a hypertext link.

The Flickr developers could also use existing client-side techniques to test for JavaScript and either display the JS-enabled toolbar or a HTML links-based toolbar. There’s a tag, <noscript> that will display different page contents if JavaScript isn’t enabled. Used in combination with enclosing the script in HTML comments should ensure that the page works equally well in all user agents/browsers.

(Which approach to use–testing at the server or the client–is based on other factors, but both work equally well to ensure the page functions effectively for all readers.)

This testing for whether script is enabled could also be used for the functionality to add tags. Right now with Flickr, if you have a JS-enabled browser, there’s an option associated with the Tag grouping (3) that allows the user to add tags directly in the page. For non-JS user agents, adding a link to a second page for editing tags provides the same option even if the behavior isn’t exactly the same. It is true that this and other options are available lower down in the edit grouping (6); but there’s no harm in putting a link ‘in context’, rather than force the person to have to search around for the capability.

The same applies to the photo navigation (5). The links to the next and previous photos are missing from the non-JS enabled experience, and I’m not quite sure why. the photos above the navigation link are are basically the same type of functionality, and show with both the JS and non-JS enabled browser. Not providing next and prev links to traverse the photo stream seems to be more of an accident than intent — this one isn’t DHTML dependent as far as I can see.

Finally, the last item is the slideshow (4). For those browsers so equipped, the current slideshow remains Flash-enabled. Right now in non-JS browsers, the link to the slideshow does work, but clicking it takes you to an empty page. I am making an assumption that a non-JS enabled slideshow is in the works and that’s why the link is still present. However, if a non-JS enabled slideshow is not in the works, this link should be removed–no need to demonstrate to folks what they’re missing.

(A Javascript-enabled slideshow would also be nice, as an alternative to those who enable script, but don’t allow Flash–though I realize that Flash is most likely better suited to this effect. But it seems a pity to stop when the company is on a DHTML roll.)

All in all, Flickr’s move to DHTML is a good one, and the interface is very clean and intuitive. Even these items mentioned in this post (other than the slideshow) are minor and, if the organization is so inclined, easily corrected. I also appreciate being able to see under the covers, so to speak, and looking through the Flickr JavaScript gave me an idea of how I can mix Flickr’s API into one of my existing DHTML applications. Nice to know that my old skills now have new uses.

(Thanks to Doug and Karl for the heads up on this.)

*Disclaimer: I wrote a book on DHTML in 1998, as well as having written several articles and tutorials on the subject. I’ve also created several DHTML script libraries, and hundreds of DHTML applications and examples.

To the best of my knowledge, I’ve never once created an AJAX library or application.

I’ve been hearing quite a bit about Ajax, the new wonder technology lately, and finally decided to take some time to check it out.

I followed the link to the Adaptive Path essay on Ajax, and started reading through the writing until I came to the diagram showing an “Ajax Engine”, as part of the new innovation. Being a geek like most other geeks, I then stopped reading and starting looking around for the download button for this new Ajax Engine. Not having found anything I could download, I returned to the essay and continued reading.

What I found is something that sounded strangely familiar. In fact, this ‘new’ technology sounded just like DHTML–Dynamic HTML–except that there was a reliance on a non-browser safe object called the XMLHttpRequest: an object to manage asynchronous XML access from the server from within web pages. An object invented by Microsoft for IE and implemented in Firefox and Safari, but not an objects that’s guaranteed to be cross-browser safe to use.

I admit, I was very confused by this time. I wrote on DHTML in 1998, in fact wrote the book whose cover you see in this post. I have hundreds of examples of DHTML, most several years old. I’ve even used the request object a time or two, but wasn’t necessarily overjoyed by it: I really didn’t like using proprietary objects when I couldn’t find the same functionality in other browsers.

In the FAQ attached to the essay, I did receive some clarification:

Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?

A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.

Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?

A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.

Q. Is Ajax just another name for XMLHttpRequest?

A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

I then read Dare Obasanjo’s excellent tap-tap that yes, the emperor is naked, and that Ajax really is Dynamic HTML with the use of the proprietary XMLHttpRequest object.

(Of course, I’ve used the term DHTML and Dynamic HTML, and in Dare’s write-up, even this is a renaming of an existing concept, so mea culpa in that regard.)

Wow, I didn’t know that I was ahead of the times when it comes to technology. I feel so super cool right now. To celebrate, I decided that I would go through all my burned CDs and recover my old DHTML applications in addition to old write-ups. As I find them, I’ll post them into posts labeled “Ajax” so that you know you’re supposed to jump up and down. (The old Well, if Google uses it then it must be OK thing.)

Starting with one of my favorites: The DHTML Menu Button from Hell, used to demonstrate the benefits of using DHTML to build menus. But if you don’t like that one, then how about Pick-A-Pair–a favorite script of porn sites the world over. Betcha can’t win the triple game.

Of course, this isn’t really Ajax, which requires the use of XMLHttpRequest. Let’s call it “Aja”, instead. Or perhaps “web safe Ajax”. But I’ll see if I can dig up something proprietary for you to see — back when these samples were built, years ago, I tended to focus on standards-based objects and cross-browser compatibility. I now kick myself for seeing that this wasn’t the way of the future.

You know, that’s why we women in technology never get ahead. We just don’t understand the right way of doing things.

update