I’m starting to design the database. Not having studied a lot of database theory, I find it slightly intimidating, especially with possible scalability concerns in the future. But I’m not going to let that paralyze me. If it ends up having problems, then I’ll fix them and move on. Perfection is rarely achieved on the first try. It’s better to get something up and then tweak and iterate until you get it right.

It is tempting to try to read through some database theory books before I get too far, but I’m going to resist, if only because I know that’ll stop me dead in my tracks. Better to do it in parallel. (I’m saying this more to persuade myself than for any other reason. :))

As a brief overview of what’s going to go into the database, here are the objects/entities I’ve come up with so far which need to be represented, and I’m guessing each will be its own table:

• Individuals
• Families
• Sources
• Research pages
• Media
• Users
• Files
• Translations

And some thoughts on each:

Individuals

Has a collection of metadata associated with each record. Need to be linked somehow.

Families

Basically the same as individuals (collection of metadata). I’m not sure if these will be linked or if we’ll rely on the individual linkings.

Sources

Still not sure if I want to go with an elaborate citation system or if it should be more free-form.

Research pages

Each page can have lists, notes, pictures, other media, etc. Not sure how to store it.

Media

Pictures, etc. Right now there’s overlap between this and the research pages. I’m not sure yet how I’ll resolve that. Research page pictures will probably end up being more pictures of documents and such, whereas media will be pictures of individuals and families. Maybe. Hmm…

Users

List of users on the system. Usernames and passwords, first and last name, last login, that kind of stuff.

Files

A file can be a local Beyond store (on that server) or a link to another Beyond server (or a PhpGedView server or Family Tree, for that matter). (If you want to open a PAF or GEDCOM file on your hard drive, will it convert it to a local Beyond store first? Hmm…) You can have more than one of each, of course.

Translations

Support for internationalization.

Technorati Tags: Beyond, genealogy, PhpGedView, Family Tree, FamilySearch

This morning I had a small epiphany. When you’re going through a pedigree, only a small amount of information is visible (because of the nature of a pedigree chart). Wouldn’t it be nice if the main information — vitals, perhaps a picture, whatever — was right there? I remembered seeing something like this in fluxiom, and here’s a quick mockup I threw together:

The idea is that when you click on the name of a person in the pedigree, it pulls up this info panel at the bottom of the screen. To get to the full details (where you can edit things), you’d click on the blue “More on John…” link at the bottom or click on the picture (which gives a much larger target area). And you’d be able to hide it by clicking on the “Hide Panel” link at the right. If there’s no picture, there’ll be a silhouette of a male or a female (thus taking away the need to show gender in the text).

One possible drawback is that this adds one more click to get to the individual detail page. My hunch, however, is that most of the time you’re not editing, just viewing, and if most of the information you’re usually viewing is right there, you’re fine. So to make any changes, you’d click on the More link, which would bring up that individual’s page, where you could make all your changes.

This info panel would apply to families as well, of course. Maybe even places and/or years. Hmm… The statistics may or may not stay, but I think they’re kind of fun, if only to get a more real picture of who your ancestors were and how they relate to the rest of your ancestors. Whatever the most commonly needed information ends up being, that’s what’ll be on the panel.

As for the pedigree itself, I’m still not sure how best to display it. I’m leaning towards something like Google Calendar (but probably horizontal), and yet I don’t know. It’s probably better to stay simple for now and get the basic functionality up first…

Update: I decided to revise the look a little bit. I’m still not satisfied (mostly with the tabs), but I’ll leave it like this for now.

No, I’m not dead. :) School is definitely taking its toll, but things should be a bit smoother from here out, with no major assignments left other than my finals.

Anyway, that’s boring. :) More importantly, I’ve made a mockup of the pedigree view:

Over the next little while I’ll be testing a few different ideas for viewing and editing data. (For example, since this is a web app, should I display the whole tree and make the user scroll, or should I chunk it into three or four generations at a time? Are the fancy boxes around each individual necessary? When the user clicks on an individual or a family, should it take them to a new detail page, or should it bring up a lightbox-ish modal dialog box, or something else?) This is admittedly a bit spartan, but I think I’ll stick with this black-line pedigree layout (since it does work) until I get everything else done. Then and only then will I consider adding colored boxes and all of that.

Anyway, I’ve got to run, but I’ll be making more time for Beyond now that my Music 201 paper is done.

Technorati Tags: genealogy, pedigree

Earlier this afternoon I read Dan Lawyer’s post Trust Model. The intro paragraph does a great job of catching the gist of it:

Have you ever used an application that violated your trust? Maybe it didn’t save something when you thought it should have or maybe you unexpectedly came across you and all of your living relatives in some online pedigree. One of the subtleties to successful applications is not breaking the user’s trust model.

