PhpGedView Update

I've been tweaking PhpGedView's configuration and I am generally much happier with it.

I disabled the autocompletion for location names so editing is much smoother. It seemed to query the server on every keystroke which was ridiculously slow, even when accessing the server on a LAN.

I configured the site as "family only" since every family has a few skeletons in the closet. ^_^ The default setting was reasonably private but anyone could browse site, which might make some members of the family uncomfortable.

There were a few other changes, but actually finding these configuration settings took more digging than I expected. The UI really is not very well designed. But it is usable which is all that matters for now.

PhpGedView still has some annoyances that cannot be magically reconfigured out of the way. One issue is the amount of network traffic it generates. It really is quite astonishing given what the application does.

Now comes the hard part. First is convincing my family to try it. Second is teaching them how to use it. What have I gotten myself into?!

PhpGedView

I finally got around to installing a private instance of PhpGedView 4.2.4 for testing. Usage is definitely not intuitive, but I got going by reading a little of the manual. While the learning curve is not huge, it will prevent most members of my family from getting started without significant hand-holding.

As the name implies, PhpGedView uses GEDCOM files and in fact you must have one in order for the system function correctly. Fortunately, PhpGedView can create one for you if you are just starting out, but this step was not obvious without reading the manual. This process creates an initial, nameless, individual which I struggled to modify initially before getting it to work.

PhpGedView uses a RDBMS for main storage and only updates the GEDCOM file automatically for certain trusted users. An administrator must accept and push the changes of other users. The administrator can also import and export the file easily, which allows the database to be maintained in a completely separate application.

The PhpGedView UI has a few annoyances, such as opening input forms in a separate window. I hate it when web apps do that. The JavaScript input validation on some fields appears to work on keystrokes which causes lots calls to the server. Needless to say this is extremely slow in a CGI setup. Even worse, the validation pops up meaningless database error messages. On one form, the JavaScript causes the you to jump around the entry fields in a most illogical sequence.

However, despite these annoyances, PhpGedView is quite usable and satisfies my immediate requirement of having a common place to record the family history, which is haphazardly written on bits of paper scatted across different continents now. More importantly, the fact that the data is portable means we are not locked into PhpGedView if we find something better in the future.

Other Genealogy Software

Now that my brother and I are not no longer considering Gramps, what other options are there? Well, one benefit of free software is they often don't mind telling you about the competition. The Gramps wiki has a page conveniently entitled Other genealogy software. ^_^

Looking through the list, the one I'm going to try next is PhpGedView (screenshots). Yeah, yeah, it's PHP, but that's what a lot of web apps used in the old days. ^_^

At least this one explicitly says it works with PostgreSQL, which is important since I don't want to run two database servers. Strangely, PHP developers seem to prefer MySQL almost exclusively, even though database agnostic PHP libraries have existed for ages now. Maybe it's because LAMP sounds cooler than LAPP. ^_^

I didn't have time to install PhpGedView today. I'll report back once I get "a round toit".

Gramps Web App

I've been trying to set up the Gramps web app but it's not very promising. The first problem is that Gramps doesn't follow Python common practices. I was surprised to find Gramps uses autoconf and make instead setuptools. The Gramp web app uses Django but if you run the usual command python manage.py runserver, it doesn't work unless you also set the PYTHONPATH environment variable to point into the source tree. Granted, the correct command is executed when you do make run, but why obfuscate things for someone who knows Django?

Anyway I did get the web app to run, but only after I modified the hard coded default locale setting, since I don't have en_US.UTF8 installed on the system. However I still can't login because the Django cross site scripting code complains that the cookie has not been set.

At this point, I gave up for the time being. My impression is that the Gramps web app is not quite ready for prime time. I was going to suggest you look at the web app demo site, but it was down at the time I wrote this.