Yahoo! Widgets Team Breaks the Machine

To my non-technical readers, there's not much here for you to read that you'd be interested in. Please feel free to ignore this post.

Now, there are many ways I could have gone about this. I figure I should have left it discreet, between me and the Yahoo! Widgets team. Then I thought I should go one higher and talk to corporate, but they'd just refer me back down to the Widgets team and give me some PR spiel about how "each department handles consumer and developer complaints internally." After seeing that nothing was done after a week, I made a public post and took this post out of draft. So here goes, enjoy the ride.

Update 11/29/07: With the launch of Yahoo! Widgets 4.5, many of the issues described in this post have either been resolved or are in the works of being fixed. Thanks to Jonathan S. at Yahoo! Widgets for addressing and seeing that these issues are fixed.

On November 16th, Yahoo!'s Widget Team decided it'd be a good time to launch their new version of the Yahoo! Widgets site, and finally move away from the Konfabulator system they've been using since Yahoo! purchased the company years ago.

Based off the consumer and developer complaints (and I'll tell you there are many complaints), it's hard to imagine how a company like Yahoo! let it get this far.

We launched a widget for our client on the 6th of this month. Well, let me clarify that, we submitted it to their strange submission system on the 6th, where we waited another week until it was suddenly approved and posted the same day. The downloads were excellent and the client was happy. 5 days later we had over 1,300 downloads... on the old site. 1,300 downloads is an excellent number and there was much rejoicing.

So, on the 16th, Yahoo! Widgets began the excruciating process of what had to be the worst site rollouts I've ever seen in my 10+ year experience with the web. The site would appear and disappear throughout the day, switching between the old site and new site. The team claimed it was DNS propagation, whether it was propagation on their DNS servers or my single DNS server, who knows.

The new site had the downloads pegged at 259. (It still says that now as I post this.) You can imagine the e-mails we got when the client saw this download count, especially after telling their superiors that the downloads were over 1,300. Of course, you can imagine what everyone else (consumer-wise) thinks when they see the widget, only with 259 downloads, and goes "well, guess nobody liked that, I'll pass, thanks." When I alerted them to this on the 16th, they said they were aware of the issue. That was on the 16th.

I sent a message via their support form on the 20th explaining the issue, that my client was upset and I needed answers and information to give them. For those of you who don't work in the interactive industry, telling your client that you sent an e-mail and are waiting to hear back from them is never good enough. (Apparently Yahoo! doesn't believe in providing phone numbers for departments and brands, because that would make sense.)

Now, I have to explain to my client that going with the Yahoo! Widgets platform wasn't a mistake and that they shouldn't pull their marketing on this initiative because of some numbers that are under 300 for a widget that's been out for over a week. I have to answer e-mails explaining what the problem is, what it could be, when it might be fixed (apparently "later this week") -- a holiday weekend no less, and to sit tight. I have to say this as I grit my teeth.

On their developer forums, the following discussion took place:

"Could it be that nobody have reviewed the page before it gone online?" - Indiana

"A lot of people looked at the site before it went online. But, it's an extremely complex site with a lot of live data that's very difficult to simulate in a testing environment. So, we very much appreciate your feedback (and understanding). We're paying close attention to this thread and the comments on the blog, and you should see some changes showing up very soon and continued optimization as we move forward.

As I mentioned in the original announcement, this site is a work in progress. We migrated everything over to a totally new back-end and completely restructured the front-end interactions, both of which were gargantuan tasks performed by one individual apiece. We know the current site isn't perfect (and in our eyes, it probably never will be), but we made a conscious decision that there were diminishing marginal returns on continuing to improve the site behind closed doors and that the new functionality was at a point where we wanted to share it with the world.

One of the advantages of the new code base over the old one is that we can make changes much more easily and with less risk. So, please keep the feedback coming."
- Jonathan S. - one of "The Management"

Wow, I don't know where to start. Jonathan, perhaps it might have been a good idea to push off that second trip to NYC's Y! office while your team so obviously struggles to fix a site that clearly shouldn't have been launched in this fashion? I mean, come on, the other teams there at Yahoo! know to always have a beta site. Hell, the Music team had a beta site and it's been around for a while now. You've heard of a beta, right?

Now, I don't mean to sound like a snob or anything, but in the 3+ years I've been at my company already, we've never, ever launched a brand portal or microsite for our world-class (and Fortune 100) clients with the mind-boggling amount of embarrassing issues your Yahoo! Widget team is encountering, nor have we ever come close to it. But man, the comments and screencaps of the rendering issues, JavaScript issues, usability complaints and other oddities being posted on the widgets forums is amazing.

Here's a list of things the Yahoo! Widgets team apparently ignored or just glazed over:

• Launching a site with the very obvious amount of rendering and cross-browser inconsistencies being reported now. Minor inconsistencies are fine at launch, because they're... minor.


• Launching a site and relying on DNS propagation to complete while posting about it on the developer's blog before that propagation has completed. Again, why wasn't there some beta site. At least the propagation would have completed so an instant launch could be performed later.


• Launching such a significant overhaul, without a beta badge, touting it across the internets and then saying "we know the site isn't perfect." That's a no-no, no matter how big your company is.


• Claiming that lots of people tested the site and that you couldn't catch these errors inside a testing environment. That's absolute BS. Rendering issues only appeared outside the testing environment? How big was this environment, two Windows-based computers on the same connection?


• Not getting the biggest bugs (like the all-important download count that influences consumer decisions and marketing efforts) fixed within the first few days. It's been over a week, and the site still says 259 downloads.


• Not getting back to their developers (or my formal support request) in time. Piss-poor customer/developer service, check.

Sorry to take my gloves off Yahoo!, but you're not really leaving me any other choice.

Here's what I'd like to the Widgets team do once they get their cards in order, but understand if it's laughably ignored:

• First off, hide the download count on the widget pages since you obviously can't fix it in an acceptable amount of time. "If you can't get it to work, just hide it until you can." That's probably the most important "fix" a designer can do.


• Draft a written apology to anyone (developers/clients) who have been directly affected by this disaster of a website launch.


• Feature my client's widget on your homepage for at least a week, because it's much better than that bouncy ball you're featuring. Hey, it never hurts to suggest it/ask.


• Brush up on your public face with your developers, they're effectively saving your skin.


• Research the right way to deploy a global, public/consumer facing site before you try this again.


• Perhaps you should hire Arlo back. "Creative differences" aside, at least Arlo knew how to talk to developers and deal with problems.

That's all.