How to Plot an Address with the Yahoo Maps API

The Yahoo Maps API is powerful, but largely undocumented.

I’m guessing all the docs / marketing materials were written by developers and project managers, with little product management considered — because its damn near impossible to do the simplest things.

My needs weren’t intense , I merely wanted to do this:

– Include a map on a web page that plots an address

One would be amazed at how assbackwards the Yahoo and Google APIs are. Doing something simple like that is a complete PITA. Neither offer the ability to do that “out-of-the-box”.

At the end of this posting is a sample of code that will do this.

Before I get into that, I’ll talk about my learnings from fighting with APIs and a lack of documentation for over 3 hours.

The main issue I had was with the difference between an address and a geopoint. Yahoo will let you instantiate a map from an address, however placing markers must be done with a geopoint. The yahoo library is asynchronous — so when you render the map, it has no idea what the geopoint is… so you’ll need to leverage into their callback chain hooks to later derive the geopoint for the address , or mapcenter. Of course, none of this behavior is documented. Nor are any of the class methods documented in full.

I eventually came up with two possibilities:

– generate a map from an address, in a callback query the center geopoint & label it
– generate a geopoint from an address, in a callback draw the map and label it

I ended up going with the latter. here is the code

The great IE6 debate, make your business your perspective

The world’s least favorite browser, Internet Explorer 6 (IE6), is in the headlines again as a new “movement” of web developers seek to drop all support for it.

For those that are somehow unfamiliar with the situation, IE6 is the bastard offspring of Microsoft’s failed attempt at dominating the “browser wars” of the early 2000s. In an attempt to get developers to adopt the Microsoft way, the company decided to forgo industry standards and create their own. The plan failed. Miserably.

It also cost companies countless (and needless) dollars to support both the industry standards and Microsoft variations… and greatly stifled innovation and progress in user experience. Instead of developers moving forward in projects, they had to spend more time (and budgets) defining and testing IE6 compliance.

In a perfect world, undoubtedly, we would be without IE6. Like everyone else I loathe IE6. But, sadly, our world is far from perfect. It is, in fact, downright cruel. Microsoft not only gave [cursed] the world with IE6, but they also gave [shafted] us the inability to rid ourselves of it with ease.

Ay, there’s the rub.

IE6 is the latest supported Microsoft browser for the Windows NT 4, 98, 2000 and ME systems. Those systems can not run a more current Internet Explorer unless a costly Operating System upgrade is pursued.

On first thought one might think that a free option — like the [kickass] Mozilla Firefox browser would be an obvious option for these systems. Unfortunately these systems suffer from the next wound in our situation — much like later versions of Windows, like XP and 2003, they are often plagued with administrative security controls that complicate or completely prohibit upgrades and installations. A large number of these IE6 installs are what is termed “institutional” — large organizations that have Windows installed throughout entire departments, buildings, or companies. When operators of computers in these institutional situations do not have administrative rights to install software on their own, they can not install updates (SP/IE7) or free downloads (Firefox).

