watching the firefox 3.1 beta 3 release on social media networks
by Christopher Blizzard
At Mozilla we do a lot of releases. Every few weeks, we’ll do a minor release to fix security issues and improve the reliability of the browser. On the 3.0 branch, for example, we’re up to Firefox 3.0.7. 7 releases in 9 months is a pretty blistering pace. For a long time we were also doing releases of Firefox 2 in parallel with Firefox 3. Oh, and we were pushing out an occasional alpha or beta release of Firefox 3.1 (soon to be 3.5) too. If there’s one thing we do at Mozilla it’s get software out the door.
One of the things that we do when we do a release is try to have a “canonical url” for each release. For major releases, it’s like the url above – a mozilla.com release page. But for the betas we usually have a post ready in our Mozilla Developer News Weblog. For the new Firefox 3.1 Beta 3 release, we had a post ready ahead of time and knew what the URL would be.
But ahead of this release one of the things I did was to set up a short url on bit.ly for the release. One of the nice things about bit.ly is that it lets you track information as people click through the url. You can see people clicking through the short link for our release at the associated info url for that particular short url. This is what it looked like a little while after the release:
The data flow is a little flaky and I hate that it goes from live to past week (2 hours to daily is a pretty rough transition) but it’s great to be able to see the effect that particular posts can have on the traffic. It’s also interesting to see the traffic sources in the graph as well. It gives you a good sense of where people are reading information and generating click through traffic.
What’s really interesting is that you can take the bit.ly url and use it to track posts on twitter by using twitter search. Here’s what I found after coming back from dinner last evening:
This was after a post from the @mozillafirefox account which has about 14,000 followers or so.
Search also lets you follow what people’s reactions are as well. In our case we’re using the #firefoxbeta tag to follow what people are saying. I’ve been able to interact with some people about their experiences with add-ons compatibility and problems they have had with the release. (Surprisingly few problems, actually.) But mostly it’s just fun to watch people talk about how fast this release is when they actually use it.
Tools like twitter search have also let Mozilla set up the Release Rapid Response Team (RRRT). This small team of people collects information from twitter, identi.ca, facebook, weblogs and other places and raises common issues for our development and support teams to look at. As an example, here’s the RRRT list for Firefox 3.0.7. (Yep, it’s a short list but that’s a pretty good sign.)
It’s great being able to passively listen or interact directly with people on the product and I think it’s part of a sea change in search, social networks and product support. It’s going to close the gap between comsumers/users and the people who produce those products. And I also personally believe that it’s going to require that companies be more authentic in the way that they operate. Not only can companies see what users are doing in real time, consumers can also see what companies are doing as well. The transparency is two-way.
At Mozilla we’ve found ways to adapt and turn it into something that’s really useful. I wonder what other projects + companies are doing with these new tools?
I think we could do a better job of having a “canonical URL” for beta releases.
At least on delicious, most people link to the all-beta page, since it’s pretty and has a prominent download link. But that page doesn’t do a great job of telling you what’s new or what to be careful about.
Then there’s the devnews post, which tells people to link to it but is much less inviting. It’s a bunch of text, most of which is irrelevant to many beta users. It emphasizes warnings in too many ways, which ends up annoying me more than drawing my attention to them. And it tries to encourage users to read the release notes, which as even longer and lower signal-to-noise.
Then the devnews post is replicated on the Mozilla Blog, so there are *two* non-inviting pages telling people to link only to them.
> Then the devnews post is replicated on the Mozilla Blog, so there are *two* non-inviting pages telling people to link only to them.
I find this weird too, the Mozilla Blog usually dupes the info on Devnews, and doesn’t offer anything else useful.
I love these ideas… I remember when I worked in support (quite a long time ago) and I started creating daily emails on all suspected issues in a new release that was sent to all internal and external support staff. It greatly sped up identifying suspected issues, collecting info, and subsequently communicating workarounds and fixes following a release.
And these techniques are great as it allows you to get a handle on issues as quickly as possible, that perhaps weren’t directly reported (or reportable), and get a better idea of impact. A great benefit of mining social networks (that doesn’t involve trying to market something to me)