Wednesday, September 2, 2015

Guiding Principles for Cleaning Up Messes in Family Tree – #BYUFHGC

Ben Baker gave guiding principles about cleaning messes in FamilySearch Family TreeThis is the second of two articles about Ben Baker’s presentation at the 2015 BYU Conference on Family History and Genealogy. Ben’s topic was “Help! My Family is all Messed Up on FamilySearch Family Tree.” His slides and syllabus are available at and, respectively.

Ben presented a list of guiding principles to use when cleaning up messes in Family Tree.

Play Nice With Others

Remember this is a shared tree. Don’t be too bullheaded. Apologize when you’ve messed up. Be nice how you approach people. When people mess up, it’s generally because they don’t realize what they are doing. Some users delete people thinking they are operating in a private tree.

Watch out for mytreeitus. Ron Tanner came up with the term; Ben Baker gave a dictionary-like definition:

mytreeitus \mī-trē-ˈī-təs\ (noun)
An inflammation common to many genealogists,
particularly heavy users of PAF. Symptoms include
extreme anxiety over others modifying their extensive
genealogical research, possessiveness of ancestors,
unwillingness to work in collaborative family trees and
disregard for others when removing erroneous
persons from their family. Usually occurring in more
mature adults and rarely seen in those under 40.
[Ouch! Ben didn’t score any points with his largely older-than-40 audience.]
Learning to use FamilySearch Family Tree has been
shown to be an effective treatment for this affliction.

Make Your email address public. To do so, click on your name in the upper-right corner of the screen. Click settings. Click Contact. Enter your email address and check the Public box next to it. There is a messaging system coming soon that will allow you to send messages to others, even if their email address is not public. [Since the conference, that feature has been released.]

Draw Pictures and Take Notes

Most of the problems that Ben runs into are messed up families. To help sort things out, draw a picture showing the relationships as they should be. Here’s a diagram with a father who fathered his first child with his first wife and his second child with his second wife:

One of Ben's diagrams showing relationships

Pay attention to the PIDs. Each record has a PID. If a person has two different PIDs, then there are two different records that need to be merged. If two different persons have the same PID, then they aren’t really two at all. They are merely showing up twice in the same diagram. I’ve created an example, below. While Imaginary Child (LKPR-R95) and Imaginary Child (LKPR-R9N) are the same person, there are two PIDs. That means there are two records that need to be merged. Also notice that there are two of Imaginary Child (LKPR-R9N). By paying attention to the PIDs, we see that there are not really two; it is the same record showing up twice.

An imaginary family showing 1 person with two PIDs and one person shown in two places

To keep track of things, open up multiple browser tabs. To open a new tab or window when clicking a link, use a middle click or a right click of your mouse [or hold down the control-key while clicking].

If you are really worried about how to do things, try things out on Beta has almost the same information as the real Family Tree, changing stuff on beta doesn’t change the real tree. If you are uncertain how to go about making a change, go over there and try things out. FamilySearch also tests new features there. To see features that might be coming, you can go over there every once in a while and see what looks different.

Family Tree has two relationship types: parent-child and couple. FamilySearch developers call a parent-child relationship a tertiary relationship because there are three people involved: a father, a mother, and a child. Family Tree uses the same innards for a single parent situation, but leaves one parent empty.

Two relationship types in Family Tree

A married couple with one child is represented in Family Tree with two relationships: a couple relationship (because of the marriage) and a parent-child relationship. Ben showed the screen snippet, below, with little icons overlaid showing the couple relationship and the parent-child relationship. To edit or delete the couple relationship, click the pencil icon to their right. To edit or delete the parent-child relationship, click the pencil icon to the child’s right.

Parents and child with relationship icons overlaid

Let me make an aside here. A nuance sometimes lost on people is that there can be a parent-child relationship with parents who don’t have a couple relationship with each other. The biological father might be nothing more than a sperm-donor, for example. In the Imaginary family, above, there is no couple relationship between Imaginary Father and Imaginary Mother. Instead of showing a marriage date between them, Family Tree shows a link to “Add Couple Relationship.”

We return now to Ben’s presentation, already in progress...

“Let me reiterate! Above all! DO NOT CLICK THERE!” [Oops. Makes me wish I had been listening. Oh well.]

