Thoughts on new version of RootsFinder (was Using RootsFinder on iPad - add media)

I’m experimenting with how flexible/powerful a new iPad Pro can be with the main software that I use. At the moment I’m heavily invested in rootsFinder so tried out to see how well it would work.

So far most things work well, but one noticeable problem is the add media option. As far as I can see the ‘Select File’ option only goes to the camera and doesn’t give access to the file locations that are available eg when added a Photo or Document in FamilySearch.

I suspect this is something that could be easily improved by accessing the relevant feature on iOS. I’d love RootsFInder to be able to easily pick up photos from the photo library but also documents from Dropbox or other cloud services.

Hoping this can be considered.

kind regards


At this point Findmypast owns RootsFinder, and I’m just providing support. So I’m fixing bugs but not adding new features. :frowning:

The good news is I’m planning to begin development work on another family tree this Fall. That tree will be a mobile app (iphone, ipad, or Android) and a website. It will take awhile to complete, but I’ll make it easy to migrate from RootsFinder to the new tree. I’ll let you know when it’s ready for testing, probably around this time next year.

Thanks for getting back on this Dallan - and interesting news indeed. Would it be a ‘bug fix’ to make it clearer within the system how to lodge feature requests, assuming that someone might look at them sometime.

Interesting news about your development work and one that will be watched with interest. A couple of questions if I may…

  • will you be looking for an alpha/beta group to assist with testing etc? (interested)
  • will you be providing a similar ability to cross reference with FamilySearch, a feature of this product that is particularly helpful


Commercial or Open Source?

i modified the roadmap trello board to direct people here. This is the best place for people to ask for feature requests (though I can’t promise anything).

To answer your questions:

  • I’m definitely interested in alpha / beta testers, thank you. I’ll post more information here in the forum, on the blog, and even on the RootsFinder homepage when it’s ready.
  • I plan to provide the same type of integration with FamilySearch.
  • Definitely open-source. In fact I’m looking for volunteers to help if people are technically inclined.

I’ll post more information soon.

Hey Dallan,

I’m not sure what you have in mind in terms of scope, functionality, and such but here are some thoughts since I’ve been thinking about this a bit recently…

Cross platform would be nice and give people the most options… desktop / web / mobile. Have you looked at Vue & the Quasar framework? Quasar was built to target all three with a mostly common codebase, using Electron for the first so a desktop build can support Windows, iOS, and Linux.

A graph database like neo4j would seem more suitable for the backing store than SQL.

I know I mentioned Gramps here before. It’s Open Source and written in Python, you should look at it if you have not since it is the most advanced Open Source one available today. The user interface is antiquated, but the data model is well thought out. A couple people have talked about adding FamilySearch integration to it over the years and a web interface, but neither ever really went anywhere. I have had performance issues with it like I did with RootsFinder due to the sheer number of events/citations/notes in my tree.

In that vein have you ever looked at what Darren Lythgoes has done with TNG over the years? He has a number of innovative features and ideas in it.

It would be really nice to see a next generation Open Source alternative that significantly raised the bar.

  • Providing a clean, modern user interface. I suggested in the past it might be nice to have two views of the data, one geared toward research and the other presentation.

  • Providing everything needed for serious professional as well as casual use. I’ve never used but often heard over the years that TMG was the best on the market for serious genealogists, I am not sure anything has ever really filled that niche since.

  • Supporting both desktop and web based use. No one should be boxed into one solution fits all. Some do not want any of their data online and complete control of it, others are fine with it.

  • Supporting local as well as cloud based storage, particularly for media items, perhaps with a plugin architecture for cloud storage to make adding support for new providers easier with the ability to automatically save the data to more than one provider at the same time as well.

  • Supporting collaborative work on trees by others when on the web.

  • Supporting integration with FamilySearch but also designed to potentially support integrations with other genealogy sites in the future.

  • Providing a modular plugin architecture for reporting and hinting and perhaps other add ons as well to make it easier for others to extend functionality.

Two features I would like to see:

I think it would be nice to have the ability to associate multiple people with any event optionally in different roles. Think about the witnesses or best man and maid of honor for a marriage, or the sponsors for a baptism, many times these were other family members.

