O, the joys of being busy. ~sigh~ Midterms are at it again, along with a myriad of other projects (designing wedding invitations for an old roommate, deadlines at work, etc. etc. etc.), and so not much is happening right now. Three more weeks and school is over. But waiting for good conditions is a bad idea, because in all reality, do good conditions ever really come? No. If it’s going to happen, it’s got to happen in spite of everything else that’s going on. I’ll have to manage my free time better. Since I haven’t fixed my laptop yet, I’ll try to do most of my designing and mental work at home, where all I’ll need is pen and paper. And then when I’m actually up here at work I can do the coding and HTML mockups and the other “real” stuff.

I’ve debated whether I ought to be so open with the inner workings of this project (especially when it’s not so flattering), but I’ll stay true to the original vision: leave this historical record behind of how Beyond came to be. Struggles and victories alike will be written, for I intend this to be a true-to-life tale of how a web app was born. (And since it’s not commercial, there’s no need to worry about trade secrets flying away.)

Yes, development is coming along very slowly, and that bothers me a great deal, but that’s reality when one is doing this on the side (in addition to school and a job). And that’s okay.

Anyway, enough philosophizing — I need to get to study for those midterms so I can take them tomorrow and get back to work on this.

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.

Beyond is now on Sourceforge:

https://sourceforge.net/projects/beyondproject/

This means we get Subversion access. :) I’ll look through the other Sourceforge offerings and see what’s worth using. (In general, though, I shy away from it because their site is really cluttered and not very pretty and it’s hard to find what you need.)

Next I’ll need to install Trac for bug tracking…

Technorati Tags: Subversion, Sourceforge, Trac

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.

Before long I’ll need some data to work with. The easiest way to get that is to write some code that’ll convert a GEDCOM (which is easily exported from PAF) into XML or, even better, SQL code that will place it directly in a database. And turns out there’s already some stuff out there.

Ruby Quiz #6 is a GEDCOM parser, and there’s plenty of interesting code there to look through. There’s also Jamis Buck’s GEDCOM/Ruby Module, which I downloaded but haven’t had time to look at yet.

Part of me wants to write everything myself, but that’s stupid (unless the existing stuff is poorly done, of course). So I’ll evaluate the existing code and see if any of it fits the bill. Hopefully it does. :) Eventually I’ll have to write a PAF importer/exporter, though, because I’m not aware of any open source projects that do that.

Anyway, the important thing right now is to get some real data into the database (which means designing the database structure…) so I can get the prototype up. Time is the hard thing right now, with school crunching in (midterms are this week) and tight work deadlines. But that’s okay.

One last thing: coding Ruby in TextMate is really fun. Seriously. It’s something I haven’t experienced in a while, but it’s such a pleasant thing that it draws me back and makes me want to code more. That’s good. :)

Technorati Tags: Ruby, GEDCOM, XML, PAF, TextMate

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