He’s written a series of tutorials on using the new Google Maps API, which he’s expanded into the recently published book: Beginning Google Maps API 3. All of the code demonstrated in the book is available for free download. I wish I’d had this book when I’d started the project – it would have saved a great deal of trial and error on my part. The author says that even those without much web development experience should be able to get a Google Map up and running. While I don’t disagree with this, the author introduces some advanced JavaScript fairly early in the book. Library staff members can follow the tried and true, copy and paste method, but some of the concepts, like anonymous and self-executing functions, might leave them scratching their heads a bit.

The author begins with a brief history of the Google Maps API and then takes a detour into upgrading from Version 2 of the API to Version 3, which the author recommends skipping if you don’t have any legacy applications to upgrade. However, I found it a useful general overview of the concepts discussed later in the book.

The rest of the book starts with the development of a very simple map. Then each chapter builds on the previous chapter in terms of map features and complexity; including such common mapping tasks as creating clickable markers that open information bubbles and creating polylines and polygons, used to create such things as driving directions, or to highlight specific geographical areas. The author follows the pattern of introducing a chapter’s main concepts and then working through them bit by bit, ending each chapter with the completed code for that chapter. I found this practice quite helpful as I didn’t have to flip back and forth as I have in other technical books to figure out the totality of what was going on.

The author also discusses several other often used features such as using Google’s
Geocoding service to find a user’s location as well as how to create custom markers. One particularly useful feature the author discusses deals with maps with large number of markers, anything above 1000, at which point a map’s performance starts to seriously degrade, particularly in Internet Explorer. This was something I ran up against very early in the development process. The author discusses the pro and cons of the various methods to deal with this problem, enabling a developer to easily choose the one that’s right for his or her particular application without having to code up each option and see what happens.

The book concludes with a very helpful overview of the API features discussed in the book, going over exactly how to use each class and method.

One concept I wish had been discussed in the book was dynamic sidebars, where a user can click a sidebar link to open the info window for a particular point. I found this one of the trickiest parts of developing our application.

All in all, I’d highly recommend Beginning Google Maps API 3 to those looking to develop Google Maps applications with the new API. It’s clearly written with lots of examples and pictures of exactly what the code’s output looks like. If you’re merely looking to embed the location of your library/institution in a Google Map this book is definitely overkill. However, if you plan on working on anything beyond the very basics this book is a definite plus. It will be particularly helpful to those with some previous JavaScript experience.

We are exploring lots of options for digital asset management systems – right now, we are experimenting with a home-grown system, and while the backend seems ok so far, the interface needs major work. It’s clunky. The system also lacks capabilities for global find-and-replace, implementing controlled vocabularies, and easy data import/export. Also, folks with levels of expertise ranging from super-duper advanced to novice will be working on our projects, so we want to ensure some ease of use.

We’ve also been playing around with ContentDM, Omeka, and Fedora. There are aspects of all three that I really like and things that cause me some concern. (We’re excluding DSpace from the mix simply because it seems much more suitable for IRs and the like, but please feel free to correct me if I’m wrong about that and you love using DSpace for image-based collections.)

So I come to you, my digital library pals – I’m sure you have strong opinions on these products. Do you have songs of praise to sing about any of them? Any huge warnings about what NOT to go with? We want to make sure we get as many perspectives as we can so we choose the right system for our needs.

• Duke Digital Collections asking for input on the redesign of their web interface (no comments yet; let’s get going!)
• UNC Libraries’ request for feedback on the newly-launched Hugh Morton digital collection in CONTENTdm

And yes, this is a sneaky way for me to publicize the Morton digital library….

Blimp advertising The Outlaw (film) from UNLV's digital collection "Howard Hughes: Welcome Home, Howard"

UNLV just announced a couple of new collections this past week. Both of them have pretty great interfaces, especially considering that they are built on CONTENTdm. We all know about CONTENTdm’s weaknesses and strengths, but those of us who use it everyday are intimately familiar with the challenges that its interface poses. Not built in XML and not built with CSS (or, just barely), making the interface “your own” involves following cryptically named links back to multiple “style sheet pages.” It is sort of like trying to figure out which one of the cords in the back of your desk is attached to the printer. . . in the dark.

Anyway, UNLV seems to have solved this problem with something they are calling “dmbridge.” I won’t go into the details here, because they’ve already done that at this link (http://digital.library.unlv.edu/dmbridge). But, I will say that they have incorporated lots of Web 2.0 features that are reflected in their two new collections, “Welcome Home, Howard” and “Southern Nevada: The Boomtown Years.” And, apparently, they will be sharing the code.