I think it would be nice to associate any event with pictures from the event to show on a timeline, just as it would be nice to associate pictures of a house or church or anything really with a location for similar purposes.


  • Cross-platform is a definite priority. I’m currently learning Vue. I think the choice is between Quasar and Flutter. I think the future will be more and more mobile; I want our interface to be mobile first, web and desktop second.
  • Lately I’ve been using postgres’ json support to treat postgres like a document database that supports joins. The thing I like about postgres is that I can have managed postgres on AWS, even serverless postgres, for pretty low cost. Neo4j is interesting, but I think I’d use it as an auxiliary datastore to the primary datastore, like using ElasticSearch to support search.
  • I need to spend more time with both Gramps and TNG.
  • I really like your idea about a researcher and a casual view. Completely agree.
  • Agree about TMG. I’ve never used TMG personally but I’ve asked people what they like best about it. It seems that being able to tag and color individuals is oe of the main things that people liked about TMG that RootsFinder lacks.
  • One of the things I want to do with the new tree is make it extensible, like WordPress or VSCode. I’m really hoping that others will write extensions, especially for DNA and media. I want to consider providing a plug-compatible API interface for the FamilySearch API so the 100 or so FamilySearch partners can plug into us without code changes.
  • Here’s something I’m especially interested in: Check out It’s promoted as a group chat system, but it’s really a distributed database with json packets for transmitting new messages. It even handles offline clients that come online at a later time. So what if you based your tree model on event sourcing and instead of using Matrix for chat rooms you used it for trees? Then you could have different people running on different “home” servers being able to collaborate in real-time on the same tree. Matrix even has the idea of bridges to external systems. Likewise, we could bridge to Familysearch, Ancestry, etc.
  • Rootsfinder has the ability to associate multiple people with any event in different roles. The new tree would continue this model.
  • Rootsfinder’s model for associating media and events needs improvement. Agreed it needs to be easier to link multiple media to an event or multiple events to a media object.

Agree the more modular/extensible it is the better. That also makes it more approachable for people who want to contribute in areas they care about.

Providing a plug compatible FamilySearch API is an interesting idea. Having a richer data model I would think you might want to expose it fully with a well thought out native one as well if it makes sense to do so.

I had not heard of the Matrix, so many new things out there. I need to digest that as I may not fully follow your line of thinking. You’re suggesting to leverage that as the transport for a publish/subscribe style model instead of a manual sync model like FamilySearch offers in their API today?

If Open Source what license did you have in mind? If it is not a self contained application and some component has to be permanently hosted in the cloud are you thinking of setting things up like WeRelate with a small non-profit foundation to keep it going?

Anyway, overall I think I like where you are heading. I’m probably no where near your caliber but think I would like to help as best I can.

Dallan, a couple more thoughts I wanted to share and expand upon…

First data classification…

Gramps let you flag any item in the tree as private. A person, place, source, citation, relationship, you name it. I think a new program should permit that with any object as well, not just people.

Someone on here asked at one point about being able to flag uncertain information in their tree as being a research item and having an easy way to find it, and I too have wanted the same thing for some time.

While you could argue a tagging system covers that, it should be part of the core functionality of any genealogy product I think just like the privacy flag concept. You have public and private data, and you have supported/cited/proven and speculative/research/unproven data in the tree. You need a way to classify it.

In addition to allowing a user to classify their data they should also be able to, if it is a person, apply that recursively to all descendant or ancestor lines for a person.

On Gedcom exports or when sharing the tree online with others the owner should be able to control whether research data is included/visible or not just like with private data.

Having done that it also makes sense that maybe some elements in the tree view may be color coded to denote the status of the person. Maybe a thin yellow border around people classified as research or something like that.

Second source citations…

Not all citations are created equal, as we know, and as evidence should not be treated as such. At one point I suggested a way to rank them and color code the stars here I think.

I think all citations should have at least two properties for ranking, let us call them knowledge and origin although maybe there are better labels.

The knowledge attribute captures if the citation/peice of information comes from a primary, secondary, or other source. You rank by assigning values 2, 1, and 0 to each.

The origin attribute captures if it is an original, transcribed, derived or other source. Here you rank by assigning values 3, 2, 1, and 0 to each.

