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.

Image courtesy of Flickr user marttj

Image courtesy of Flickr user law_kevin

Question: Will the way volumes are digitized today change the way that work is done in the future: less close reading more broad reading/more data mining and deduction across corpora. Are the traditional monograph-driven disciplines a strong enough force against the tides of Google-ization (i.e. the “close enough” answer is the good enough answer)?
These questions are being explored by author David Weinberger in an upcoming book he’s working on called Too Big To Know and he gives some insight into his writing process and the arguments he is pulling together for his book on his Joho the Blog. It’s interesting both from the perspective of getting an inside look at an author’s process and for the sake of the arguments themselves. Check it out.

I ask because now we can add Google to the list of content providers who think they know us better than we do. Aside from the questionable deepening of the echo chamber that already exists on the Internet (Roy Tennent breaks Godwin’s law here by bringing Nazis into it, but you get the point), this just frustrates me so much because 9 times out of 10, these things DON’T WORK WELL.

Social search will do things like show you a document your friend wrote in search results if it’s related to something you’re searching for, and that document will receive more prominence on the page.

My “friends” are not the experts on everything! I don’t need my own, personal Google.

And as a librarian, and a human for that matter, I hate to think that I might be looking for information that might be lost or lowered in the results because I was previously looking for information on something else.

Don’t even get me started on the lack of transparency. At least I can (supposedly) turn off the “personalization” in Google News (just because I’m more likely to read the entertainment news, that doesn’t mean I don’t want to see the actual news headlines…).

Let Me Tell You about My Grandpa: a Content Analysis of User Annotations to Online Archival Collections by Jessica Sedgwick, Archivist for Women in Medicine at Harvard Medical School.

(I’ve just been informed, as well, that this presentation was actually given at SAA last year)…

The research presented investigates how users interact with digital archives when they are given the facility to comment. The results of her analysis are interesting. While I’ve observed the same things, I’ve never thought about quantifying it like this. I think it’s also interesting that the site with the sparsest metadata had the highest number of comments, but the site with the most metadata had the highest proportion of corrections.

Anyway, just for your reading pleasure…

Apparently, the (short story) is that up until IE 7 (feel free to correct me if I’m wrong, by the way), Microsoft didn’t feel it necessary to ascribe to any sort of HTML-based standards. Most everyone else, basically, did. When they came out with IE 7, they had a huge internal debate – do we suddenly learn to play nice and create a standards-based browser this time, or do we continue down our own, proprietary, non-standardized path? They were “nice enough” to play with the rest of the team and adopt some standards. This is all good, right?

EXCEPT that IE 6 is still OUT THERE. HAUNTING US. TORMENTING US with its non-standards based self. And, A LOT of people are still using it (something like 17-ish percent).

Well, I was glad to see the other day that I’m not alone in my frustrations, and that there are some folks out there trying to do something to rid us of the insane havoc (as if havoc alone wasn’t enough) that IE 6 has wrecked on so many web developers. I give you ie6nomore.com.

Spread the word, people.

Wow. This actually turned into a much more religious tract than I meant for it to be. Ah well. I guess Microsoft will do that to you, sometimes.