Ben showed a family not unlike the imaginary family I showed previously. Imaginary Child (LKPR-R9N) is shown once with both parents and once with just his father. This is a common scenario. Ben asked attendees how to fix it. One suggestion was to add the missing mother. That was not the correct answer. The child is part of two parent-child relationships. The first parent-child relationship has both parents. The second parent-child relationship has just the father. It is incomplete and unnecessary; delete the extra relationship.

Deleting a person, on the other hand, is rarely the right thing to do. When there is an extraneous person in a family, don’t delete him, delete the relationship. (This makes sense when you think about it. Family Tree is intended to be the family tree of all mankind. Everyone who ever lived needs to be in there. Keep the person, just get him out of the family.)

There are probably only two times when you should delete a person: If you find a fictitious person such as the god Odin or Mickey Mouse, you should delete him. Or if you have just barely added a person and realize that was a  dumb thing to do, delete him. In fact, FamilySearch will soon make changes so the latter condition is the only one in which you can delete a person. For a fictitious person, you’ll have to call support and ask them to delete him.

“I think delete person is evil, personally,” Ben said only half-jokingly. “It’s doing really bad stuff in the tree.” Deleting a real person can be a double-whammy (my description, not Ben’s). When you search for a person in the tree, including spouse and parent names is very powerful. When you delete a person’s spouse or parent, that person becomes harder to find. If the person is left with absolutely no relationships, they may never be found again. FamilySearch employees call such persons “dark matter.”

I had to leave early, so I didn’t get to hear the remainder of Ben’s presentation. I’m guessing he didn’t have time to finish all the material he prepared, but it is covered in his slides and syllabus. Let me call out a few more  guiding principles:

  • Base your actions on verifiable sources.
  • Provide good reason statements.
  • Act on icons to achieve regular, small successes with the possibility of adding new persons to the tree.
  • Contact support when you need to and ask to escalate if necessary.
  • Report abuse if you believe someone is purposefully destroying data.
  • Use the Watch List more effectively.
  • Learn to understand and use the Change Log better.
  • Read, maybe even subscribe to, the blog.
  • Embrace change.
  • Realize that some things are not fixable yet.

Well, that’s it for this year’s BYU Conference on Family History and Technology! It only took me a month to cover the small part of it that I attended. I leave you with this photo of conference bloggers, Jana Last, the Ancestry Insider, and Lynn Broderick.

2015 BYU conference bloggers, Jana Last, Ancestry Insider, and Lynn Broderick
Photo credit: random passerby.

Tuesday, September 1, 2015

My Family is all Messed Up on FamilySearch Family Tree – #BYUFHGC

Ben Baker addressing the 2015 BYU Conference on Family History and GenealogyBen Baker spoke at the 2015 BYU Conference on Family History and Genealogy. His topic was “Help! My Family is all Messed Up on FamilySearch Family Tree.” Ben’s presentations are always packed with useful information and this was no exception. Fortunately, he posts his slides. You can see them for yourself at This is the first of two articles recounting his remarks.

FamilySearch Family Tree is somewhat like a wiki. Anyone can make a change. Everyone sees the changes. It is maintained by volunteers. It’s free. It reduces duplication and encourages collaboration. Your research outlives you. You can link to photos, stories, and sources.

Ben posed the question, “If collaborative family trees are so great, how come everything is so
messed up?” To begin with, Family Tree was created from multiple kinds of sources. And Family Tree has imperfect patrons. It astounds him how “creative” people are when they make changes. “People do really crazy things. It never ceases to amaze me,” he said. The third factor is that FamilySearch has done things in the past to try to clean things up, and sometimes have made them worse.

There are three special usernames that frustrate users when they show up as a contributor in Family Tree. They sometimes introduce or re-introduce errors.

FamilySearch This value means that a FamilySearch administrator, or an automated FamilySearch tool, has changed the information. This happens when someone at FamilySearch is fixing problems that can’t be fixed in any other way.

This value indicates that Family Tree doesn’t know who the contributor was. On the slides Ben gave Pedigree Resource File contributions as an example. In his presentation, he mentioned the old four generation program (by which, I suppose he meant Ancestral File). I don’t think either of those are correct. I think Family Tree doesn’t know the identity of some contributors to the International Genealogical Index. When FamilySearch keyed in paper submissions to the IGI, they didn’t key in contributor or source information. This value exists for original contributors only; current contributors are all known.

LDS Church Membership

This value means that FamilySearch brought the information into Family Tree from the Church membership system. FamilySearch synchronizes Family Tree with the Church’s membership database on a regular basis.

