First impressions of Measure Map from Adaptive Path

I got my invitation a few days ago to try out the alpha release of Measure Map, the blog stats service from the folks over at Adapative Path. After a few days of using it, I’m generally impressed. The quickest (but also crudest) way I can think of to describe the service is WebSideStory’s Hitbox or Omniture Site Catalyst for bloggers, since (like Measure Map) both of these services leverage the placement of Javascript code in a site’s pages to deliver reporting, freeing sites from the laborious crunching of log files, filtering out spider/robot traffic, and the many other annoyances of old-school methods of traffic reporting on the web. That being said, even if WebSideStory or Omniture decided to create a blogger offering, you can bet it wouldn’t be as simple, elegant, and useful as Measure Map. Even though it’s alpha, it looks like they’re building the right half of a product, but not a half-assed product. The tag line is “get to know your blog,” and that’s what Measure Maps is already helping me do.

Setup was easy for WordPress. I have no problem editing my templates based on rudimentary written instructions, but I still appreciated the clear visual guidance the Adaptive Path folks give in their instructions. Here’s an example:

Measure Map template editing

Almost immediately, the numbers started rolling in, and I found myself checking my Measure Map stats as often as I had grown accustomed to checking my Feedburner stats (incidentally, I consider these two services complementary at this point, since Measure Map measures non-RSS traffic, and Feedburner measures RSS traffic). Here’s a sample screen, the “Links” screen which tells me inbound links, outbound links (how else are you going to get that info without a bunch of ugly redirects and log crunching?), and search terms used to get to your site.

Measure Map links screen

The outbound links tracking is cool because it includes everything on your blog page, so you can see exactly which photos people are clicking on your Flickr badge, for example. The search terms section lets you know what words people are using to find you on search engines. Like everything else in Measure Map, the information is updated fairly instantly as activity occurs on your site.

