Well, Stephen Abram and Richard Wallis beat me to it, but I thought it would be worth mentioning that Google is now enabling users to extend the Google Gadget to their own personal web pages.

For example, here is the AADL top items list using onr of my Google gadgets (seems to not work in some browsers):

Very cool and very easy.

I’ve made a little update to two of the PatREST Google gadgets (top and new items)–partly due to the insistance of a certain Superpatron, but mostly because I was planning on doing it anyway.

The new versions allow users to display cover images along with the records. A new option gives you the choice of text only, images only, or images and text. Not a major change, but noteworthy. Also, in case you missed the update in my previous post, the new items gadget can now match subject headings–useful if you want to be notified about new items on a particular topic.

For the purposes of the Talis mashup competition (for the judges), the original xml files are still available under a different name (tops-v1.xml and new-v1.xml). Everyone else, here are the new ones:

• tops.xml
• new.xml

(FYI, it’s the same URL as the previous version. If you’ve already added it to your Google page, the update will be automatic)

While working on this little project, I became painfully aware of PatREST’s limitations when dealing with asynchronous execution — like that of Google gadgets. I previously thought it would be better to limit the amount of data returned in an XML hit-list and use a second record query for and detailed info. I think I may have been a little short-sighted. At any rate, the lesson learned is that the more practical experience I have with PatREST, the more I’ll know what works and what doesn’t.

The upshot of all this is that I’ve expanded the result objects in any PatREST function that returns multiple records to include more information, such as ISBN, cover image, author, and record link. For those asynchronous folks, this will make life a lot easier. The new additions have been added to an updated specification. Existing PatREST applications (I don’t think there are many at this point) will continue to work, of course.

I know I’ve written a fair amount in response to Dion Hinchcliffe’s posts, but I wanted to point out his latest offering which highlights a number of great Ajax resources. He’s tends to look at Web 2.0 objectively in a way that I appreciate. Lately he’s been on a roll.

I’ve said before that we need to be careful about laying our hopes and dreams at the feet of the (supposed) almighty Ajax. I still believe that, but I think it can fill a niche that desperately needs to be filled. I was talking with Eli Neiburger today about the new MiLE client. (You may remember from a previous post of mine that MiLE was recently hacked. Badly.) Their new client, much to my chagrin, is java. Java is a network administrator’s nightmare, a relic that urgently needs to be put out to pasture. I’m truly disappointed. For what that client does, an Ajax alternative could easily take its place.

Ajax is well positioned to address the need for client-side, stateful applications. I’d like to see the “next gen” ILS and ILS support software take advantage of it in place of Java. Requiring a contemporary web browser is a much more reasonable expectation than requiring customers to juggle different versions of the JRE. I understand that using java has helped to defray operating costs for vendors, but with Web 2.0 technology, the same level of ubiquity can be achieved without penalizing the customer by encumbering them with a ’90s albatross. This could easily be done using the model I (and others) have been begging for: light clients, extensive, standards-based APIs. The tools Web 2.0 has made available obviate the need for complex client-side applications.

Let me be clear on the difference between what I’m suggesting in this post as opposed to what I’ve said about Ajax in the past. I do not think we should launch into projects that require our patrons to have Ajax-capable browsers. I think that would be premature and somewhat irresponsible. I’m saying that the applications vendors require libraries to use on the back-end should adopt Web 2.0 technologies, such as Ajax. Shedding an old technology like java should be a priority.

Hinchcliffe’s article also serves as a good starting point is you are looking to read some material that will familiarize you with Ajax. He also points out that it is improving, and worth keeping an eye on.

Google isn’t the boss of me!

A colleague of mine just pointed me in the direction of a talented flash coder’s blog post detailing his use of Yahoo’s Map API. His examples are brilliant. Moreover, they’re a testament to how Yahoo has done it all right.

First, Yahoo has decided to use flash as their UI engine. Thank God! I think this is a perfect example to backup what I said in my earlier post about Ajax. Ajax is not well suited for large-scale applications. Adding discreet bits of Ajax code to a web page can enhance functionality, usability and end-user experience greatly. But, make the page too reliant on Ajax and it becomes cumbersome, slow, and bug-prone. Think of Ajax as a condiment, not an entree.
You can appreciate Yahoo’s adoption of flash in this product when you see how fast, smooth and visually pleasing the result it. That’s what flash lives for.

Second, check out how extensive the API is! Okay.. let me gather my thoughts around the coolness.

There is the simple API which is what you would use if you wanted to embed maps in your website. Quite easy to follow.

Then there is the actual Flash API which essentially has three components. The Actionscript API, the Javascript API and the Flex API. I’m actually not sure how the Javascript API is a subset of the flash API because as you’ll see on the page, it doesn’t require any Flash programming. *Shrug*

Finally, and here is the real kick in the pants. There is an Ajax API, which basically means you can use DHTML to do on-the-fly changes to the map as it appears on the page. Wow! totally cool. Can you see the convergence now? I think this is such a great example of next-gen application development.

(can anyone say circulation interface?)

Okay, but there is the caveat concerning the ubiquity of Flash. I’ll acknowledge that not everyone has it installed, but my answer to that is that it’s easy to install, its a fast download, its stable and its not a fad technology. Flash has been around for a long time. I remember someone telling me that Flash is just shy of “killer app” status. I think it’s a contender, especially now that Adobe is behind Macromedia. It’s a technology that is positioned to fill a crucial technological gap in a whole slew of forthcoming next-gen applications.

So, back to the Justin Rich. He’s got two great examples of what can be done with this type of technology. Check out his pirate map and radar. There’s no way you can’t call that cool-as-hell.