A few weeks ago, at a State Department Town Hall Meeting [ [news article]( ] a worker asked Secretary of State Hillary Clinton:

“Can you please let the staff use an alternative web browser called Firefox?”

The next two lines are very telling of the same exact situation that keeps IE6 around:

The answer is, at the moment: Its an expense question,” Kennedy said. Then someone in the audience pointed out that Firefox is free.

“Nothing is free,” Kennedy responded. “It’s a question of the resources to manage multiple systems. It is something we’;re looking at…It has to be administered. The patches have to be loaded. It may seem small, but when you’re running a worldwide operation and trying to push, as the Secretary rightly said, out FOBs [for remote log-ins] and other devices, you’re caught in the terrible bind of triage of trying to get the most out that you can, but knowing you can’t do everything at once.”

What people often forget, is that even free software and updates have integration and management costs associated with their installations. As organizations grow in size or their security needs grow in complexity, the integration costs for software deployment — free or not — grow as well. It’s worth mentioning that many companies have based significant portions of their revenue streams in providing professional services. In fact, it is not uncommon for Open Source companies like RedHat to offer software for free , while they charge for support and maintenance and vie for enterprise contracts.

The culmination of all this is that we’re stuck with IE6. For how long? Who knows… Much of this will probably depend on how hardware and software cycles through its usage period with institutions. It could conceivably stick around for months… but possibly linger for years. I worked on a contract in 2003 for a Fortune 100 company where rooms full of employees worked on Windows95 or earlier, some machines only had DOS screens.

In an effort to more quickly rid the world of IE6 , designers and developers have banded together to suggest ways of dropping support — ranging from blocking browsers to forcing upgrades. Discussions like this are dangerous and irresponsible.

Whether IE6 should or should not be supported is not a decision for a bunch of advocates to lead — it is something that every organization should decide on a per-project basis by carefully weighing their goals and audience metrics.

The overall market share of IE6 is estimated to be somewhere around 2% in 2009… but this number is only a global installation base, and not indicative of traffic. The number of IE6 visits to a particular site vary drastically by both site, topic, and userbase demographic.

Several consulting engagements I had in 2009 on high traffic content publication sites showed double-digits for IE6 visitors; one site had a whopping 24%, another 17%. A high-traffic financial services company I consulted with in 2008 factored in 32% of visitors on IE6 into their application design. A friend messaged me today, his high volume online shopping company averaged 14% of unique users on IE6.

Conversely, friends working on fancy Web2.0 interactive projects often showed 1% or less of IE6 visits. The social news site [released some numbers last month]( on their IE6 usage. Digg actually derived patterns by breaking their numbers down, and showed that 10% of visitors, 5% of page views and 1% of ‘transactions’ happened via the IE6 browser; Digg then announced that , based on these learnings, they would eventually phase out the support of ‘transactions’ while maintaining support on reading.

Suffice to say, IE6 impacts websites quite differently from one another.

Before getting into the details of dealing with IE6, let’s outline some points on why we all hate it:

– IE6 is not standards compliant, meaning that it renders differently than everything else and extra work must be taken to make simple things look halfway decent
– IE6 is bad technology
– IE6 is old technology
– IE6 stifles innovation from its limitations and necessary extra work

That’s out of the way. We agree. We don’t like it. Let’s hold hands. Rainbows.

But we have a problem… people still use IE6, and we can’t change that — even if we close ours eyes and wish real hard.

IE6 is very much like abortion – everyone agrees that they’re against it, they just fight over what to do about it.

The fight is largely drawn between those passionate about web development, and those concerned with business.

I’m an entrepreneur. I handle technology, operations and businessy things like marketing , product management, and PL sheets… so I approach this problem with that mindset, and say you need to be responsible, and address it properly. Don’t follow a movement blindly, be an adult — find out if you have a problem and deal with it.

The first step in dealing with a potential IE6 problem is to start looking at your site logs and marketing research for your demographic. Find out what systems your current users are using, what your market opportunity is, and what/where your projected growth is. Your current users may not use IE6, but your business operations are likely to scale to a significant number of users. On the flip side, you may have a huge percentage of IE6 visits now… but in 6 months your planned expansion will make that percentage tiny. The point is to look at the present and the future… uou might be surprised to learn that IE6 is simply not an issue for you, or that supporting it will make or break your project.

The second step is to remember that these are only numbers , and they may not tell the entire story and value of browsers to your project. By that, I mean that when looking at browser statistics, one must keep in mind what the purpose of their website is.

If a website is designed to generate revenue through advertising or shopping cart sales, dropping IE6 support could equate to dropping 15% of gross revenue. The question to ask then becomes: What is more costly – 15% of revenue, or the resources needed to make something IE6 compatible ? In most situations I’ve encountered, a 15% yearly revenue drop projected to cost far more than a few more weeks of design & development. Recent engagements I was involved in dealt with situations like this:

– $40k IE6 development retrofit when two year projections showed $3MM in lost potential revenue
– $8k in additional costs to build in IE6 support from the outset, when 6 month projections showed a difference in 30% difference in potential users based on marketing partnerships

Many websites aren’t designed for revenue generation — they’re a component of a marketing/advertising campaign. In these situations, the question becomes : What is more valuable – a larger audience, or a smaller audience with a richer experience ? In many situations I’ve been in, the smaller audience with a richer experience has been worth far more to the organization.

This isn’t to suggest that there are two only scenarios; there are thousands of possibilities, which is why IE6 support must be addressed on a per-project basis. Some web properties would require egregious amounts of capital to provide the same level of IE6 support, others would be wholly impossible to deliver a comparable experience with the browser.

The inability to factor in situations like there are why I refer to the anti-IE6 crowd as zealots, cultish , and often ignorant or idiotic — they’re unable to reconcile or even acknowledge significant IE6 usage or business importance , even when these numbers are starting them in the face or driving the revenue that pays their salaries.

Being costly to support, limiting, stifling-innovation, or being old-software aren’t valid reasons to drop browser support — they’re just motivations for rhetoric and dogma.

Web projects exist for one of two primary reasons:
– making money
– delivering an awesome experience

Most projects strive to achieve both, but one — and only one — can be the primary driving factor: a website is either a business or a hobby first and foremost, while the other reason is secondary.

If your project is a hobby and want to say “Screw IE6″… then sure, do it!

If you’re a business, weigh your options and think about the impact intelligently. Don’t think of movements. Don’t think of dogma. Think of dollars and cents.

If your goal is to make money, you need to decide on who/what your audience is — and if fostering a better relation with other uses is worth writing them off. This might be a viable concept, but unless you’re doing something aggressively web2.0 for that demographic, it probably won’t be.

Once you’ve realized the presence and extent of IE6 issues, think of smart ways to handle them. Remember that dealing with IE6 doesn’t mean that you do full support or full deny — but that you can tier user experience. Take cues from folks like [Toby Boudreaux of The Barbarian Group]( who suggests that you “can think of IE6 as a perfectly viable user agent for consuming content, but cost prohibitive for rendering top-tier experience design,” and “understand the complexities facing the people your cocky designers and lazy developers want to patronize or abandon”.

Also remember that if you are in fact a business, your design and development teams (both in house and vendors) are often completely clueless about your operations and goals. You should always listen to them about web stuff — they know their areas well (that’s why you hired them!). But remember that they work for you, and if your business needs to support certain products or experiences for specific demographics, it’s their job to get it done — and that’s a job that you can easily give to someone else.

You may also remind them, politely, that the 15% drop in revenue they suggest your company make for their cause correlates very well with what your company spends on their salaries and benefits.

Finally, remember that the costs for retrofitting support and designing with it at the outset can be extremely different as well. A recent retrofit I was involved with, in which IE6 was discounted at the outset of the project, took 8 weeks of development time to achieve 2/3 of the functionality after launch. Had IE6 compatibility been decided before work began, the design, ux and development of the project would have proceeded more differently and cheaply.

The world would be a much better place without IE6. Developers and designers could do cooler things, sites would work faster, things would be more awesome, maybe even unicorns would return to the Earth again. A world without IE6 would really and truly be that amazing. But dropping support is simply not a viable or responsible business option in many situations — and this is something that developers and designers will have to deal with just as harshly as those who write the checks for all the extra time spent on support.