When you call support, you get different tiers. The first tier consists of volunteer missionaries. They can escalate to  higher tiers. One of the higher levels is the Data Quality team. They can escalate bugs to the software developers; that’s when Ben would get involved. Ask support to escalate if the first tier is not able to solve your issue.

But things are getting better. There are hundreds of millions of sources attached to Family Tree. That is stabilizing things because people are less likely to make changes when there are lots of sources. People are merging duplicates; there are 40,000 merges per day and it has been as high as 50,000. Another sign that things are getting better is the reduced number of times that people undo merges. In the New FamilySearch tree, for every four combines, there was one separate. That was probably a sign that people were making incorrect combines. Today, there are about 30 to 1 merges to restores. Ben takes that as evidence that users feel like most merges are correct. And there are few reports of “edit wars.” That’s when two people disagree about a fact and constantly change it back and forth. There are some. Click the report abuse button if it is happening.

We’ll know Family Tree has “arrived” when it is the first place to go to find out about a historical person. “That’s not true today,” Ben admitted. We want people to say, “Wow, this is amazing. Why would I want to go make my own tree somewhere else?”

Stay tuned for more…

Powerful FamilySearch Partner Apps – #BYUFHGC

Jimmy Zimmerman presenting at RootsTech 2015“Have you ever said to yourself, ‘If only FamilySearch would do this one thing?’ ” asked Jimmy Zimmerman, product manager for FamilySearch Family Tree. Jimmy spoke to the topic “Powerful Partner Apps for FamilySearch” at the 2015 BYU Conference on Family History and Genealogy.

“There are an infinite number of ideas out there,” Jimmy said, “and FamilySearch has finite resources.” But what if others could add features? Well, FamilySearch has something called an API which allows that.

Diagram showing arrows between apps, through the Internet, to the FamilySearch API

[Insider’s note: An API is like a wall with holes in it set aside for particular actions. An app or website writes information on a piece of paper and, holding the paper in hand, sticks their hand through a specific hole in the wall. On the other side FamilySearch notices the hand sticking through the wall, reads the information on the piece of paper, writes a reply, and shoves the hand back through the wall. For example, an app might write a person identifier (PID) on a piece of paper and stick itthrough a hole labeled “fetch information about a person in Family Tree.” FamilySearch writes the information on the piece of paper and shoves the hand back through the hole.]

To use the API, companies must adhere to a strict set of rules. These are designed to protect the integrity of data in FamilySearch Family Tree and to guarantee best security practices. The rules are so voluminous they are jokingly referred to as “the tax code.” In the FamilySearch App Gallery, each app page indicates capabilities that the app can exercise within the information at Writing and modifying Family Tree requires far more rules than just reading Family Tree.

Jimmy talked about finding available apps in the App Gallery. If you can’t find a way to get to the App Gallery, you can always go to Find apps by searching for the name or description, specifying category, filtering by platform (Windows, iPhone, web, etc.), price option (free, purchase, or subscription), free trial availability, language, FamilySearch capability (read-only, update), and if a FamilySearch login is required.

Some apps are listed without any certification. According to Jimmy, these have been found to be so helpful, FamilySearch lists them despite the lack of certification. He pointed out’s Family Tree Maker as one example. An audience member asked when MyHeritage will be interacting with FamilySearch Family Tree. Jimmy said that while he couldn’t say, he could tell us it is in progress.

Users can rate apps and write reviews. Please leave reviews. It helps others find the really good apps and it encourages the developers to improve. If you find problems with an app, first contact the company. App reviews may not be a fair place to report problems, as the problems might actually be a FamilySearch API issue.

Some apps with high ratings are:

Jimmy demonstrated a few of the apps. Kinpoint was one that I had not seen before.

Explore Chart of displays a fan chart, or Explorer Chart as they call it. Dots on the Explorer Chart are like a to-do list. They mark things like missing vital information, timeline issues, duplicates, lacking sources, and record hints, although some of these are available only with a subscription. The pane on the left displays information about the focus person. A summary pane on the right-hand side shows interesting facts about the persons displayed in the Explore chart, such as the number of countries of origin, number of children per family, youngest and oldest ages, and range of birth dates. Most of these are available only by subscription. Facts can be used to highlight persons on the chart according to available filters. For example, you could see all ancestors highlighted who were 25-30 years of age at the time of their death. The chart can show ancestors or descendants. The subscription features are available for free in a Family History Center.

