About a year ago, I wrote a feature for Jira during my 20% time that shipped in Jira 5.1. This feature notifies a user if their current time zone (as detected by their browser) doesn’t match the time zone they’ve set in their user preferences.
Part of the reason I wrote the time zone detection plugin was that, although the time zone setting for users was the headline feature of Jira 4.4, I didn’t think it was obvious enough to those users who don’t read the release notes or marketing blogs. This meant there might be a significant number of users who were frustrated that Jira wasn’t displaying times and dates that were meaningful to them, without realizing that they could change the setting.
Out of curiosity, just before my plugin went live on our primary customer-facing Jira instance (jira.atlassian.com), I got some anonymous database stats from the server about how many users had set their time zones.
Now, one year later, jira.atlassian.com is running Jira 6.0 and I got the same (completely anonymous) user stats as before to see if the plugin made a difference. Survey says? It sure did.
Stats and graphs and rock ‘n’ roll
JAC was upgraded to Jira 4.4 (and therefore got time zone support) in July 2011. In the 11-ish months between then and its upgrade to 5.1 (with the time zone detection plugin), only 483 users (0.66 percent) had set their time zone. Of these users, over 20 percent were in Sydney, and most likely Atlassian staff.
As of my recent data collection, 8,339 users (8.4 percent) have a custom time zone. In raw numbers it’s a 7,856 individual user increase, or 16 times the previous count.
Some numbers:
| A year ago |
Now | |
|---|---|---|
| Active users | 73,493 | 99,296 |
| Users with a custom time zone | 483 (0.66%) | 8,339 (8.4%) |
| New users since data was collected last year | 25,803 | |
| New users with a custom time zone | 2,259 (8.75%) | |
| Existing users with a custom time zone | 6,080 |
For those who prefer numbers in shiny graph form…
So what does this mean? Firstly it reaffirms that feature discovery is important. Users on our primary public Jira instance running 5.0 hadn’t realized that they’d been able to change their time zone for two major release cycles. But as soon as they had a simple, obvious, one-click solution to set that preference, more than 6,000 of those existing users used the feature.
But wait!
How do we know that the users weren’t just setting it manually? Was it just a coincidence of timing? No, and here’s why:
The plugin uses the open source JS Timezone Detect library to do an in-browser “best guess” about the user’s time zone. Therefore, anyone in Western Europe in the GMT+1 time zone (GMT+2 in summer) gets their time zone detected as “Europe/Berlin” — it’s not 100 percent geographically accurate, but the relative times are the same, so there’s no real user impact (unless there are geo-political aspects to the situation).
Looking at the database again, what’s the most-used time zone? “Europe/Berlin,” by quite a margin. It accounts for 91 percent of all European GMT+1 time zone preferences (2,283 out of 2,503 users, for the record).
A similar pattern occurs for various other time zone bands that are detected by the plugin (Europe/London, Europe/Helsinki, America/New_York, America/Los_Angeles, etc). This gives me confidence enough to declare…
The big takeaway
A simple banner resulted in a 16-fold uptake of the user time zone feature on our biggest Jira instance. Amazing what a little feature discovery can do.
Caveats, retorts, etc.
“OK, all this work for a simple thing like a set-once user preference. What’s the big deal?”
Simply put, users care. It’s also just a simple friction point. I know I find using sites or apps frustrating when all my activity is listed in a US time zone that has no relevance for me in Sydney.
“Well, that’s just one Jira instance and one data point. Can you really claim success?”
Fair point, although it is certainly our most high-profile instance (flagship instance, some might say), with a wide range of users in locations all around the world.
“Why are you asking questions of yourself while pretending to be the voice of other people?”
Because I can, and it breaks up the wall of text a little.
What’s next
In true developer style, I’m still not completely happy with the plugin and want to do some more work on it. But it’s always good to know that a feature written as a small 20% project can have a valuable impact.