Jason Levitt recently announced in a Yahoo! Developer Network blog entry (dated December 21, 2007) that Yahoo! Maps is now pure JavaScript. In the past it was a hybrid Flash/JavaScript application. The new port brings, according to Levitt, "at least double the performance of the previous Flash-based version". And of note to developers, the enhanced version of the Yahoo! Maps AJAX API which is being used in the newest version of Yahoo! Maps will be made available to developers sometime in 2008.

To be honest, I haven't paid all that much attention to Yahoo! Maps over the last couple of years, as both their "flagship" application (maps.yahoo.com) and their API have, to be quite honest, failed to impress. And (staying honest here), after using the application and perusing the API again tonight, I'll have to say that I'm still not all that impressed:

• The application's responsiveness just doesn't seem to be up to par when compared to Google and Microsoft's mapping applications (maps.google.com and maps.live.com, respectively). Please note that at this point, this is just an observation; I haven't conducted - or even looked for - any performance tests, but I definitely think that Yahoo! has a long way to go before they'll be able to start seriously competing against Google and Microsoft.
• On top of this, the look and feel of the application just doesn't do it for me. In my opinion, Microsoft - with its latest release - has the best looking and most usable interface out there. Google still has more "Wow!" features ("Wow! I can drag a route to change it!" ), but I don't think that I've ever actually used any of them.

To close, I'm disappointed that Yahoo! - one of the companies that really led the way in the early (2005) web map API days - has fallen so far behind. I hope that this coming version of their Maps AJAX API will bring them back into the competition.

So, the "Find" and "Find/Replace" tools aren't an important part of Visual Studio, are they?

I recently installed the RTM of Visual Studio 2008 Professional on my Windows XP x64 machine, leaving Visual Studio 2005 installed, as well, just in case things went awry with the new version. I've been using the early release versions of 2008 for sometime now, and have been impressed with the performance improvements and many of the new features, so I didn't think that I'd have too many problems with or misgivings about the upgrade.

Well, after the install I was working in the IDE and used the trusty Ctrl-F combo to open up the "Find" dialog. Visual Studio 2008 immediately conked on me. Totally conked. I opened it back up and tried Ctrl-F again and it conked again.

At this point I was ready to go back to 2005 (I was pretty disappointed in the much-hyped JavaScript debugging already), but I decided to do a quick Google search first. After performing the search, I ended up on the Visual Studio feedback site at the "Visual Studio 2008 RTM Search Crashes" bug report.

For those of you who aren't into reading bug reports, I'll summarize the contents: If you use more than one monitor and a utility (UltraMon in my case, but could be a utility that comes with your video card or any other third party utility) that helps you manage the multiple monitor setup, Visual Studio 2008 will crash when you open up the "Find" and "Find/Replace" dialog. This bug is apparently not a problem with Visual Studio 2008, but a newly-discovered (or at least newly-publicized) bug in Windows XP x64.

After reading through the multiple posts that were associated with the bug report, it became painfully obvious that I had only two choices: either uninstall my baby UltraMon or go back to using Visual Studio 2005. I didn't even have to think about it; I immediately went back to using 2005 and accepted my fate.

Today I randomly decided to check to see if an update for UltraMon had been released, and lo and behold it had! And talk about lucky - in this newest release (3.01 = beta 2 of 3.0) Realtime Soft decided to take some of the Windows 'hooks' out, meaning that the Windows XP x64 bug that was causing my Visual Studio 2008 Ctrl-F issues was fixed for me immediately!

It seems like the ArcGIS Explorer development team is trying to rub my office's horrifically slow network connection in my face.

After yesterday's release of the newest build of ArcGIS Explorer, I was interested in trying it out. So I downloaded it (and yes, the download took forever), installed it (and no, the install didn't take long at all), ran it, and waited. And waited. And waited some more. It took *forever to load just the initial globe.

But finally the globe loaded and I started to take a look around the interface.

I ended up clicking on the "Help" menu and found a new "Test connection speed..." tool.

After running the tool, here's what I was told:

I know what they're going for here, but still thought it was funny that ESRI was actually telling me not to use their application. And no, I am not on a dial-up connection at work.

This brings up an interesting question: as bandwidth becomes more and more of a precious commodity in some organizations (like the one that I work for), are IT staff still going to allow users to install these bandwidth-heavy virtual globe applications? And even if IT staff are supportive, won't most users get frustrated with the performance of these applications in situations where bandwidth is in scarce supply and stop using them?

I know that bandwidth is going down in price and improving for most organizations, but there are a lot of companies out there that can't (or aren't willing to) keep up with the growing bandwidth requirements of a web-centric world. It would be a folly for the major mapping vendors to ignore this group of users.

This realization is why we're currently focused on high-performing (and lightweight) web map implementations and not standalone desktop applications that consume centrally-located services. This is also why we're beginning to outsource some of our more bandwidth-intensive services. In short, we don't foresee our resources (network, hardware, and otherwise) growing any time soon, but we do see that we'll be expected to increase the quality of our services and will be serving more users than ever in the near future.