This is very, very, very important. I don’t think I can overstate it — it’s that important. There are two ideas in the article that hit me. First, access to data:

Provide at least the three mental buckets: my stuff, my shared stuff, and my published/public stuff. This does not imply complex access control systems. The simplest form can be stuff that only I can see, stuff that people on my shared list can see, and stuff everyone can see. More and more I find complex grouping concepts in sharing to be too much for ordinary people.

I admittedly hadn’t gotten to thinking much about this yet (except on a very cursory level), but I agree that the simpler it is, the better. Dan gives Flickr as an example, where your photos are private or public, but you can share private photos with friends and family as well (if you want). I like that. Not too complex, and I can’t think of any shortcomings, really. Sure, there might be complex situations, but I’m not going to design for complex situations if I don’t need to. Let the other record managers do that. I’m aiming at the 80% of the problem which most people will be dealing with. Fringe features have no place in Beyond.

The second idea, which is a beautiful solution for a problem I’ve been mulling over for a while now, is this:

Allow the user to say “I think” or “Maybe” about their conclusions. This is an area of functionality that is tempting to make overly complex. You could build a whole feature set around analyzing the quality of evidence, a surety schema, etc., etc. Ordinary people are likely to be driven off by this. One simple way to implement this might be to have a flag or button associated with fields that indicate that the conclusion is really a hypothesis of sorts. This would allow the user to share their work in progress with others without losing that important piece of metadata “I think”.

Is any more than that necessary? Either something is verified or it’s a “maybe.” I think that’s enough, and if more detail is required, they can go in the notes or research pages. The main thing is saying that the data isn’t certain. And that’s all it needs to be. This vastly simplifies things, which is a Good Thing. :)

Now I just need to figure out how to balance my time more wisely so that I can work on this project without completely leaving my schoolwork in the dust…

Technorati Tags: genealogy

Yesterday I hacked together a quick mockup of the login screen. It has problems in Safari, and I haven’t even tested it in Internet Explorer, but it looks like this in Firefox:

It’s good enough for now; I’ll worry about the nice blue login button and other alignment issues and stuff later on. (This is what I have to keep telling myself so I don’t spend the next two days perfecting it. :))

Incidentally, I’m now reading through some design pattern libraries, and the stuff I’m finding is important enough that I’ll try to read through most of it before continuing with the interface design. Why? Because they give rationales for each design pattern (when and where to use it, when not to, things to be aware of, etc.), which are very, very helpful. And I have a strong suspicion that designing the main interface will be a lot easier after having read through them. We’ll see. I really, really, really like the idea of design patterns, by the way. If only I’d come across this stuff a few years ago… :)

Technorati Tags: design patterns

Or rather just the snail. This is taking too long! Right now I’m working on Beyond only in my free time (because of these work projects that have a higher priority), and there isn’t much of that with midterms crunching me (not to mention other obligations). But the time constraint isn’t the main thing.

What’s taking too long is designing the interfaces. I think I’m a perfectionist and so I want to get each screen just right before proceeding, which is really slow and not good for creativity. Time to say goodbye to Mr. Perfectionist. Bypassing the internal censor (and this is common to writing and other arts as well) will free me up to get the ideas out and done with, and then I’ll be able to start coding. (I’ve hesitated to start coding until the interface was done, per the 37signals philosophy. But I’ll admit that they don’t recommend taking forever on the interface design. I’ll have to get back on track…)

Here’s a quickie roadmap of what I hope to accomplish next:

• Finish rough drafts of the interface
• Put together really quick HTML mockups of the interface
• Design the database
• Upload some test data
• Write code to display the data in some usable form
• Figure out where to go from here :)

To make sure that I don’t get caught up in the interface design again, perhaps I’ll set a limit on myself — one minute per screen, or something. We’ll see. Being a graphic designer has its downsides when doing stuff like this, because it’s hard to allow yourself to put out unbeautiful screens. Oh well.

Here’s a diagram showing the server/client model for Beyond (you can click on it for a slightly larger image):

I think the image pretty much speaks for itself. The only thing not accounted for is that desktop clients will probably need to have a mini-server for offline editing (they’ll need to implement the Beyond API themselves, and then switch between calling it and the API on the server, depending on whether they’re editing online or offline). For offline editing, SQLite will probably be the best way to go.

I put these together in Illustrator and will hopefully have HTML versions before long. The second screenshot is what the error screen will (tentatively) look like, though of course the error text will change depending on the error.

