Categories
JavaScript

Flickr DHTML: first looks

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.

Categories
Web

Have I mentioned

how much I love brilliantly executed satire?

Ladies and gentlemen, I give you Web 1.0! Please do not let the excitement go to your heads so much that you piss your pants. Or if you, do it in someone else’s garage.

Categories
Technology Weblogging

Security Assured

The security problem I mentioned in the last post does NOT impact on Wordform — huzzah! However, I did some good feedback about other areas of concern, so I will be making some modifications to ensure the application is as secure as possible — including making sure the metadata forms are only called from within the existing administrative interface. Ahem.

Still a lot of work to do, and I’m finishing up a PHP API for hire, so don’t expect release until next week. As soon, as possible–I promise.

Categories
JavaScript Technology

Ajax the Manly Tech

Seems that O’Reilly has had another one of its invite-only summits, but this time about Ajax. If you’ve missed hearing about Ajax, it’s the web development equivalent of tags (as taxonomy) and metaformats (as semantics). This is part of the technology that makes America, well, America.

A new twist, though: As you can see from the list of attendees, Ajax is the new manly-man technology. Or if you prefer, stud muffin technology.

Hey! Hey! Hey, hey, hey!
Macho, macho tech (macho tech)
I’ve got to be, a macho tech
Macho, macho tech
I’ve got to be a macho! Ow….

Macho, macho tech
I’ve got to be, a macho tech
Macho, macho tech (yeah, yeah)
I’ve got to be a macho!

What’s the tech equivalent of butt cracks and belching? Oh, yeah! XmlHttpRequest and Javascript!

Normally I would be all up in arms about the absolutely abysmal ratio of women to men, except we’re talking about Ajax. What did one statement from this summit say? Ajax is to traditional Web, what IM is to Email. Nice and catchy, except I can think of a better analogy: Ajax is to traditional Web, what Miller Lite is to beer.

Macho, macho tech. I want to be a macho tech…

Categories
Technology Weblogging

One more release

Recovered from the Wayback Machine.

There is some form of security problem with WordPress 1.5, and the developers haven’t identified it. Since Wordform is based on WordPress 1.5, I’ll have to try and guess what it is to fix it–if I am vulnerable to whatever it is.

I’ll be providing one more release of the code as soon as I can, and that will probably be it for me for awhile, as I won’t be online that much in the months to come. I’ve been working some odd jobs recently and that slowed the release of this product — but no one is dependent on it, it’s primarily for fun, anyway, so I don’t feel too badly.

The metadata portion of the application is fun and I think it’s interesting, and worth checking out for this if no other reason. I like the tool, but can’t recommend it to folks when things are so iffy.