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.