I wish I had more time for this… :) But I’ll make time. I can’t get Beyond out of my thoughts (not that I’m really trying) — every day a stream of new ideas flows into my head. Today in class I started designing the database structure and will have some stuff to show pretty soon. The goal right now is to finish the interface design (which is coming along more slowly than I’d like, through no fault of its own) and then slap together a prototype with some real data so I can mold the system into what it needs to become.

It seems like genealogy and pedigrees are eternally bound together — you don’t get one without the other. And since Beyond is a genealogy app, it follows that it’ll have a pedigree.

So, I’ve been thinking about this a lot lately. What’s the purpose of a pedigree chart? The obvious answer is that it’s to be printed out and put up on your wall. But in the context of actually working on our genealogy, why do we use it? (This is keeping in mind that there are also individual detail views, family views, etc.) Here’s what I’ve come up with:

Pedigrees help you see the structure of your family tree, specifically your direct lines. They don’t offer all the details (like your grandfather’s brother’s children), but they do show you the basics — the branches if you will. The leaves are all the extra details that flesh out your ancestor’s life and make them more than just facts on paper, and they’re mostly found in the individual and family views. As part of showing the structure, pedigrees naturally show you where the ends of lines are, which is nice when trying to decide which part of your tree you want to work on.

Now for the disadvantages: as mentioned, they don’t show collateral lines (like your grandfather’s brother), just direct lines. It’s also very easy for them to get cluttered.

With the purpose of pedigrees in mind — showing the structure — I think the information shown on a typical chart can be pared down quite a bit. What’s most important? The person’s name and their place in the hierarchy. The dates and places are still important, but not nearly as much as the name. Nor do you really need a ton of information there on the pedigree, because there’s an individual view which houses all the detail. Let’s keep it as simple as possible.

So, the name. It probably ought to be the full name because that’s a good way to differentiate relatives who have the same first and last name (like John Franklin Crowder and John Preston Crowder in the Pedigree Sandbox example).

Because we’re not using the pedigree to enter data (more on that later), we don’t need the full gamut of dates. All we really need is an idea of when they lived, and the standard birthyear-deathyear (e.g., 1819-1871) does that for us. If the death year is missing, “1819-” would give the impression that they’re still alive, so “1819-????” is probably better. (”-unknown” would have to be translated into all the languages and we’ll avoid that if we can.) If the birth year is unknown but the death year isn’t, “????-1871″. And if both are unknown, then the date probably should be left blank. (I’ve thought about using another existing date instead, like a marriage date, but it may get confusing. In those cases the person’s position in the pedigree should give a rough idea of when they lived.

Now for places. One of the things that you can’t really model in PAF is where a family lived. You can model where major events in the lives of the individuals took place (birth, marriage, death), but you can’t say “This family lived in Montgomery County, NC from 1830 to 1892.” For now we’ll probably display a compact version of the birth place and the death place, separated by a slash (e.g., “Montgomery, NC / Anson, NC”). All you need is a general idea of where the person was, because remember, this is just the outline of our tree.

More on the family modeling thing. It would be pretty nice to be able to have information about the family as a whole, rather than just the individuals. The closest thing is the marriage event (that’s what creates a family), but I haven’t seen any software that lets you treat the family as a distinct unit rather than as a linking together of various individuals. I want to say, “This family was Methodist,” or “This family lived in Riverton for five years, then moved to Georgia for the next thirty years.” I’ve added an example of what I’m envisioning to the Sandbox. You’d be able to click on the family as a whole and edit it. The advantage of something like this is that you can see in pedigree form most of the information on a family group record, in a much more compact format (more families per page). Judging by this test, you’d probably only be able to show three generations per page before it got full vertically.

Oh, I said I’d mention alternatives to pedigrees. The cascading (”drop-line”) format is one:

(from http://www.sog.org.uk/leaflets/chart2a.gif)

I’ll see if I can figure out a nice, easy way to do something like that in HTML. I probably wouldn’t include places on a form like this, and the dates would certainly be compacted, because there isn’t a whole lot of horizontal room.

One last thought: it’s probably better to be for the charts to be more vertical than horizontal because people are used to scrolling vertically. Is scrolling good for something like this? I’ll have to give it some more thought, because I don’t think I’m making much sense today… :)

Technorati Tags: genealogy

I’ve created the Pedigree Sandbox page as a testbed for various pedigree ideas. Right now it’s just a simple table-based layout for two and three generations, at various sizes. And the code for the two-generation one is at the bottom (you can view source for the rest, though there’s not much different about it).

Here’s a two-generation layout:

And three-generation:

A little bit later today I’ll post about what I think of pedigrees (and some alternatives), which will explain the abbreviated form of the dates.

Technorati Tags: genealogy, pedigrees