Perhaps you add a third attribute, say confidence, that is a more subjective measure of high, medium, low, or none as well based on the knowledge of the overall family profile in the mind of the user. That too would be say 3, 2, 1, and 0 each as well. I’m not sure this should be included or not though. Maybe included for some purposes but not for others as it is subjective.

Rank is computed by adding the values.

A date obtained from viewing an original source, or copy of original source, like a marriage certificate would be ranked higher than a date obtained from an index or transcription of the marriage record where an error could have been introduced. And likewise a marriage or birth year derived from a census ranks less than either of those. And likewise a date from a published family history is even further removed, as even if the author reviewed the originals they could have made a mistake as well as the publisher. Or a date from a Family Tree published from someone else, here I’m thinking of trees, should also not be given much weight given how many have problems in them.

I think a ranking like this is just as important in an evidence oriented system as data classification.

And think about what it enables now. In a publish/subscribe model if people are able to publish to a pando tree or subscribe to one it helps rank what information to consider more reliable when they publish.

Someone publishes a birth date, the citation is from a primary source. Someone tries to publish one that is from a less accurate source. Now you have a way of better managing that. You also then have a metric to try to rank the users who publish to the tree for accuracy. Maybe those who seem to know what they are doing are allowed to perform direct edits.

The other thing having a ranking like this does is give you something to use to try to visually indicate the quality or reliability of the data to the user.

For example I have deep New England lines in my Ancestry. Some ancestors have ten records or so in that Connecticut Deaths and Burials index. That index was transcribed from the Hale newspaper transcriptions I think. Having ten records with the same date does not tell me anything new. What is worse with that collection is that some of the death dates actually differ because they were not the real death dates, they were dates the newspaper article mentioning the death was published and the data was transcribed wrong. But the point is if I saw ten stars next to a person I might think they are well researched/sourced/documented which is misleading, and worse yet all those sources are of a poor quality.

With ranking you could look at some of the key facts about the person, birth, baptism, marriage, death, burial or whatever. Each fact with a citation is now a star with the color based on rank with green the highest.

Regarding Matrix, yes, I’m thinking that if you have your tree on Server A, and I have my tree on Server B, and you invite me to your tree, then your tree will be copied to Server B and kept in sync automatically, and I can access it from Server B.

Regarding the license, I’m thinking the Apache license. Genealogy societies and other organizations could host copies of it, and yes, I’m planning to also host it with the same non-profit foundation that hosts WeRelate.

I’m happy to get your offer to help! I’ll be in touch when we’re further along…

I can see some use-cases for object-level privacy doesn’t seem unreasonable.

And yes, the idea of uncertain/unproven data is a big deal. It needs to underpin the entire data model. I’m not positive what the right approach is here. Tagging and color-coding and source raking are certainly part of it, but I think there’s more yet needed to support the research process. It will require some thinking to get right. At the right time, I’d like to invite a group of people to start a dialog.

Also, I’ve recently come across AirTable, and it seems like there’s something to be achieved by integrating with AirTable.

Thank you for your thoughts! I’m pretty excited about the future.

Sounds really interesting. Integrating with something like Airtable (I have very limited experience of it) sound like it could have a lot of uses. A couple of simple ones? View/filter etc any table of information including todos, filtering data for specific conditions (all my living people over 90 years of age) etc etc.

I’m not much use on the technical side (anything technical in my CV is very old now) but very interested in requirements, use cases, testing, etc if that can be of use.

Thanks! When we are ready to start talking about user requirements, I’d love to get opinions from you and others about how RootsFinder could be improved, especially in two areas: (a) to help people more with the research process, and (b) to give people more ways to share their findings with others. I’ll be in touch toward the end of the Summer.

Not sure if you have run across this effort before, stumbled on it tonight, it strives to be purely evidence based.

Very cool! I haven’t seen that before. I’ll check it out.

You’ve probably seen the other similar effort:
Are you aware of any other offerings out there that work that way?

Yes, I’m familiar with Evidentia, and also with

But I recognize that I’m not big enough to do all these things myself. I’m hoping to make the new version of RootsFinder extensible so others could create plug in tools like Evidentia and ResearchTies.

That’s why I am happy to hear you want to take an Open Source approach with it, as it can then become a community effort. I think if the data model and core architecture are well tought through and planned out and you make it easily extensible it will be well received.