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.
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.
(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.
*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.