Idea for a new navigational view

This posting introduces an idea for a new navigational view in Gramps, and includes some rough sketches to help explain the idea.

Gramps currently has views for each type of data (persons, events, places, etc.); some of these views are hierarchical. The relationship view (including the new “combined” version) provides some ability to navigate among persons. Gramps also has chart views (pedigree, H-tree, graph view, etc.) which are navigable. There are also tools, gramplets, etc, which help in various ways.

So what is the need for a new navigational view? It is meant to make it easier to:

  • grasp the entire structure of the family tree, with respect to the current person, without seeing everything all at once (or to mix metaphors a bit, to paint a meaningful picture of the “forest” without painting each individual “tree”)
  • see and understand the relationship(s) between the current person and any other person in the tree, differently than existing tools such as the Relationship Calculator

Specifically, it can help answer questions such as:

  • How many third cousins does this person have, and who are they?

To go any further, I need to start using some illustrations. Please keep in mind that I’m not a UX designer (which will soon be quite obvious).

The new view can be thought of as a graph that starts with four nodes:

  • the self node is the current person
  • the parents node is the set of persons who are a parent of the current person
  • the siblings node is the set of other persons who are children of the any of the parents
  • the children node is the set of persons who are children of the current person

Note that the above definition of siblings includes all persons who have a parent in common with the current person, even those who don’t appear in any family with the current person.

Some of the nodes may be expandable, and that potential can be indicated somehow:

For example, the siblings node can be expanded to have a children node beneath it:

And the parents node can be expanded to show its parents and siblings:

Then that new siblings node can also have a children node:

And each of the children nodes can have children nodes of their own:

And so on.

Some of the nodes (other than self) may be empty, if such relatives never existed or have not yet been identified. A count within each node can make that clear:

Each node can be labeled to indicate the general relationship of that set of persons to the current person. I say “general” relationship because the view does not distinguish between paternal and maternal relatives, etc., and because the meaning of “siblings” is more general, as described above. The choice of suitable general terms may therefore be problematic for some languages or cultures.

However, although the node labeled “first cousins” (for example) might contain some persons who are technically not first cousins of the current person, it is still the case that all of the current person’s first cousins will be contained in that node.

Although a node with a count of 0 need not be expandable, allowing the user to expand it lets them see the general relationships represented by subsequent nodes.

Some persons may be represented in more than one node, or multiple times within the same node. (That’s an intentional feature, not a flaw!)

An additional, non-expandable node called “Other” can represent all of the persons in the database who are not related to the current person in any way:

A suitable control (with a choice such as “Include spouses”) can allow the user to include spouses in the list of persons for each node. Otherwise, they are included in the other node, unless they happen to be related to the current person in some other way. A different setting of the same control (“Include only biological relatives”) can cause all non-biological relatives to move to the “Other” node.

Again, I’m not a UX designer, but I imagine clicking on a node and getting a pop-up list of the persons represented in that node, and that list can include not only a name (and perhaps a few basic details like birth and death dates), but also the actual relationship, if any, to the current person. I will not attempt any further illustrations here.

Depending on how a name within that list is selected (that is to say, what manner of clicking), either that person can become the new current person, thus reinitializing the entire display, or that particular path from the current person to the selected person can be highlighted on the graph, and the names of all the connecting persons can be displayed near the nodes that contain them.

Alternatively, users can also somehow perform a search operation to highlight all of the nodes that contain a given person.

Note that the view also makes it easy to count degrees of separation between the people represented in different nodes. (But two people within the same node could be separated by varying numbers of degrees – two of your first cousins might be siblings to each other, or cousins to each other, or unrelated to each other.)

Although I’ve mentioned a number of details, I’m sure there are many other considerations that haven’t occurred to me yet. If anyone has managed to read this far, I’m curious to hear their feedback.

By the way, a similar navigational view could be created for places:

  • the self node is the current place
  • the parents node is the set of places that contain the current place
  • the siblings node is the set of other places that are contained by the parents places
  • the children node is the set of places contained by the current place
  • the nodes can be expanded, searched, etc. in the same manner as for persons

A navigational view could even be created for repositories, sources, citations, and their references:

  • When self represents a citation, parents contains the citation’s source, siblings contains other citations of the same source, and children contains all of the citation’s references.
  • The citation’s parents can be expanded to show its parents, which contains the repository where the source is located, and its siblings, which contains the other sources in that repository.

Even if those other views are not particularly useful, it might be helpful to think about them just for purposes of designing things in a more general way.

1 Like

Just to clarify, the nodes of this graph do not represent individual people, expect for the self node (but even that would also contain the spouses of the current person). However, it is still useful for determining the expected average amount of autosomal DNA shared between the current person and persons in any of the other nodes, since that is a function of the degrees of separation, which are easy to count. Of course, the actual range differs from the expected average, and may be lower or zero for some persons in a given node because they are only half- or step-relatives of the current person.

Again, this graph is not intended to show individual items in a node, but yes, in the way I described it earlier, the children node of a citation would contain all of the things (events, persons, places, etc,) that reference that citation.

The view is meant to help the user navigate at a high level in order to find things of interest and understand relationships, but it is not meant to show a detailed view of one node per object. I am also interested in such views but they would be different than this one.

Thanks for sharing about Tulip – it looks like a useful program.

Yes, exactly, to open the editor, or make that person the current person, or do whatever other useful things could be done at that point. I just did not include any illustrations for that.

1 Like

Another visualization graph style that has some similarities is
The Contextual Family Tree

1 Like