Saturday, February 22, 2014

The new Iditarod tracker and user experience ("UX")

First, I'd like to apologize for not blogging much over here.  I've been extremely busy with work (that's a good thing, mostly) and have found that keeping a Facebook page is a handy way to get out short notes.  The Facebook page is here.

Anyway, Iditarod's new tracker is up and being used to track the Junior Iditarod.  It's pretty clear that they've written their own based on a data feed from Trackleaders, and it's also pretty clear that they didn't have time or the means to debug it.  Software quality assurance is much more difficult than you might think.  One common problem is that commercial-grade software needs to handle unexpected inputs gracefully.  It is an ongoing source of amazement what people will try to do with something, things you never could have expected and didn't plan for.  When people in the techie business say "The first 80% of the project takes 80% of the effort, and the last 20% of the project takes the other 80% of the effort," that's nearly always what they're talking about - quality assurance.  People who haven't done a lot of commercial software tend not to appreciate this and think that when a program does what they want it to, they're done.  Not sure what to say about that other than "Hah."

Anyway, rather than dwell on bugs I'd like to talk for a minute about user interface issues.  User interface is also a very highly specialized area in software.  It's something at which I am truly terrible, so I rely on people who understand user behavior, workflows, and so on.  But in this case I am a user and here's what I'm finding:

  • Some of the things which work well for a 9-team field are going to be nearly unbearable when there are nearly 70 teams being tracked
  • First, good for them for making the columns sortable in the leaderboard (the panel on the left-hand side of the map).  It's helpful, and it's going to be absolutely necessary when there are 60-odd teams on the trail
  • Too much clutter on the screen, and it covers up portions of the map.  Unfortunately because of a few other problems with the user interface we kind of need to keep some of it around (the leaderboard)
  • The base map layer is not a good choice.  I understand that this is what Mapbox provides but the lack of labels on geographic features is unfortunate.  It would be nice to have the option to switch between a map layer and a satellite image layer (a topo layer would be awesome but I understand it's a lot more difficult to come by - another plus for Trackleaders).  On a more positive note, today Iditarod switched from showing the road map layer to showing a terrain map layer.  It makes it easier to compare to a topo map, plus - let's face it - using a road map to track a wilderness race is kind of dumb
  • We can't zoom out to cover a larger geographic area.  Can't imagine why not unless it costs them money (does Mapbox charge for tile access?  Don't know).
  • They need to get a handle on this whole "rest" thing.  I'm very interested in run/rest schedules (you should be, too!  They're a key question in understanding distance dogsled races) and a 10-minute stop for snacks or to check booties is not at all the same thing as a 4-hour break.  Also, it's probably a mistake to display a musher as having stopped the same as a tracker that hasn't updated.  It doesn't help that a single 0mph reading is treated as stopped, because it means that they're also showing a single missed tracker update as stopped
  • If you hover over a flag on the map it gives you the geographic coordinates of that tracker update.  I assume they did that for debugging purposes, but for those of us following the race it would be a big improvement if they showed the musher's name, instead.  Right now you need to go back to the leaderboard to find who a given bib number belongs to.  That's going to suck when there are 69 teams on the trail.
  • I'm having a hard time calling their analytics "analytics," since they don't provide that much insight into what's going on on the trail.  I keep hammering on this because I think it's important: the competitive advantage that Trackleaders brings to the event tracking business is that they know how to tell a story using data.  Teams on the trail aren't simply moving down a line, they're also moving relative to one another, and that movement is much of the story of a race.  Who's traveling together?  Who's passing whom, and where is it happening? How much faster *is* one team traveling than another, really? Is there one particular spot on the trail that's a popular camping site?  I get the impression that the folks working for IonEarth were pressured by Iditarod to provide analytics and found a Javascript library containing strip charts so implemented that, without thinking very hard about what they want to show.  Now, Iditarod is copying that.
  • Here's one thing the Iditarod analytics do do well: by mapping speed against time they give you some insight into a particular musher's run/rest schedule.
  • It's great that they let you get a musher's "analytics" directly from the leaderboard but it's kind of a clutzy process.  I usually start by noticing something on the map I'd like to look at more closely.  In this case, what we see on the map is bib numbers.  So you need to go over to the leaderboard (open it up if you've closed it to mimimize clutter), find the bib number, then click on that person's analytics icon.  It'd be a lot more straightforward to be able to go from the map marker directly to the "analytics."
  • Another clutter-related issue is that because the pop-ups don't close when you open another, you can get a mess pretty quickly.  Unfortunately closing them can be a little hit-and-miss with your mouse.  Anyway, your moment of fugly:

  • They're not really strong on the mileage reporting and while the analytics show speed against time there's really no easy way to compare how two teams performed over the same section of trail
Anyway, enough kvetching.  When you're in the software business and when you're an engineer, your first instincts when facing new technologies are 1) to figure out how it works, and 2) to figure out how to make it better.  Alas, this tracker is giving us plenty of opportunities for the latter.  But ultimately what matters is how it works when put to some basic tests, and in a couple of future posts I'll look at how to answer certain kinds of questions using this software.

No comments:

Post a Comment