FamilySearch Developers Conference: Family Tree

A new release of FamilySearch Family Tree has probably been released by the time you read this, so I thought I'd report what I learned about it at the FamilySearch Developers Conference.

One nice thing about covering the 2009 BYU Family History Technology Workshop live last Thursday was not having to go back and try and write an article out of my cryptic notes. Since I didn't do that for the FamilySearch Developers Conference last Wednesday, I still owe you several reports.

After lunch Tim Cross and Jason Butterfield made a presentation about FamilySearch Family Tree. Tim is the product manager and Jason is the lead engineer.

Tim Cross

Tim mentioned that the team is thinking about making the various software components of Family Tree (developed using a computer language known as Flex) available to 3rd-party software developers. That would give 3rd-party developers a tremendous head start in producing web sites that tied into the pedigree database sometimes called Common Pedigree or New FamilySearch.

He also shared a slide with us that looked like this diagram. Tim told us that New FamilySearch, the "Classic" user interface, is used by about 20,000 different people each day, and they view about a million and three-quarter pages per day. By comparison, the new Family Tree user interface is used by very few people. One reason is that Family Tree doesn't have all the features that the Classic Client has. Tim's goal is to make using Family Tree so compelling that by November, the situation will be reversed, with most people using Family Tree and just a few still using the Classic Client.

There is an entire list of features that they know are necessary before that will happen:

1. Full temple experience
2. The ability to add, update, and delete information are some of the features added this week
3. A relationship column is needed for move records so one can make certain the move is right
4. Move history - See who keeps recombining the records you separate
5. Show possible duplicates that might need to be combined
6. Show side-by-side compare for evaluating possible duplicates
7. Give a mechanism to quickly combine multiple spouses, fathers, mothers, and siblings
8. "Un-reserve" or remove from temple list
9. A "What's Ready?" or "You've Got Names" feature to flag where temple work is needed on your pedigree
10. Provide the ability to login to Helper mode to assist another person

Tim mentioned that after #9 is implemented, flags or push-pins on the pedigree could be used to indicate all sorts of conditions that might need your attention, such as events that need sources, or possible record matches in Record Search. (No, he didn't say "shaky leaf." 

While not at this conference, Tim has been saying some new and interesting things at other conferences:

• For patrons bringing FORs from out of state, Idaho and Utah temples will soon be able to handle FORs. In other words, temples in the red zone are converting to NFS, even though NFS is not being rolled out to patrons. This is possible because a temple using NFS has the capability of accepting a TempleReady submission.

This explains the various, odd rumors going around that the Such-and-such Utah Temple is getting NFS even though family history centers and consultants aren't hearing anything about it. We had someone come into our Family History Center recently carrying cards printed from an FOR at the Provo Temple.

• The goal is to have NFS installed in all temples within 45 days, or about 1 May 2009.
• NFS will be released in the red zone by stake rather than by temple district.
• It will be released to 5 or 6 stakes a week. Then they will watch to see that the system is able to handle the additional users.
• They anticipate that by the end of the year, everyone will be on NFS.

Jason Butterfield

Remember, Jason's a programmer, so his presentation portion was more technical. He showed us the diagram below. It shows how pieces like Family Tree, Record Search, software components, and so forth fit together.

Family Tree and Record Search now share a common library of software components. There are 25 different components, among them: pedigree viewer, timeline, search, image viewer, event map, temple list, person summary, and family group record. The Data Model layer defines interfaces used by components to talk to services. Some of the services and domain pillars are: Family Tree/Common Pedigree, Authorities, Identity, Record Search, Ordinance Reservation, and Temple.

By this time I was starting to phase out. "Pillars blah, blah, ... share a common queue... blah, blah ... to call the API. This is the same API that 3rd party developers call, so we're on an equal footing."

In the question and answers, the only snippets that caught my attention were:

• Long list of reserved temple requests take a long time to display and come up piece meal. [This] week's release will be faster; it will request 30 at a time.
• When displaying the pedigree, we get batches of 3 people at a time. Version 2 API will be faster and we may revisit this batch size.

That's it for now. Stay tuned...