Other stats I quickly learned:

  • the browser breakdown for my blog (58% Firefox, 26% IE, 12% Safari, 4% “other”)
  • the geographical distribution of visitors (73% U.S., 5% UK, 5% Canada, 5% Australia, 4% India, the rest spread among 12 other countries)
  • peak usage times (7-9am, 1pm, 5pm)
  • My top 10 posts (#1 is “Super-mashup with Yahoo! APIs: event browser“)

Bottom line: though only in alpha, Measure Map is already quite useful to me. Only one significant glaring hole that I noticed in the materials: no mention of an API on the Measure Map alpha status page under “feature set”: We’ve got a few great features coming soon, including stats for your RSS feed, tracking interesting events in your stats, and deeper tools for understanding search engine traffic. This might very well be on the way, but it would be nice to see it explicitly mentioned. After all, the service itself is being developed on top of some sort of API — why not start surfacing it early? It would be great to be able to do some remixing with the Feedburner API, for example.

Update (for those of you who don’t keep up with the comments): Jeff Veen from Adaptive Path writes: “We’re already working with Feedburner, with the intent of hooking your accounts together and merging the stats. Also, our first peek at a public API will be coming very soon now.”

Term Extraction API and TagCloud.com

One of the most inspiring backend pieces of the Event Browser for me was the innovative use of the Content Analysis Term Extraction API, which Ed describes in his post about the Event Browser:

One of the problems we had were that there were no images in our event feed. We knew we wanted to get images from either Flickr or Yahoo Image Search but it wasn’t immediately obvious how we would get an image from a phrase like “Highlights of the Textiles Permanent Collection at the MH De Young Memorial Museum”. It was another Yahoo, Toby Elliott, who suggested that we use the Content Analysis API and then Image Search. Honestly, I didn’t even know Yahoo had term extraction as a public API. To get the images you see in the demo I concatenate the title and venue to get the most important terms extracted and then use that as the image query. The first thumbnail gets used as the photo for each event. It’s really simple code on my end and all the real work is done by the term extraction service. My favorite example for images is the De Young Museum’s list of events.

I’m a total news and politics junkie (when I worked at CNN.com several years ago, it was like giving an alcoholic a job in a liquor store), so last week I started thinking about how using a tag cloud to represent breaking news from a set of RSS feeds that I choose. Last week being a big news week, I envisioned a dynamic tag cloud where words like “Scooter,” “Miers,” and “indictment” would get huge in breaking news situations to tip me off that something big was going on at that moment.

I started digging around and was getting ready to sit down and write the code, but then I found TagCloud.com, which uses (you guessed it) the Yahoo! Term Extraction API to produce a tag cloud built from RSS feeds you specify in an interface that is nicer than anything I could build quickly myself. No need to re-invent the wheel, so I signed up and had my tag cloud in a few minutes, using these feeds: CNN.com Top News, Fox News (to be fair and balanced), MSNBC, NY Times home page, Washington Post top news, and Yahoo! Top News.

Here is the resulting tag cloud from those sources. TagCloud.com offers a nice “stop words” feature so you can remove common (but useless) words from the tag cloud display. I specified “full story” and “story” as stop words, for example, but I also specified “white” and “supreme” because they were generally represented in the phrases “white house” and “supreme court” (terms which were preserved in the tag cloud even though I specified words within those phrases as stop words). (And check out their implementation guide for simple instructions on how to put your TagClouds on your site in badge form).

Displaying this tag cloud more dynamically in a Konfabulator widget would be cool. . . . TagCloud.com has already done the difficult work using the Term Extraction API, perhaps the most underappreciated API in the Yahoo! API arsenal. Sounds like a fun project.

Flock and WebOS

Now that I have Flock, I decided to test it out a little.  My first task, of course, was trying to post to my blog.  That’s what you’re seeing here (please forgive some of the wonky formatting).  I was hoping that the blog tool would allow for offline posting a la ecto, but that doesn’t appear to work.  When I tried to save a draft with no network connection (I turned off my wireless card and pulled my network cable for fun), the app went into a tailspin.  This inability to save locally in what is essentially an extension of the Firefox browser reminded me of Jason Kottke’s post about the WebOS way back in August.

Flock is perhaps the quintessential Web 2.0 company (technology and hype included), but after ten minutes with the application and some reflection on Kottke’s WebOS post, I think Flock could be more than simply “a Web 2.0 on-ramp” (as Kris Krug of Bryght calls it in this Wired story).  I think Flock might be thinking WebOS. From Kottke’s WebOS post:

So this is my best guess as to how an “operating system” based on the Web (which I will refer to as “WebOS”) will work. There are three main parts to the system:

  • The Web browser (along with other browser-ish applications like Konfabulator) becomes the primary application interface through which the user views content, performs services, and manages data on their
    local machine and on the Web, often without even knowing the difference. Something like Firefox, Safari, or IE…ideally browser agnostic.
  • Web applications of the sort we’re all familiar with: Gmail, Flickr, and Bloglines, as well as other applications that are making the Web an ever richer environment for getting stuff done. (And ideally
    all Ajaxed up to provide an experience closer to that of traditional desktop apps.)
  • A local Web server to handle the data delivery and content display from the local machine to the browser. This local server will likely be highly optimized for its task, but would be capable of running locally installed Web applications (e.g. a local copy of Gmail and all its associated data).

That’s it. Aside from the browser and the Web server, applications will be written for the WebOS and won’t be specific to Windows, OS X, or Linux. This is also completely feasible, I think, for organizations like Google, Yahoo, Apple, Microsoft, or the Mozilla Foundation to make happen (more on this below).

“Something like Firefox, Safari, or IE.”  “Web applications of the sort we’re all familiar with.”  “Won’t be specific to Windows, OS X, or Linux.” Pretty close to what Flock encapsulates.  The only area where Flock completely misses is the third point (basically running locally without loss of features), which is understandable given the constraints of current browser technology and the fact that Flock is a “developer preview.” I would still love to be able to save a draft blog post locally using Flock while disconnected on a plane, though.

Going back in the time machine to Kottke’s oh-so-long-ago post in August, he asks, “So who’s going to build these WebOS applications? Hopefully anyone with XHTML/JavaScript/CSS skills, but that depends on how open the platform is. And that depends on whose platform it is. Right now, there are five organizations who are or could be moving in this direction.”

Aside from the usual suspects (including my employer, where we are definitely doing lots of cool things as the post suggests), Kottke lists the Mozilla Foundation:

This is the most unlikely option, but also the most interesting one. If Mozilla could leverage the rapidly increasing user base of Firefox and start bundling a small Web server with it, then you’ve got the beginnings of a WebOS that’s open source and for which anyone, including Microsoft, Google, Yahoo, and anyone with JavaScript chops, could write applications. To market it, they could refer to the whole shebang as a new kind of Web browser, something that sets it apart from IE, a true “next generation” browser capable of running applications no matter where you are or what computer (or portable device) you’re using.

Flock isn’t the Mozilla Foundation and they are “completely independent,” but reading Flock CEO’s Bart Decrem post about how Flock will create “sustainable value” (the answer to all the what is your business model? questions) gives me pause. If you replace Mozilla with Flock in the Kottke quote above you might be tempted to think that Flock is working towards something a lot bigger than a cute Web 2.0 browser. Besides, who needs another browser anyway?

And who needed another search engine?

Want Akismet? Then download Flock. Huh?

(Note on 11/10/05: getting the API key was mildly painful, but Akismet is doing an EXCELLENT job of catching spam. I have zero problems now — it was well worth it!)

I ran across a mention of Akismet, the WordPress spam blocker, on the BusinessWeek blog and since I’ve been seeing a bit more spam these days, I decided to try it out. WordPress has been good to me, and this sounded like just the thing I needed to make my experience almost perfect.

I clicked over to the Akismet site, and see “Akismet is free for personal use.” Looked good. “All you need to start using it today is a WordPress.com API key. Sign up on WordPress.com to get an API key.” No big deal — I sign up for API keys all the time.

I followed the “Sign up on WordPress.com to get an API key” link over to WordPress.com and saw this message: “Want WordPress.com? Then download Flock. . . .”

want wordpress? download flock

Huh? I just want an API key so I can try out Akismet and I followed a link that promised me just that. What does Flock have to do with this? Why should I have to download Flock?

Frustrated, I downloaded Flock, but it was guesswork from there on how to get an API key. I clicked around on the “Five ways to. . .get started” on the Flock startup page (with the Flock app) and chose #2, “. . . get yourself a blog.”

five ways

I was presented with three choices: WordPress, TypePad, and Blogger. I chose the WordPress link and filled in the requisite information (note that “chad” was taken, so I used “chaddickerson,” but didn’t do another screen shot).

wordpress signup

At that point, I got an e-mail with my username and password to login to my WordPress.com blog. Yay. So I logged in to my WordPress.com blog, still not sure where this elusive API key existed. Randomly, I clicked around until I clicked on “Profile” in the main admin menu. And there it was! My API key!

WP API key

This process makes almost zero sense. I expected a lot more from WordPress, and getting siphoned through Flock to get an API key smacks of some backroom arm-twisting marketing deal. Getting an API key has never been so convoluted.

Fortunately, installing the Akismet plugin was as easy as any other WP plugin and I got it installed in a couple of minutes. I entered the API key with no problem. Whew. Now I’ll see how Akismet works.

Oddly enough, it wasn’t until the plugin was installed that I came across a reasonable link about the API key, found on the plugin manager page (yes, it’s a little hard to see below):

plugin manager

For those who don’t want to go through the aggravation I just did, here’s the text:

Akismet checks your comments against the Akismet web serivce to see if they look like spam or not. You need a WordPress.com API key to use this service. You can review the spam it catches under “Manage” and it automatically deletes old spam after 15 days. Hat tip: Michael Hampton and Chris J. Davis for help with the plugin.

What a strange process. I sure would like to know the thought process that went into it, because I certainly can’t make any sense of the actual process.

Update: Michael Hampton responds in the comments, and this post makes things clearer:

Last week I told you all about Automattic Spam Stopper, the new anti-spam solution for WordPress from Matt Mullenweg. There’s been some new news, and you’re going to hear it here first.

First off, the plugin has been renamed to Automattic Kismet, or Akismet for short.

Second, it now requires a WordPress.com API key, which you can find on your WordPress.com Profile page. (Click My Dashboard, then Profile.) If you don’t have a WordPress.com account, you won’t be able to use Akismet at this time, until you somehow finagle yourself an account. The fastest way is probably to use Flock. You don’t actually have to blog at WordPress.com to use Akismet, you just need the account to get the API key. You can use the API key at more than one blog, too.

Adium rocks!

Quack! Tim wasn’t kidding — Adium for OS X (based on Gaim) is awesome. I had been using iChat on my OS X box at home until I picked up a bunch of Yahoo! Instant Messenger pals in my new job. I tried Fire for a few weeks, but it left me cold. Honestly, I never really liked iChat that much either, even after exhaustively going through its preferences and stripping it down interface-wise as much as possible (getting rid of the text bubbles, the sounds, etc.)

That being said, I hadn’t spent any time looking for alternatives, but two minutes after reading Tim’s post, I was up and running with Adium. Easy switch, and totally worth it, though I recommend disabling the sound effects immediately — I jumped out of my seat when the first IM came through with a loud “QUACK!”

iChat and Fire are both gone from my dock now.

Backing up a Mac with rsync

If you want to avoid using all the goofy backup software that come with firewire drives these days, but you haven’t gotten around to reviewing the rsync man page and you’re starting to get a little worried about your backup situation on your Mac, this is the page for you. Rsync has always been a mainstay in my tools arsenal, but mostly on Linux and Solaris. This set of detailed instructions will clear any rsync cobwebs quickly, and throws in a few Mac-specific details to boot. I’m running my backup now. . . . looking good.