Because I apparently can’t stop making genealogy charts: here’s a pedigree chart I put together as an experiment to see what things would look like if the more recent names were larger. The result:
I do like the larger names, but it seems that on the left side of the chart the hierarchy is harder to read. This kind of chart might work better with just four generations instead of six.
I’ve got this itch to record as much of the stories of my family members as I can — particularly the histories of my parents and grandparents who are still around. They’re all getting older and memories are fading and at some point relatively near in the future they’re each going to go full incommunicado. At that point, family history research gets harder, working in the realm of conjecture and secondhand reporting. Much easier to talk to primary sources while they’re still alive. (Sounds coldblooded when you put it that way, though, doesn’t it.)
Yet in spite of these lurking deadlines (literally), I hardly ever actually talk to my parental and grandparental units about their histories.
It’s a pity. Every time I do talk with them, it’s wonderful, and I learn things about their past and my past that make my life more meaningful and that help me relate more to them, especially now that I’m a father. Tonight, for example, we visited my parents and somehow ended up talking about one of my younger brothers who was born at only twenty-one weeks along and passed away when he was forty-five minutes old. I sort of knew the story from when it happened, but I was only seven at the time and my memory’s fuzzy. Now, though, I’m an adult with two children of my own, including a daughter with some fairly severe medical issues. It wasn’t till I heard my parents talk about it tonight that I really even understood what losing their son must have been like. And now I’ve got the story recorded so I can refresh my memory later when my kids are old enough for us talk about it, and even better, they can hear it from their grandparents themselves. That’s worth a lot to me.
The thing, too, is that it’s far easier to record these things now than it ever was before. I have a phone in my pocket almost all the time. That phone has a microphone and can record audio to MP3s, which take up so little space that I can store hours and hours and hours of conversations on my phone. It’s amazing.
Now I just need to figure out a way to remind myself to do more of these oral interviews before it’s too late…
Ever since seeing the IPython notebook, I’ve been thinking about how its notebook idea would be great for genealogical research. So I put together a (very rough) proof of concept:
Some notes:
A text-based query interface (the queries are in purple) to get information from a database. I don’t know that the best query language would be natural language like this — it’s more just to get the idea across — but the important thing is being able to easily do these types of queries against the genealogical information you’ve stored, enabling all sorts of analysis. “Who in my tree is born more than nine months after their father died?” “Who got married when they were younger than 12 years old?” “Who are all the children who died when they were younger than eight years old?” And so on.
Interleaving queries, their results, and other text (using Markdown, of course). This is the core notebook idea. Or you can look at it as an annotated transcript of a query session. Rather than just having a list of queries and their results, you sort of embed them in between your writing about the research. (Similar to literate programming.) For me, writing things out helps me to see what I think and wrap my head around the research.
There’s a lot of room for data visualization here. I’ve only shown pedigree charts and some basic tables, but it’d be easy enough to have a query return any other type of chart — bar, pie, fan, you name it. Including interactive things like the family analysis tool.
I didn’t include this in the mockup (because I, uh, just barely thought of it), but you could extend the query language to support hypotheticals. “Show me what William Crowder’s family would look like if he and Sarah got married in 1820” or “From now on, pretend Samuel Shinn was born in 1860.” And then following queries would act as if that were true. It’s nice to be able to establish a few suppositions and then see what the ramifications would be, whether they’re plausible, etc. Or to compare two different hypotheses.
Which brings us to the purpose of all this: to have a good place to do the rough, messy side of genealogical research. Thinking through things, seeing what comes of it, and keeping a record of the journey, basically.
Since the information in the database would be subject to change (as you do more research), it would probably be good to cache the results. Or maybe highlight the queries whose results have changed when you reload a notebook. Personally, I lean more towards caching, so that the notebook accurately represents the database at the time it was written (making it a valuable historical record of your research), but you could also look at it as a living document that updates automatically when the background data is updated.
Anyway, the proof of concept is just a static HTML page. I’m not planning to do anything more with it, but I wanted to get the idea out there.
As I’m doing more research on my family lines from Morrone del Sannio (a town in Italy), I’ve put together a quick index by year to the various microfilms for each type of record (click for the full PDF):
A while ago I said I was going to post more in-progress stuff, but I haven’t really done that. So, here’s one of my current projects (click for the full image):
It’s a little app (currently just a mockup) that helps you track LDS temple ordinance work. With my own family history work, I’ve found that it’s a bit of a pain trying to remember which sealings I can do and which I’m waiting on the endowments for. I’d rather let the computer do that. So, the idea with this app is that it’s smart enough to keep track of the relationship between people (children and parents, spouses) and know which ordinances you can do and which you’re still waiting on. (I haven’t mocked this up yet, but in the Sealings column, there’ll be a ghosted area for sealings waiting on other ordinances.)
The other use case is that when you’re about to go to the temple, it makes it easy to see at a glance what cards are ready for whatever ordinance you’re planning on doing. “I’m doing initiatories, okay, here are the cards I need to take with me.” That kind of thing.
I’m also planning to include a stats page so you can see how many ordinances you’ve done each month (separated out by type) and get a list of all the people you’ve done the work for.
Progress-wise, I’ve got the design roughly where I want it (with polishing still left), so I’m just figuring out the backend logic and planning out the code.
In genealogy web apps, I kind of like consolidating name fields into a single textbox. Simpler is better. But then you run into the problem of distinguishing the surname from the rest of the name — because of surnames like “Gutierrez Sanchez,” you can’t just assume the surname is the last word in the string.
I’ve been thinking for a while about a clean way to deal with this (as well as giving a nice visual indication of the surname instead of just slashes), and here’s what I’ve got so far, which I’m dubbing (rather unimaginatively) the Javascript name box:
When you click on the name, it becomes editable:
How it works
Basically, you give it an input.namebox element and it creates a corresponding div tag for displaying the highlighted surname. It then flips back and forth between the input and the div, parsing the name field and changing the highlight appropriately.
This is the project that spawned my CSS mini timeline adventure (which I ended up not using, actually). It’s a really simple proof of concept for analyzing family relationships:
You enter basic information for the family and on the fly it draws a timeline and shows you how old each person was when other major family events happened (siblings born, deaths, etc.). Super simple. It’s mostly so you can get a better feel for what all the dates actually mean — you can see that so-and-so was only 16 when her mother died, or that there’s a gap where a child could have been born, etc.
Also, this is just a proof of concept — I’m not completely satisfied with the design, and the print stylesheet needs more work (but yes, there’s a print stylesheet), and there are plenty of issues left to resolve (some of which are on the GitHub issues page for the project) — but you get the idea.
Something like this would be more useful when hooked up with a data store (like FamilySearch, for example, which wouldn’t be very hard to do). Then you wouldn’t have to type everything in.
I wanted to add small timelines to a little web-based genealogy proof-of-concept I’m working on, and I realized that it’d be pretty easy to make the tick marks using CSS box-shadows. And it was.
There are some caveats (if you change the background color, you have to edit the CSS to match — you can’t use an rgba color with an opacity of 0 because then the tick marks fill the whole space), but overall it works well.
The other day I was looking through one of the directories on my computer and found a web-based family descendancy chart redesign that I forgot to post about. It’s a work in progress, but you can take a look at the live demo, which looks like this:
Traditional family group records (at least the ones I’m used to) are usually a little ugly, but man, they don’t have to be. Here are a couple of redesigns I’ve been playing around with (and you can click on the screenshots to get a full PDF of each).
Original
I should add that they normally don’t look quite this bad — this happens to be printed from the new FamilySearch website, and the print stylesheets need a bit of work. But this is the general layout of traditional family group records.
Too many lines. And lots of wasted space on information that isn’t present. (If you intend to fill it out as a form later, however, then it’s a good thing. For the purposes of this redesign, I’m assuming you’re doing your data entry on the computer.)
Also, the visual hierarchy is essentially flat, making it hard to see the names of the people involved.
Version A
At a glance, you can tell which family the record is for. This is handy when you’ve got a lot of family group records.
The layout’s a little more compact. (If a family has lots of kids, I’m thinking the second page would drop the parent sidebar and go full-width, kind of like in Version B.)
For the parents’ parents, I’m including a lifespan to help place things in context (see John Crowder).
I’m using “born” and “died” instead of “birth” and “death” since they’re shorter.
The LDS ordinances are a lot more compact. (And for people who aren’t LDS, it’d be really easy to remove them from the layout.)
I’m still not very happy with the placement of the gender designation on the children.
The footer is home to some “family stats,” interesting tidbits on the family that aren’t immediately visible from the absolute dates.
Version B
The parents are now side-by-side on the top. This layout emphasizes the vertical hierarchy of the family, for what that’s worth.
There’s more space for each child’s information. I’m not sure that space is necessary, though. Hard to say.
Conclusion
I see these as initial explorations into the area of family group record design — there’s still a lot of work to be done, and I’ve got lots of other ideas for ways to visualize family history data.