Jimmy showed, a website with census and vital records. MooseRoots is a new company in the family history space, but has its roots in the ability to pull together lots of information. [Insider’s note: The parent company is the newly named Graphiq, a data visualization company, with many vertical search engines.] For example, their census records are married to aggregate census statistics, name origins and meanings, historical stock performance, historical place information, and economic data. [Insider’s note: Some of their data looks pretty rough, like the WWII army enlistment records for The first five names from Cache County, Utah are Edson Bcnson, On Roy Pehr, Meroill W Glevn, Grant C Jarsvn, and Eewzp Thompkwo. If I had to guess, I would say they used OCR on a typed or printed source. No images were available.]

Jimmy wanted to show us their Civil War Soldiers collection, but couldn’t find the link to it. I stumbled across it at after a lot of poking around. Graphiq has married the standard Civil War Soldiers database with information about the infantry, battles, and casualty counts.

The same section of the Graphiq website contains information about battles, generals, sailors, and war statistics. They credit the National Park Service for the data and Hal Jespersen ( for the maps.

Monday, August 31, 2015

Monday Mailbox: How Fast Was the 1860 Census Indexed

Howland Davis sent a question in response to my article, “FamilySearch Indexing Not Keeping Up.”

Dear Ancestry Insider,

Interesting article, thank you.  I have a question about the comparison of the indexing the 1860 and the 1940 censuses.  I am fairly sure that the 1940 index was completed 1650 days after its release in 2012.  Was the 1860 census indexed 17 years after its release in 1932(?) or did the work start some years after that?

Just curious, not important.

Howland Davis

Dear Howland,

Ooooh. Something shiny.

It took four months and one day to finish its 1940 index. (See my article of 6 August 2012, “Census Indexing Update: And It’s Over.”) FamilySearch published the 50 states a while later, but I think it took them a considerable amount of time to finish the territories.

I believe the first large-scale effort to index the U.S. censuses was made by Ronald Vern Jackson and Accelerated Indexing Systems (AIS) in the late 1970s through the early 1990s. I believe he indexed heads-of-households only, and just the names, so the amount of work was more manageable. These were true indexes, not the census databases we use today. Where did he get his keyers? Does anyone know? He published the indexes as bound books of computer printouts.

A page from the 1976 AIS index to the Louisianna 1820 census
Ronald Vern Jackson, et. al, eds., Louisiana 1820 Census Index (Bountiful, Utah: Accelerated Indexing Systems, 1976), 1.

According to Thomas Jay Kemp’s The American Census Handbook (Wilmington, Delaware: Scholarly Resources, 2001), here are the publication years for a sampling of states:

Census Publication year
1790 New York: 1990
Ohio: 1984
1800 Ohio: 1986
Vermont: 1976
1810 Virginia: 1978
1820 Iowa: 1977
Indiana: 1976
1830 Indiana: 1976
1840 Iowa: 1979
1850 Iowa: 1976
1860 Iowa: 1987
North Dakota: 1980
Virginia: 1988
Washington: 1979
1870 Iowa: 1990

Notice all were done after the widespread availability of computers.

In 1984 AIS published on microfiche what it had completed. published AIS indexes online in 1999.

Some limited scope indexes were published earlier. For example, in 1964 the Ohio Library Foundation published an index of the 1830 Ohio census. This, too, was a computer printout. Volunteer family historians extracted the names of heads of households onto index cards. The cards were keyed onto punch cards, which were then sorted by an IBM mainframe computer.

A page from the Ohio Library Foundation's 1964 index of the 1830 Ohio census
Ohio Library Foundation, ed., 1830 Federal Population Census Index, vol. 1 (Columbus, Ohio: Ohio Library Foundation, 1964), 1.

So the answer to your question is, that indexing the 1860 census took about a decade and was finished around 1990.


Thursday, August 27, 2015

The Future Will Bring Automated Indexing Tools – #BYUFHGC

Jake Gehring presenting at the 2015 BYU Conference on Family History and Genealogy“It’s not that we don’t like our [indexing] volunteers,” said Jake Gehring. “We would just rather have them work on things that only [humans] can do.” Jake is director of content development for FamilySearch and presented at the BYU Conference on Family History and Genealogy last month. This article is the third and last article about his presentation. In the first article I reported on Jake’s premise that FamilySearch Indexing is not keeping up with the number of records FamilySearch is acquiring and additional means are needed. In the second article I reported about two of those means: increasing the efficiency of human indexers and working with commercial partners. In today’s article I will report on the third means: increased automation via computers.

In the third part of his presentation, Jake spoke about “the really far-out stuff, HAL9000 kind of stuff.”

Jake showed a screen shot that we saw in Robert Kehrer’s keynote. (See “Kehrer Talks FamilySearch Transformations” on my blog.) The screen showed a color-coded obituary.

Obituary with parts of speech color coded by FamilySearch automated obituary indexing system

FamilySearch trained a computer to identify the different parts of speech. They trained the computer how to discern meaning out of a bunch of words. Notice in the example above that names of people are identified in dark green, places in brown, dates in dark blue, relationships in salmon, events in pale green, clock times in a steel blue (or would you call that a dark sky blue?), organizations in red, and buildings in goldenrod (or would you call that a mustard?).

They basically teach the computer to read. The computer is willing to extract a lot more detail from an obituary than a volunteer can easily do. And it can work really, really fast. For obituaries, computers can do in about a week and a half what it takes all of FamilySearch’s volunteers three and a half years to do. This is why in a few weeks FamilySearch is going to stop having volunteers index the current obituary project. In fact, FamilySearch has already published about 37 million obituaries this way. You may already have found and used an obituary that was indexed by a smart computer.

This applies to obituaries published since about 1977. Since that time, most obituaries have been published and stored digitally. Pre-1977 it looks a lot differently. Because the obituaries are not already digital, it is a pretty nasty OCR problem. [OCR converts the printed page to text so that the computer can subsequently try to make sense of it.] The problem is so severe, computers can recognize only about half of the words in pre-1900 newspapers.

If you were at RootsTech you may have seen the last thing Jake showed. A company named Planet entered its ArgusSearch into the Innovator Challenge. ArgusSearch is a system that reads the handwriting of documents that have not been indexed. You type in something like “Steinberg” and the program shows some records that might match that name. It won’t find all the matches. And it may return some results that aren’t matches. But this is still useful. This technology is still young, but an application like this is likely to hit real life in the next ten years.

Planet's ArgusSearch automatically read handwritten names in census records without an index.

Jake summarized by saying that while indexing is going really well—never better—unfortunately, it is just not good enough to give us all the records you need. [FamilySearch does not index all the records they acquire.] “We need to do much better. It’s not that we are not quite there; we are way behind and getting further behind every year,” he said. There are three areas that FamilySearch needs to utilize. FamilySearch needs to increase the efficiency of its indexing volunteers. FamilySearch needs more help from for-profit publishers who can bring more resources to the table. And FamilySearch needs to use computer technology to make images searchable with little or no human intervention.

“It’s an exciting time to be alive. Can you imagine the explosion of document availability once we make a bit more headway in a few of these areas?”

Jake took a couple of questions:

Q. How easy is it to use tools like Google Translate to translate Spanish records?

A. Google Translate is better at modern, generic words. If you type in the text of a letter, you would be able to get the gist of it, but it may not handle archaic words or words specific to a vital record. As long as you know a small set of terms, you can usually get by without a computerized translator. There is no magic tool currently available.

Q. Why do we sometimes key so very little from a record? While we have someone looking at the document, shouldn’t they be extracting more?

A. Because we publish both indexes and images, we index the minimal amount necessary to find the image. Why index something that no one will ever use in a search? Cook County, Illinois death certificates are an example where we indexed something that didn’t need to be. We indexed the deceased’s address, but who will ever search using the address? Sometimes we don’t get it quite right, but that’s the general principle.

Q. When will we be able to correct published indexes?

A. We’re starting now after ten years of being in the top three requested features, we’re starting to implement the feature to allow you to contribute corrections. We are rapidly approaching the point when this will be available. I’m not really authorized to say “soon,” but we have our eyes on that feature.

Wednesday, August 26, 2015

FamilySearch Should Increase Indexing Efficiency and Utilize Partnerships

Jake Gehring presenting at the 2015 BYU Conference on Family History and GenealogyFamilySearch is not keeping up with indexing the records it digitizes and improvements in three ways could help fix this, according to FamilySearch director of content development, Jake Gehring. Yesterday I presented the first part of my remarks about his presentation at the 2015 BYU Conference on Family History and Genealogy (#BYUFHGC). Today I’ll present the second part, covering the first two of the three ways, increasing efficiency and partnering. Tomorrow I’ll present the third way, increased use of computerization.

Today’s FamilySearch Indexing (FSI) system is somewhat inefficient. FSI primarily utilizes a double-blind indexing methodology, sometimes described as A+B+arbitrate. Two indexers independently index a batch of records. If there are any differences, even one letter in one record, the entire batch is sent to a third person to arbitrate between the two values, or supply a value of their own. It turns out that 97% of all batches have at least one difference, even though what is keyed is the same for 70% of the fields. As a result, almost all records are looked at by three people. There’s a good argument that that is wasteful. For certain kinds of records and certain kinds of people [and certain kinds of fields, I might add], only one keyer is sufficient. The accuracy doesn’t get any better when involving two more people. FamilySearch has recently switched to single keying for newspapers in the last year since reading typeset material can usually be done without error. You wouldn’t want to do this for certain types of records or for beginning indexers.

A more efficient methodology is referred to as A+review. One person keys the information and a second person reviews what is keyed. All the reviewer does is indicate whether the information is correct or not. This could easily be done, even on a cell phone. This method is about 40% more efficient than the double-blind methodology because FamilySearch knows when a record needs to be keyed a second time. FamilySearch is actively working on this kind of methodology to increase the efficiency of indexing.

Jake showed three, entirely new, experimental types of indexing. Some do not even have working prototypes: keyboardless indexing, free-form indexing, and casual “micro-indexing.”

Jake showed an indexing system that allows productive use of devices without keyboards, such as smart phones. If you’ve used photo recognition in Photoshop, you have seen the paradigm before. He showed a slide showing 12 snippets of a name, such as “Henry.” (See my version, below.) These had been read from documents by a computerized handwriting recognition system. But since computers aren’t too good at reading handwriting, it presents its results to a person for verification. The person marks any that the computer got wrong. Where the computer had a good second guess, it could present that as well, allowing the person to select an alternate name, such as “Kerry.” For pre-printed forms, this works great and allows easy indexing on devices without keyboards, such as cell phones.

Snippet of name indexed as Henry

Shippet of a name that was indexed as Henry or Kerry Snippet of name indexed as Kerry
Snippet of a name that was indexed as Kerry Snippet from a page wherein one name was indexed as Kerry Snippet of a name that was indexed as Kerry
Snippet of a name that was indexed as Kerry Snippet from a page wherein one name was indexed as Kerry Snippet from a page wherein one name was indexed as Kerry

Snippet of a name that was indexed as Kerry

Snippet of name indexed as Henry Snippet of a name indexed as Kerry

Jake showed the FamilySearch Pilot Tool, another indexing system for free-form indexing. It is currently live, as a pilot. A large portion of the screen is a browser showing a record on Along the right side is a pane where an indexer can enter names, dates, and places extracted from the document. (See the screen shot, below.) A person would use the tool to index any record that they care about and a short time later the record would be searchable. You wouldn’t have to ask for anyone’s permission. You wouldn’t have to index all the names. Anyone could take any collection desired and do some indexing. This tool is in pilot right now. FamilySearch is very interested in tools that let you index as you go. To join the pilot, send Jake an email. (I see someone has also posted the link online. See “FamilySearch Pilots Web-Based Indexing Extension” on the Tennessee GenWeb website.) There is no arbitration. If you care enough to index the image, you probably care enough to be accurate. But that supposition is something yet to be validated.

The FamilySearch Pilot Tool for indexing - Click to englarge

“Micro-indexing” could be used to make images more usable. It would be nice to be able to browse unindexed images easier. FamilySearch is very interested in an upgrade to the current browse experience. Jake showed an animated artist’s rendition of a tool, reminding us that this is just a research and development idea.

FamilySearch is interested in making it easier to find records in images that have not yet been indexed.

In micro-indexing the system might ask you really simple questions, like, “What kind of record is this?” and have you click the record type. By asking volunteers to do tiny tasks, FamilySearch might be able to gather information to make browsing images easier to find my record type, locality, and time. Just because FamilySearch doesn’t have the time to index the images, doesn’t mean they can’t be made easy to browse.

This is a mock-up of what a micro-indexing tool might look like.

In addition to talking about increasing the efficiency of indexing, Jake talked about partnering. FamilySearch is fine with the concept of trading data with other companies. FamilySearch provides images and the partner creates indexes. They may even get exclusive use of the indexes for awhile. For example, a lot of Mexico church and civil records are being indexed right now by We all get the value of it eventually. FamilySearch has similar projects going on with Findmypast (I didn’t catch the projects names) and MyHeritage (Danish census and church records, and Swedish household names). This increases the rate of indexing by bringing more indexers to the table.