I finally got my Yahoo! Go on this week, when the client for my Samsung Blackjack became available. I had been watching this project because it's one of the more ambitious mobile initiatives in a long time. You wouldn't know from the press coverage, but that's because it's in the middle of the land of purple, a giant doing everything and nothing, well and badly, all at the same time.
Let's pass over Y! Go's features and design for a sec. In terms of software architecture, we're looking at a smart client app: its content and features are network-oriented (mail, flickr, search), but it also runs offline, saves stuff locally to make that work, and masks fluctuating data rates and request latency under a locally controlled UI.
It's effectively got an embedded web browser (although it looks like page transcoding is happening on the server side, to save bandwidth and reduce complexity on the phone) and server-side support for viewing PDF, Microsoft Office documents, HTML email, etc. This strategy is a lot like the Blackberry's server-side translation, with the exception that Yahoo's actually works.
So Yahoo has basically built a 1990s-era AOL client, a monolithic app that provides a controlled experience and mediates access to the Internet. And they've built it on at least four platforms (Windows Mobile, Symbian, J2ME BlackberryOS, J2ME/MIDP vanilla) with countless versions and quirks. Which is why even versions for "similar" phones have trickled out over the course of months.
Why would Yahoo do an AOL? Because they want to take over the world with their platform, and control where users go? Nope. They did it because they didn't have a whole lot of choice. The phone development platforms remain extraordinarily fragmented across OS, API, version, and hardware install (!), and the carriers are more of a hindrance than a help. The worst part is that within six months there will be enough new devices and OS changes that the entire QA cycle and maybe even dev will have to be at full throttle just to keep this app viable.
Most likely, the original mission was to bring Yahoo to mobiles in a more consistent and usable way than the old mobile web site. And most likely they looked at mobile web options before realizing that those would require nearly as much customization for different devices as rolling their own app (plus mobile web would lack critical offline/low-data-rate functionality). So they did what everyone has to do: build their own native application to serve as platform and abstraction layer over the other APIs.
Who wins in this scenario? It's not the Yahoos, Microsofts, or Googles, who would rather not rebuild, test, and maintain the same app over and over. It's not startups, who kill themselves trying what only GYM can really afford to do. It's not the carriers, who want to increase revenue per sub by selling data plans, and who need compelling network-intensive apps to do that. And it's probably not the hardware folks, who don't care too much what's happening four levels up the software stack.
No one wins this game of 52 Pickup. It creates "small value" in the short term, while stifling "big value" in the long term, the same way a tornado wrecking a town brings a bunch of contracting and insurance dollars in the short term, but doesn't make the town a creator of value in the long term, the way building infrastructure like fiber-to-the-curb, or a decent university extension campus might.
I built a push-mail system in Perl in 1998, the same year RIM started shipping the precursor to the Blackberry, and I started reading my Yahoo mail on my phone in 2000 via WAP. So we're nearly at 10 years of mobile productivity apps and the trend is still toward more chaos rather than less. So... how can we reign this in, hopefully still preserving some biodiversity in phone DNA at the same time?
No comments:
Post a Comment