Relatives is brand new genealogical software. It is a commercial product of GenealogySoft. GenealogySoft calls it "genealogical trees visualisation software". Version 1.0 was released on 2008 Jun 10, and its author, Andrei Douglas, announced the introduction to the soc.genealogy.misc and alt.genealogy list on 2008 Jun 25.
Relatives is a perfectly sensible name for a genealogy program and scores originality points for not starting with the letter A, F or G. It is a slightly annoying name, because Relatives is plural while a program is singular.
You cannot buy Relatives in a store, you have to download it from the
GenealogySoft web site. The site is bilingual. The two languages are not Russian
and English, but Russian and Amglish - the American variant of English. It
thus seems that, despite the bilinguallity, the maker is not really aiming at the international market, but at the American market.
Weirdly, GenealogySoft
uses the Union Jack as a button for the Amglish site. That is just wrong. The
site should use the Union Jack for English pages, or the Stars and Stripes for
its Amglish pages.
Further evidence that the makers are aiming at the American market is that GenealogySoft does not list the price in Euros, but in US dollars.
The site works with PayPal. If you follow the buy link, you may even get the impression that you have to sign up with PayPal to pay with VISA, MasterCard or AmEx. That is just PayPal’s suggestive layout, you can pay by credit card without a PayPal account.
When I first visited the site, my first thought was that was some Russian company making a bilingual product but that is wrong. The site does not list an company address, but its author lives in the United States of America.
The site does not impress in any way. It uses Windows code page 1252 instead
of UTF-8 and still uses frames. The page headers claims to adhere to the by now ancient HTML 4 Transitional
standard, yet the site does not validate against that low standard.
The worst part of the site is the menu. Instead of some normal menu, there is a drop-down
box to select pages from, and it does not work if you surf safely. You need to
allow scripting for this poor menu substitute to work.
Perhaps the site is not really ready yet. Firefox popped up a few warnings about an invalid certificate while I was browsing around.
The site offers three downloads; the full program, a demo variant and a
viewer. For all three programs, the download is roughly 8 MB
in size. You will need to buy a password to download the full program, the others
can be downloaded for free.
The viewer lacks the menus and dialog boxes for editing, but is otherwise identical. Although it loads GEDCOM files nearly as fast, the problems detailed below keep it from being serious competition to GENViewer Lite.
According to the web site, the demo variant has one limitation: you cannot save files.
It is not possible to upgrade the demo to the full program, but necessary to download the full program from the password-protected section from the site. GenealogySoft sells a password to download the full version. The demo does not have a registration dialog. The full version needs to be installed even if you are already using the demo.
I discovered that there are really two limitations. You cannot save your database as a file, and you cannot export to GEDCOM. The first restriction makes it impossible to evaluate the database size, file loading or file saving time. That last restriction makes it impossible to evaluate the quality of the GEDCOM export.
I started evaluation by downloading the demo setup package. It uses the lesser-known Excelsior installer It suggested a reasonable installation folder, but allowed me to change it. It creates a folder but does not create a desktop icon. It does ask whether you want to start the program when the installation is done. Installation went smoothly, the only small complaint is the inability to opt for a desktop icon.
I later downloaded the full version. You may need to be patient. After I
entered my email and password, it took about half a minute for the download to
start. The full setup does not detect the directory used for the demo variant,
but defaults to installing alongside the demo.
The demo defaults to installing in Program Files\GenealogySoft\Relatives Demo 1.0.
The full program defaults to installing in Program Files\GenealogySoft\Relatives 1.0.
The website and help file do not highlight this, but you can run the demo and
full version side by side.
The full program is personalised; it shows my name and email address in the about box. Neither the demo nor the full version bothers to show its version number in the about box.
The first thing I noticed after starting up is a empty maximised window. Some sessions later, it was clear that Relatives makes the annoying mistake of always maximising the screen upon start-up, even if you resized it before.
The second thing I notice, as soon as I Alt-Tab, is a horribly ugly icon. It is ugly even by the low standards of the early Windows 3.0 days. It is truly a reason to turn away in disgust, and I sympathise completely with anyone who decides to stop trying this program upon seeing its icon. The lack of attention paid to the program’s icon makes the entire product seem amateurish even before you tried it.
The copyright message in the about box is a bit of a puzzler. This is version 1.0, the very first release of the program, yet the copyright is 1998-2008. Perhaps it is a new name and version number for a program that used be Russian only? Anyway, Relatives has been in development for ten years? This should be good...
I asked Andrei Douglas about this. He wrote a program back in 1998, but it languished as he focused his attention on other things. The current version includes some of the same code, but most of it has been rewritten as he redeveloped the program during the past three years.
The menus look simple and there is a real Windows help file. Still, a quick browse through the menus is enough to discover that this program is still rather limited. It will import GEDCOM 5.5, but will not import any native formats, not even PAF. It will export to GEDCOM and HTML, but that seems to be the extent of its current reporting capabilities. There are no menus for performing consistency checks (born before died and so on) either. Well, it is a version 1.0 program.
Relatives’s tools menu is remarkable. It has menu items for the Strings Translator and Template Translator. A brief look in the help file confirms the suspicion that these allow you to translate the program’s strings and templates to another language.
The website claims that Relatives can handle practically anything; "There are tens of thousand relatives in your genealogic file? - Not a problem! The program can process trees of any complexity. And there are no restrictions like "a person cannot have more than two wives" or "an uncle cannot marry his cousin niece". In this program everything, as in the real life, is possible!.. ".
Sounds good, but I remember similar claims from other vendors and mercifully decide to start with the small GEDCOM file anyway.
When I try to import a GEDCOM, I get to see a rather startling import dialog box. Relatives’s GEDCOM import dialog box has some unusual options.
|The first option is for incomplete families - do you want to "make up
missing members" or "remove it"? Neither option gives me a warm fuzzy feeling.
An import should neither make things up nor remove anything. The default
is "make up missing members".
The way the import dialog box words it sounds bad, but it turns out that
Relatives simply adds a Unknown to an incomplete marriage records, which is
perfectly fine behaviour.
The options to "Correct wrong tags" and "Remove empty elements" are not reason for excitement either. I particularly wondered what "Correct wrong tags" really means (read on to find out). Both options are checked by default. Again, it turns out that Relatives does the right thing, the only real problem is the somewhat unfortunate choice of words for the import dialog.
There is an option to insert spaces before CONC lines, which should not exist. Inserting spaces there is wrong, but that option is necessary to account for the many other programs that get this wrong in their GEDCOM output.
The dialog box lets you choose the character encoding. There is a drop-down box with a whole list of character encodings, but you should not need to choose anything, as it quite correctly defaults to "use the header’s charset".
The import dialog box would benefit from slightly less worrisome text for the options and a help button that brings up the relevant part of the help file. I did not experiment with the options, but imported files using the default settings.
Loading the 1 MB GEDCOM took just 3 seconds. That makes it one of the fastest
GEDCOM import I’ve ever seen. Even more impressive is that the program did not
just import the data, but also reports on the trees that make up the forest in
this file. A small complaint is Relatives’s message may confuse a bit, because
it incorrectly uses "tree" and "branches" instead of "forest" and "trees"; "This file contains 4862 persons and 1700 families in 112 branch(es)"
[trees]. Relatives hen goes on to report the sizes of all the individual trees.
The GEDCOM import
reports some warnings. When I click the warnings button, there is just one
warning: "* Number of empty elements removed: 1111".
Relatives allows you to save the import log, but I do not consider that to be good enough. The program should save the import as the import progresses. As it stands now, any program failure during import will leave you without any import log at all.
Just how important the import log is, is proved by a later attempt to import the 3½ MB royalfam.ged file by Samuel Howard Sloan. That seemed to go fine until Relatives decided to stop with the message that "The GEDCOM file [is] corrupted or there is a program bug. Please contact the program maker.". Well, GENViewer Lite has no trouble reading the file to tell me it was created by PAF 5.2.18, so the defect is probably in Relatives, but without an import log, I have no idea what went wrong or why.
I wondered how basic or sophisticated Relatives’s analysis of the database is, so I made a GEDCOM file with a cycle of just three persons, and asked Relatives to read it. It discovered a forest consisting of one tree with three persons. It did not discover the cycle, but did not crash drawing the impossible tree either.
Once the import is done, the program does not show a list of individuals. There is a person list dialog, but it is pathetic dialog compared to the large and informative list that other genealogy programs offer. It appears to have been added as an afterthought. This program is visual. Its main window does not show a list, but a graphical forest of trees.
Relatives is not the first program to try the graphical approach.
GenoPro has been trying to do so for years, but still cannot handle anything but
small files, gobbles memory, takes it sweet time to display a tree, and
then still makes a horrible mess of the graphical display. Hereditree gets
a bit slow when you opt to show four generations in its main view. Geves cannot
even read a GEDCOM file without consuming all memory. Genea seems to get lost in
its own confused logic when it comes to reading and displaying anything. Geni.com
takes second to display even a few individuals and initially limited GEDCOM
import to files smaller than 5000 individuals.
Obviously, doing a graphical family tree interface is not as easy as the makers
of these programs thought.
GenealogySoft makes does not any ridiculous claims, and actually notes that "for
files with thousand persons the result can be somewhat disappointing".
Relatives did not take three second to load the files. It took three second to load the file, recognise the separate trees in the forest, auto-arrange these trees and display them. The test file had several solitary persons, and these dominated the main view, but when I zoomed out, I got the see the forest in all its glory.
Relatives loads data, analyses it, auto-arranges and displays a graphical tree in mere second. That is an impressive piece of efficient coding. Scrolling is a bit jerky, but that is my only complaint. Zoom in and zoom out appear to be instantaneous.
Of course, a file with less than five thousand individuals is hardly a challenge for
anything but the worst programs, so I quickly moved on to trying the 100k INDI
file. If the progress bar is any indication, the GEDCOM import either has multiple
phases or restarted several times. Anyway, the pure import time is just 25
seconds. After those 25 seconds, the program was drawing many boxes on top of
each other in the upper left corner of its window. That is disappointing,
as is it plain wrong. It lasted for another 25 seconds, then the drawing
stopped.
As you cannot start using the program until the screen drawing is finished, the
practical GEDCOM import time is 50 seconds. Well, with all boxes on top of each
other you cannot practically use it after those 25 second either, but that is
another matter.
Some quick math tells us that Relatives managed to import some two thousand individuals per second. That is very fast indeed. Once the repaint delay is fixed, Relatives might boast an import speed well above 1 MB per second.
Legacy Family Tree 7 takes more than an hour to import the 100k INDI GEDCOM, and its Tree Finder takes about seven minutes to identify the separate trees (and then gets wrong, probably because of import errors). Relatives does both, and follows it with auto-arrange, all in less than half a minute.
I first measured the import times using the demo, but those times are not representative, as the demo version does not save the database it imports. I later measured the import times using the full version - and ran into an unexpected problem. When I create a database and then import a GEDCOM, Relatives does not save the file. You have the save the database manually. To arrive at realistic import times that are comparable to the times measured for other programs, I timed the save operation and added that to the import time.
For the 1 MB GEDCOM, the import time is 3s + 12s = 15s. The 12 seconds to
save the file seems a bit long, but not really excessive yet. Once again,
testing with a big file revealed a program’s weakness. After clicking OK to save
the database, the save time for the 100k INDI GEDCOM started with the 25 second
redraw delay, and then took 6 minutes and 10 seconds, that is 370 seconds. That
is slow. So slow, that I could watch the file in Explorer to see the file size
creep upwards. By the way, that file size is a quite reasonable 43 MB, not an
excessive 440 MB like Hereditree.
Thus, for the 100k INDI GEDCOM, the total import time is a round 7 minutes,
which equals 420
seconds.
Relatives has a slow file save, and that slow save undoes the import routine’s speed advantage. Without the file save, Relatives beats them all, but with file save, it loses to MyHeritage Family Tree Builder 2.0, Personal Ancestral File 5.2.18.0, RootsMagic 3.2.5 and Aldfaer 4.0.
A complaint about the file save itself is that only shows a hourglass. That would be fine for a fast save, but a save this slow should show a progress bar.
There were import warnings. Relatives offered to save them, I opted to do so, and it then briefly seemed as if no import log had been created. It turned out that Relatives created the import log in the directory of the GEDCOM file. I am pretty sure I had selected another one, but did not bother investigating that small issue. I focused on the contents of the import log.
It is not hard to understand the first warning, "* Missed spouse (ID: P1) was
made up and added to an incomplete family (ID: F35396).", presumably the program
wants both a father and mother.
It is harder to see the logic behind the
second warning, "Missed father (ID: P2) and mother (ID: P3) were made up and
added to an incomplete family (ID: F21688). ".
After all, if the program were to
insist on adding a father and mother to every individual that has neither, it
would be stuck in an endless loop until it ran out of memory. Obviously, it does
not do that, so why does it insist on adding both a father and mother in some
cases?
I think the PAF GEDCOM is to blame for this particular issue. PAF databases may develop small inconsistencies, and as a result, a PAF GEDCOM may contain a marriage record without partners. I looked up marriage 21688 in the PAF file, and it does indeed appear to be marriage for which the partners were deleted. I have long since solved these database inconsistencies, but left them in the 100k database. Relatives is one of the few programs that detects and then acts upon this particular issue. Its message is a bit surprising, and not crystal clear, but it is accurate and reflects the attention paid to GEDCOM import.
The two warnings I mentioned occur multiple times, but are otherwise the only
two warnings in the import log, but for one. There is just one other warning, and it
is one I truly appreciate: "Wrong tag EMAIL changed to user-defined tag _EMAIL:
1 occurence(s).".
This warning shows that GenealogySoft treats the GEDCOM specification with a lot
more respect than most other vendors do. It is a little known and
underappreciated fact that EMAIL is a GEDCOM 5.5.1 tag, but is not a GEDCOM 5.5
tag. PAF 5.2 writes GEDCOM files that claim to be GEDCOM 5.5, but use GEDCOM
5.5.1 tags. Many other programs make similar mistakes, and few programs catch this
error. Relatives catches it and reports it correctly. Relatives’s decision to
treat it as a GEDCOM extension is correct too.
Relatives adds underscores to user-defined tag, is what happens when
you leave "Correct wrong tags" checked. That sounds quite sensible, but for one
thing. Surely, when the import is done, there are no tags anymore, but only
database records? Or is Relatives one of those program that makes the blunder of
inserting comments into your database?
I did a little experiment and was pleasantly surprised. Relatives does not add
unauthorised comments, but has a flexible database structures and actually
adds the tags it does not recognise to its database as tags.
I wondered just how flexible Relatives is. Relatives is not limited to the tags its author predefined, but allows you to add your own tag definitions. I did so for the tag I had added, but the results were disappointing. Both the program user interface and the HTML output continued to use the tag name instead of the label and description I had provided. I guess that is not entirely as intended.
GEDCOM export is speedy. Exporting the 100k INDI database to GEDCOM format took just
a few seconds. I am happy to report that the program did not bother with me a gazillion
options, as some other programs do. However, it did not ask me to pick any option at all, not even
a character encoding. I checked and found that Relatives exported the 100k
GEDCOM to ANSEL. That is a good choice,
but UTF-8 would be even better.
I later found that it is possible to choose the encoding, Relatives just doesn’t
ask when you export a file.
The GEDCOM file looks good, impressively so. Relatives’s flexible database includes all PAF extensions, and the export includes them too. Let me stress that: Relatives’s GEDCOM export reproduces the PAF-specific tags it encountered on import. This approach practically guarantees 100 % round-trip compatibility.
Like GenoPro, Relatives uses GEDCOM extensions to remember the positions of boxes on screen, but GenoPro’s extensions are illegal, and Relatives’s extension are not. Relatives respects the GEDCOM standard; all its GEDCOM extensions start with an underscore like they should. Relatives even changed PAF’s illegal EMAIL tag to _EMAIL to make sure its own GEDCOM files are okay.
Relatives uses quite a few extensions. I spotted _X, _Y, _MIN,
_MAX, _LEN, and _HLP, in addition to the _PRIMARY, _UID, _AKA, _ITALIC and
_MARNM extensions it imported from PAF.
When I imported a small Relatives GEDCOM back into PAF, PAF rather ungracefully
issued errors because it does not recognise Relatives’s extensions. The
Relatives extensions are perfectly legal, so PAF is wrong to issue errors.
Relatives retained the submitter information present in the PAF GEDCOM. If you make a new file, Relatives will prompt you to fill out the submitter record before its writes the GEDCOM file. That sounds better than it is. See, Relatives is not so user-friendly that it shows the dialog box you need fill out, it only tells that you need to fill it out.
Creating a submitter in Relatives is convoluted and far from intuitive
procedure. You are
not likely to guess how. You must specify the submitter in the file
header dialog box, but you cannot do so, until you create a submitter record,
and you must create that record in the Shared Record dialog box. Now, you can
create the record there, but that only gives you a weird dialog box for
that empty record. You
can select that empty record you created in the file header dialog and continue,
but you don’t want an empty record.
It took a bit of experimenting to figure out that you the select
"Submitter" in that weird dialog box, right-click it to bring up a context menu,
then choose the field you want to fill from
that menu..
Every time I switched away from the program, and then back to it, it would repeat the 25-second repaint. During this 25 seconds, the program hardly responds to anything else, be it a button click or a menu selection. This repaint delay was not obvious with the small file; for the small file, Relatives performed the repaint in just a second or so, and you need to be in a real hurry to notice that.
This repaint delay is a serious issue. It is quite annoying to have wait 25
seconds before you can select a menu item, have to watch another 25
second repaint because the menu overlapped the window, get a dialog box but then have to wait 25 seconds again because the dialog box overlapped the main
window...
This repaint delay makes Relatives 1.0 unusable for anything but small files.
Apart from the slow repaint routine and the jerky scrolling, Relatives is truly fast. Perhaps part of that speed is the result of trade-of between speed and memory usage, because its memory usage is not modest. After loading the 100k INDI, some 38 MB in the already inefficient GEDCOM format, and some 43 MB in Relatives’s own database format, the Task Manager showed Relatives to be using 700 MB.
Relatives 1.0 had no trouble importing the 100k INDI file, but it cannot
handle it. The redraw is not just unbearably slow, drawing all the boxes on top
of each other is plain wrong too.
I think
that Relatives tries to calculate something, perhaps the size of the canvas it
needs, its calculation
overflows, and it then ends up drawing everything in the upper left corner of
its window. I’d guess that it needs to use 64-bit integers instead of 32-bit
integers and that it will handle the 100k INDI file just fine when that issue
has been fixed, but when I looked at the GEDCOM output it seemed to be using
floating point numbers. Whatever it is that goes wrong exactly, the bottom line
is that Relatives 1.0 cannot handle the 100k GEDCOM.
The file header dialog box allows you to specify the character encoding that Relatives should use on GEDCOM export. It apparently defaults to the encoding of the file you imported. GenealogySoft surely means well, but that is just not right, as export to anything but UTF-8 or UTF-16 might lose data. You should be fine if you import and then export immediately, but if you edited the database since importing, it may well contain characters that the selected character set does not support.
The GEDCOM export dialog box provides the same extensive list of character encoding options that the GEDCOM import dialog box offers. That is perhaps the only spot where Relatives does not respect the GEDCOM 5.5 specification, which allows ASCII, ANSEL, and "UNICODE" (UTF-16) only. It does not allow MSDOS or "ANSI" and even explicitly forbids "IBMPC". The GEDCOM 5.5 specification omitted UTF-8, that oversight was corrected in GEDCOM 5.5.1.
Relatives’s support of UTF-16 deserves a small kudo. The "UNICODE"(UTF-16)
character encoding has been in the GEDCOM specification since GEDCOM 5.5, which
was released on 1995 Jan 2. Today, more than thirteen years later, the number of
genealogy programs that still does not support it is embarrassing. RootsMagic 3
does not support it. Legacy Family Tree 7 does not support it. Family Tree Maker
2008 runs on top of Microsoft .NET, which is a Unicode throughout, yet FTM2008
does not even support UTF-8.
A few other genealogy programs that do support UTF-16 are PAF 5, Ancestral Quest 12,
GenoPro 2007 and OhmiGene 1.6.
When I played around with the GEDCOM export, I came across a reason to wonder about the
quality of Relatives’s ANSEL support. The drop-down box for character encoding
in the dialog box that allows you to pick the character encoding for GEDCOM
export says "ANSEL = 7-bit ASCII", and "ASCII = 8-bit ASCII".
That is completely wrong.
ASCII is 7-bit, "8-bit ASCII" is a nonsensical contradiction in terms, and ANSEL is an 8-bit extension of ASCII. The erroneous dialog box is a serious issue already, as this character encoding stuff is confusing enough without erroneous dialogs to confuse you even more. It also raises the question how well GenealogySoft understands it, and whether they got this right.
There is no reason to worry about other conversions. Common conversions are provided in general purpose programming libraries (and Relatives seems to be using the java.nio.charset library), but ANSEL is not common enough to be included in those, so genealogy vendors must create and test their own ANSEL support.
I decided to do a few quick tests to determine whether Relatives support ANSEL
at all, or mistreats is as ASCII. I found that Relatives does not either
ASCII or ANSEL.
When you select export to ANSEL, Relatives actually exports to Windows ANSI.
When you select to export to ASCII, Relatives actually exports to Windows
ANSI.
You might think that Relatives really likes Windows ANSI, but when you decide
to export to Windows ANSI, Relatives labels it "windows-1252", which few other
genealogy programs are likely to recognise.
The UTF-8 and UTF-16 export seemed fine, and Relatives does use "UNICODE" for
UTF-16.
It is practically impossible to mess up an ASCII import, however you treat it, but the import should issue errors upon encountering non-ASCII characters. Relatives issue nu such errors, but bluntly imports everything as Windows ANSI.
Windows ANSI is imported as Windows ANSI, and although Relatives itself writes "CHAR windows-1252", it does not complain about "CHAR ANSI". It recognises both "windows-1252" and "ANSI".
Relatives mistreats ANSEL encoded file as Windows ANSI, thus mangling your data.
Relatives does not support ANSEL.
ASCII, ANSI and ANSEL are all treated as Windows ANSI.
When the file isn’t too big for Relatives to confuse itself on how to auto-arrange and draw the tree, you can zoom in and out, and click on any box to get a dialog box with information. These boxes seem to have all the information, but are in dire need of a redesign. The dialog boxes for lists are too small, most are needlessly complex and keep you clicking to get at the simplest facts. More often than not, getting anything done involves another dialog box popping up. There is a pop-up dialog box for editing the name, a pop-up dialog box for the gender, a pop-up dialog box for birth and death, one for notes, and so on. It is awfully awkward. Editing your data in Relatives is a far from enjoyable experience.
Sources are what GenealogySoft calls shared records. Submitter, repositories and sources are all shared records that must be created through the shared record dialog box. You have to do so by selecting the record type from a drop-down dialog box and then choose the create button. Once that is done, you have an empty record. You need to select and click the edit button. You then get a new dialog in which need to once again select the empty record. Once you’ve done that, you can right-click to get a context-menu. That context menu lists the available fields. To actually edit the record, you must choose one of those fields. You will then get another pop-up in which you can type a value.
Most of Relatives’s dialog boxes are like that. You cannot simply type a value into a field,
but must right-click and choose a field to get a pop-up, and do so again and
again, for every field you want. It is horrible.
The user interface presented by the dialog boxes does not need a redesign, it
needs a design.
The program appears to be bilingual, but when I try to switch to show Russian, it continues to show Amglish, even after a restart. There is an INI file, and it contains the line "lang=ru", but the menus remain Amglish. I tried this with both the demo and the full version, with identical results.
This program does not support any reports at all, other than its HTML output.
There are a few options, such as whether to produce one big file, or a separate file for each record. I simply went with the defaults, but will note that Relatives’s default for the character encoding is plain wrong. Web output should default to UTF-8, but Relatives defaulted to Windows ANSI (which, because of a typo, shows up as "ANSII", with double I).
Relatives once again impressed with its speed. It seemed to be done within two or three seconds of clicking the OK button, but I was not impressed by the quality of the output. The layout is pretty clean to look at, and the links works just fine, but there are many issues to complain about.
First of all, I doubt that many users who opt to have all records in a single file want the index to be in the same file as the records. That should definitely be a separate option. More annoying is that the display of the data is spoiled by the presence of GEDCOM tags. There should be no GEDCOM tags in reports. It makes for a reader-unfriendly report. Relatives should default to either user-supplied strings or leaving these tags out.
Relatives does not provide a choice of HTML standards, and it generates pages that do not specify any HTML version at all. It has thus excused itself from living up from even the HTML 4.0 standard, yet the pages it produces still does not validate. I’d barely qualify it as HTML at all. The SGML parser (the validator the W3C uses) reports 176.353 errors in the page that Relatives generated for the 1MB GEDCOM. That is 176.353 errors for a database with 4862 persons, and that averages to more than 36 HTML errors per individual.
I wonder how often I have to point this out before vendors grok that computer-generated web pages should be technically flawless. There is no excuse for errors in computer-generated HTML.
The failure to validate is not the only problem with the generated pages. There is a bit of CSS, but these are not CSS-styled pages. Instead, they abuse tables for layout and are full of hard-coded values and options. The HTML it produces is better than that of TMG, but that is faint praise indeed; I do not consider what TMG produces to be HTML at all.
Relatives is a Java program, so it uses Unicode internally, but it does not
automatically follow that it also stores your data in a Unicode format. Family Tree Maker 2008
is painful proof that use of a Unicode platform (Microsoft .NET in FTM2008’s
case) does not guarantee a true Unicode program.
Relatives will accept, save and store any character you manage to throw at it.
Relatives is a true Unicode program. Its database encodes all text in UTF-8, just like PAF does.
Relatives’s database is remarkably flexible.
It will happily accept any legal tag upon GEDCOM import, show that tag in its dialogs, and then reproduce that tag in its GEDCOM output. This ability is complemented by a dialog box that lets you define some tags, but that does not seem to work very well yet, so its reports still show tags instead of the strings you type in there. Reporting would benefit from an "ignore unknown tags" option anyway.
The GEDCOM specification allows a GEDCOM reader to ignore tags it does not recognise, so programs do not need to know about all the GEDCOM extensions that other programs use. However, when those tags are ignored, any information stored in these extensions will be lost. Some programs make the blunder of adding comments to your database for every tag they don’t recognise, which is really not what you want.
Relatives introduces a superior approach. It does not soil your database with ugly comments that show up in all your reports, and does not throw the tags away either. It does not violate the GEDCOM specification, but does better than the specification demands instead .It simply accepts tags as tags, so that they can be reproduced later. It is a great feature. All That’s missing is an informative message about these tags in the import log.
Relatives will import and export data that it does not even recognise or support. You can round-trip every legal tag through Relatives. Relatives even accepts illegal GEDCOM extension, it will just prefix them with an underscore to make them legal. You can switch to Relatives and back without losing any program-specific data.
Relatives’s flexibility in allowing unknown tags ensures maximum compatibility with both current and future GEDCOM specifications and extensions. I have not analysed it to make sure, but my initial impression is that the Relatives database format is so flexible that GenealogySoft can add new tags to a new version of Relatives without worrying about file conversions for an older versions of Relatives, or even with what version of Relatives anyone edits a Relatives database.
Relatives does not seem to use any database engine, but a proprietary binary format that is not unlike GEDCOM. Relatives does not use GEDCOM itself as some programs do, but its format does use tags and values. That is what gives it its flexibility in accepting tags.
There are two main problems with the database. The obvious one is that saving files is rather slow. The second one, compounded by the first, is that Relatives needs to rewrite the entire database whenever you make any change. Other programs save data as soon as you move away from a field or dialog, Relatives only saves data when you command it to save, and it does not feature an auto-save option. If your system were to crash in middle of an editing sessions, changes are that you lost all edits.
The Relatives program is written in Java. That sounds hard to believe, as
Java is notoriously slow, but GenealogySoft uses Excelsior JET to precompile the
Java code to native code. This results in performance comparable to that of C
and Pascal programs.
The compiled program does not need the Java runtime, but it does need the
Excelsior JET runtime - That’s the stuff in the rt directory. The Java code
seems to be using the Eclipse framework.
As mentioned already, the program does not appear to use any database engine.
The Relatives web site does not list the program’s requirements. The
Excelsior JET runtime it relies on requires Windows 2000 or better. It also
requires a 800 MHz Pentium III or better.
I’ve tested Relatives on a 2,7 GHz Intel Pentium 4 with 2 GB of RAM, running
Windows XP Service Pack 3.
Relatives is a Windows program complete with an installer and a Windows help file.
As the quality of the GEDCOM export determines whether it is wise to use this
program at all, the inability to examine its GEDCOM export for yourself with
your data is
good reason to disregard the program.
GenealogySoft would be wise to pick another demo limitation.
The GEDCOM import dialog box needs a help button, and the program should write the import log without prompting. The raw GEDCOM import is impressive, but undone by a slow database save.
Relatives 1.0, a new program from an previously unknown company, seems to have the fastest GEDCOM import of any genealogy editor, but its particularly slow file save makes that it still has to bow to MyHeritage Family Tree Builder 2.0, Personal Ancestral File 5.2.18.0, RootsMagic 3.2.5 and Aldfaer 4.0.
Relatives supports UTF-8 and UTF-16 ("UNICODE"), but it does not support ANSEL. It claims to support ANSEL, but it does not. It does not really support ASCII either. ASCII, "ANSI" and ANSEL are all treated as Windows ANSI. The practical upshot is that Relatives will mangle your ANSEL files upon import.
Relatives uses UTF-16 internally and encodes its databases in UTF-8; Relatives is a true Unicode application.
The inability to register the demo program and then continue is a drawback. The need to download and install the full versions when you are already running the demo is quaint to say the least, but you can run both variants side by side.
I do not think Relatives deserves the 1.0 version number yet. A genealogy program without ANSEL support simply isn’t ready yet, but there are some very good things about this program.
It is a Unicode application. It respect the GEDCOM specification. Its flexible database will round-trip tags it does not recognise or support. It imports fast, and its import routine produces accurate error and warning messages. It performs graph analysis to recognise the trees in the forest, and then auto-arranges all these trees on screen, and does all that in mere seconds. Zooming in and out works well - and fast.
I wish it responded to the mouse wheel, but That’s just my personal
preference. There are some real complaints about these features; The display of
big trees is too slow and scrolling is jerky.
Slightly smarter display code would solve the display speed issue, and perhaps
the jerky scrolling with it. It would even boost it practical GEDCOM import
speed of large files to above 1 MB per second. Well, if the creeping slow file
save is fixed too.
Other than the Unicode support, GEDCOM respect, flexible database, fast import, accurate messages and fast auto-arrange, the program is a big disappointment. Its otherwise excellent GEDCOM support is marred by its lack of ANSEL support. Its database save is so slow that undoes the import speed advantage. It is short on features, has extremely poor HTML export and no other reporting options. Its icon is incredibly ugly and its dialog boxes are astoundingly awkward.
The ability to translate the strings and dialog is nice, but translation of any dialogs makes little sense until GenealogySoft spends some time to actually design proper dialogs to replace the current right-click and pop-up mess.
A real killer is Relatives 1.0’s inability to display large trees correctly. The graphical tree is the main user interface, so when that doesn’t work, the program is practically unusable.
The issues with this program are too many and too serious to recommend it to anyone, but I am not unimpressed. The quality GEDCOM import and export, fast graph analysis, speedy auto-arrange and quick zoom are, notwithstanding the few reported issues, an impressive core to build on. GenealogySoft has managed to do what many other companies have failed at; build a graphical genealogy editor that actually works.
The program’s core is evidence of programming skill and dedication, but the
rest of the program has not enjoyed the benefit of similar attention to quality.
The dialogs are horrible.
There is serious potential here. If this product improves with subsequent
versions, it might well become a serious rival to established products. The
impressive core is embedded in a rotten shell, but it is still a most promising
1.0 release.
Andrei Douglas has confirmed that a defect in Relatives prevented it from loading the royalfam.ged file I tried. This defect has been fixed and Relatives 1.1 will load the file.
The website now sports the Stars & Stripes, and uses button instead of a drop-down box, and navigation no longer requires JavaScript. The install for version 1.1 does not detect 1.0, but simply defaults to another directory. The install still does not make a desktop icon. Relatives still maximises on start-up. The about box shows a version number now, which is 1.1.0.1. Saving files is way faster now. The 1 MB GEDCOM saves in about a second, and the 100k INDI GEDCOM saves in about 5 seconds. The 100k INDI still does not display correctly, but the scroll of smaller files is smooth instead of jerky now. The core has definitely improved.
Relatives 1.1 adds support for export to Scalable Vector Graphics (SVG). SVG is web standard, so this is ideal for web pages. Internet Explorer 7 still does not support it, but IE users can install Adobe’s free SVG viewer. Relatives’s HTML with SVG output is supposed to prompt for installation, but that does not work right yet.
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 3s | 50s |
| time in seconds | 3 | 50 |
| INDI per second | 1.620,66 | 2.001,34 |
| bytes per second | 351.965,00 | 775.987.86 |
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 15s | 7m00s |
| time in seconds | 15 | 420s |
| INDI per second | 324,13 | 238,25 |
| bytes per second | 70.393,00 | 92.379,51 |
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 3s | 50s |
| time in seconds | 3 | 50 |
| INDI per second | 1.620,66 | 2.001,34 |
| bytes per second | 351.965,00 | 775.987.86 |
| file | 1 MB GEDCOM | 100k INDI GEDCOM |
|---|---|---|
| time | 4s | 55s |
| time in seconds | 4 | 55 |
| INDI per second | 1.215,50 | 1.819,40 |
| bytes per second | 263.973,75 | 705.443,51 |
| property | value |
|---|---|
| product | Relatives |
| version | 1.0 |
| organisation | GenealogySoft |
| website | GenealogySoft: Relatives |
| price | US$ 29,98 |
| requirement | Windows 2000 or better |
| note | |
| Verdict | impressive core in rotten shell |
| Rating | promising |
Copyright © Tamura Jones. All Rights reserved.