Punishing the Subscriber, Slowing the Server: Ancestry.com

(Repost from my interface blog, May 2011)

I have been spending a LOT of time on Ancestry.com lately.  It is, I’m pretty sure, a fantastic set of data, but it keeps itself carefully hidden behind an interface that seems designed to frustrate the subscriber at every turn.  In many ways, I feel like I was able to find information more efficiently when I wasn’t a subscriber - and that’s just wrong.

There are 2 main areas where Ancestry misses the mark: workflow and search.  These are both big, gaping, hard-to-avoid areas.  So consider this my UI review, on behalf of Ancestry subscribers everywhere . . . .

Workflow

When you're getting started in Ancestry.com, the most common activity is building out your family tree.  You start with a grandparent or someone, and work your way back, usually getting help along the way through their 'hints' mechanism.  Once you add a person, you can see if they have 'hints' from Ancestry, which are links to data, sources, and other family tree information you can add to the data for that individual.  If a person has hints, they get a little leaf on your slowly rendering tree.  Then you can hover over an individual, see the number of hints they have, and click to see the list.  Here is a screen shot:

The workflow for that person then begins.  But as it is currently structured, the addition of Col. Ball to a family tree will take approximately half an hour.  Multiply that by the thousand or so people in a family tree, and you have a terribly punishing process for the user.  Consider that the process is also not Web 2.0 in any way, but takes dozens of slow trots back to the server for complex rendering and rerendering of data, and you have a process that is painful for the server as well.

Here is the diagram of the process:

Two easy changes would make this a 5 minute process instead of a 30 minute one:

1.  Allow bulk acceptance of hints, or acceptance without having to render and review each individual hint.  While you want to make sure that your sources are correct, there are some sources that you don't have to render individually.

2. Allow access to an individual's record without rerendering the entire family tree.

I have a 50 Mbps connection, so it's not as if the rendering slowness is the fault of my pipe. 

Ancestry has the advantage of being a bit of a Goliath, in terms of the data it has.  So most people who really want to get to the answers about their family tree have to subscribe to Ancestry at some point.  But many, like me, may be feeling trapped and frustrated by the arduous nature of their interface.  And I'm sure there are techies in their offices at Ancestry scratching their heads to figure out how to make the servers faster and the site lighter to render. 

It is somehow more frustrating when the same fix would solve the problems of both groups.  This happens throughout complex web application implementations, and these slight workflow changes are often easy to fix if the internal folks would step back and see the workflow from the user's point-of-view.

Next time, I'll take a look at the second issue - search.