Microsoft has announced that Windows Longhorn’s official name is Windows Vista, and they’ve put up their own website to prove it.
There are worse names that we could have to endure over and over again for the next 10 years.
‘Windows Vista’ is boring, but it can mean whatever Microsoft wants it to mean, forever. There are already a number of taglines about things like “cutting through the clutter and focusing on what’s important to you.” Some time next year, the real marketing, with flashy videos of icons and windows and transparency, will tell you that you really want Microsoft’s vision of the future to move in with you. You’ll want it in your kitchen. And then when you have it, you’ll eventually lose a document you were working on, curse, and tell it to stop smirking at you. Same as it ever was.
This weekend I went on a road trip with Drewstew and Adam to the Sierra Mountains between Yosemite and Sequoia national parks. It’s about a 4 hour 47 minute drive if you ask Google Maps. We played cards (betting with macaroni), swam in a creek, listened to iPod music, drank a little, made a campfire, and generally chilled for the whole weekend. Couldn’t have been much more relaxing. Hot in!
Joseph Scott talks about API Only Services and whether it would be possible to have a really specialized API that wouldn’t have a web application of its own. I love that people are exposing more and more APIs to get to the data on their sites that otherwise would have to be painfully screen-scraped to be useful to other web sites, but I would suggest an alternative path to building good APIs from here on out.
Start with your API, then build your website as the first client. Launch the site and the API at the same time. They’re the same. The things people get from screen-scraping and regular expressions and faking form submissions on day 1 of the website should be the same things that you give people a reliable way to get at with the API on day 1 of the website.
If I were building a service like Flickr, Google Maps, or Odeo (and I would guess that these sites had a good part of this strategy in mind when they built them), I’d start with the API, then use it and make sure it has everything I need to build my site. If you gate things for yourself through your API, it will be your top priority. But if you write features for the site first and ever think, “someday, I’ll add that to the API,” it will always lag behind.
As an example, pretend I were starting a website to provide a service to tell people what you’re wearing every single day. Clothes-blogging. Let’s call it favoriteshirt.com (hey! looks like it’s for sale). I write the API (”okay, tell us the names of what you’re wearing today, and in what colors, maybe give us a photo of you in the mirror, and here’s a list of what you’ve worn this week, and here’s a list of what your friends wore yesterday”). Then I use it to build my website. When I do it, you have to enter the names of what you’re wearing in textboxes, and I can only get pictures of the clothes from Amazon, so that’s the output. But seeing what your friends wore is pretty cool, right? When I launch my website, I launch the API. Somebody writes a program to figure out from a picture what you’re wearing and send it through the API, and that goes on their website. Somebody else does 3D models as output. Somebody else maps what city wears the most expensive designer jeans. All of a sudden, I have so much content that I don’t know what to do with it. I could start my own brand of T-Shirts and I’d get enough traffic to make a profit selling them. That’s the power of an API, and my little website started with one right away.
There’s a good exercise. Write a plan for a startup in 15 minutes. Very fun.
Ever wondered how far you just walked? It turns out that my walk to the bus stop is about .49 miles according to the Google Maps Pedometor that someone built using the Google Maps API, and the walk after work to go visit my friends in Pacific Heights is about 1.37 miles. With the hills, not such bad exercise if you ask me.
