Short answer: I have no idea.

For the main county-by-county sequence, I have tried to arrange the entries in possible 'household' groups -- ie all the children of each set of parents, arranged in marriage-date order.

Unlike Rootsweb's WorldConnect, or the LDS's Ancestral File, there are no connecting links between records in the IGI. There is therefore no firm evidence that the John and Ann Heald of one record are any relation to the John and Ann Heald of the record before. Any implication that they are should be taken with a substantial health warning.

Attribution is even harder when early records list only the child's father, leaving it open as to whether the parents are John and Ann, or John and Mary. In such cases I have tried to list all the 'John Healds' together, even though this may lead to a long deviation from the main sequence of marriage-date order.

My aim for the listings here is to try to make it easy to see whole probable family groups at a glance, with less record duplication than in the online database, and to restore some of the browsability of the microfilm version of the IGI. Above all, I hope it helps with the question 'what other Healds were living nearby at that time ?', which can give useful leads to otherwise unknown siblings or cousins.

Please respect the fact that to be a valid copyright "fair use" of the transcribed material, the underlying data here is provided as a piece of noncommercial scholarship only, exclusively for the purpose of assisting further noncommercial scholarship, and it must not be used in any way prejudicial to the interests of the original copyright holders.

The IGI includes data from many individuals and different sources. Where these are in conflict, I have tried to preserve all the variants, even those which appear obviously unreliable or erroneous (I have tried to flag the most likely errors).

It is useful in itself to know that there are a range of different variations all in circulation; and it removes a possible source of confusion, if it is a 'non-standard' variation that the reader already knows.

Most importantly, explanations may later arise for the different variants -- they may refer to different parents, or different children, or different events. But, once suppressed, information is hard to recover. I have particularly sought to preserve variants with slightly different dates.

This is the LDS batch number for the transcription of a parish register.

Because the parish records have been compiled and transcribed systematically, they may be more reliable, especially date-wise, than other sources.

I have used this when the item occurs in one or more of the contributed family-history LDS records, but not in the parish register entry.

Important note: The contributed record may or may not be accurate: the [ ] implies only a variant, not an editorial correction.

I have also occasionally used backslash \ to combine different contributed variants.

A contributed record may list the (assumed) village or settlement where a family lived, rather than the strict parish name.

Some parishes contained several churches. (For example, the chapel at Macclesfield was originally part of the parish of Prestbury). In some cases the chapel's register books may have been transcribed into the IGI, as well as Bishop's transcripts for the whole parish.

In the nineteenth century, civil registration adds a further level of possible names. The indexes for the national (GRO) registers give a 'registration area', not a town. The registration areas were typically the size of one of the old county hundreds, and might include several villages, as well as a town which gave the area its name. Local indexes (eg CheshireBMD) may also/instead give a registration sub-district. Thus a birth in Tarporley in Cheshire might be listed as in the Bunbury sub-district (info from ChsBMD), or the Nantwich registration area (from the GRO index).

If there is a GRO link for the event, this will link to a page at FreeBMD, which in turn will have links straight to a list of the villages in the corresponding registration area. Lists are also available at Genuki and (for Cheshire) at CheshireBMD.

This might indicate a birth (no batch number), followed by a christening (with batch number).

Until 1752 the legal and civil new year officially started with the Feast of the Annunciation, on March 25th. The day after December 31st it was officially still the same year, so December 31st, 1609 was followed by January 1st, 1609 "Old Style", not January 1st, 1610. A child could thus be born the next month in February 1609 (OS), ten months after a marriage dated April 1609.

A date March 5th, 1650 in the IGI may thus represent either a "New Style" corrected date (it really was 1650 NS) or an "Old Style" uncorrected date (ie 1651 NS)

The date might even have been mis-corrected from 1649, either by human error, or software confusion -- 1649 (NS) might have been entered as 1649-50, meaning "either 1649 or 1650 (calendar uncertain)", and then fixed by a computer as 1650.

To make things even more difficult, note that both year-styles were in popular use well before 1752. Scotland had legally switched to the 1st Jan New Year back in 1600. The confusion was contemporary, not just present-day.

If the year starts in March, then by October (or 8ber) it is indeed the 8th month old-style, rather than (new-style) the 10th.

The Quakers in particular disapproved of the traditional "pagan" month names. Thus, according to Quaker records, "John Heald of Morley, in Pownall Fee, Cheshire, a husbandman, married Martha Foden, of Morley in Pownall Fee, 11th mo. 15, 1701" (heald04 database at rootsweb, I2709).

In the absence of additional external information, a definitely correct interpretation may typically not be possible. The above probably means 15 Jan 1702 (NS); but it might mean 15 Nov 1701. It is hard to be sure either way, unless there are any adjacent records which spell out the month in words; or have a clear split date 1701/02; or contain a date like 30th Mo.2 (definitely not February). Secondary sources which do not quote the date in full as originally given will often (usually?) get it wrong.

Given a choice between different spellings, I have chosen the spelling used in the parish register.

Principally this is another example of trying not to erase information carelessly, when it could be easily preserved; and trying not to impose certainty where there may be doubt.

Any well-specified system for processing genealogical information should be able to cope with diverse name spellings.

Also, I thought they were more picturesque.

This is a consequence of standardising Sandy to Alexander. Similarly, Hannah and Nancy are listed with Anne, Ellen with Helen, etc.

The full list of name variants recognised and standardisations used can be found in the files boys.dat and girls.dat in the directory code/data/. These are derived in part from the name variant lists on the Wirksworth site.

The lilac colour highlights marriages, picking out the date and the Heald partner.

The orange colour is a warning of contributed data from the IGI, rather than data from the LDS programme of parish record extractions. It may or may not be as accurate or as systematically proofread.

Orange in the middle column highlights approximated birth records. These may be relatively accurate, eg by calculating back from an age at death; but more usually they are placeholders estimated from marriage information, typically 25 years before the marriage for a male or 21 for a female (the exact figures can vary according to which program generated them). When this appears to be the case, I have tried to place them next to the corresponding marriage.

The approximations may be based on genuine information, not otherwise present; the entries may include other relevant side-information -- eg place of residence -- which would otherwise be lost; and they may usefully indicate that whoever submitted this individual to the IGI couldn't trace their ancestry back any further.

On IE5 you can choose to print background colours by selecting:
Tools > Internet Options > Advanced > Printing: Print background colours and images

On IE5 the text size in printouts also changes when the display text size is changed: so a choice is available between increased readability and decreased consumption of dead tree. Even if the text becomes unreadably small on the screen, it may be still be quite clear when printed.

Landscape-style printing may not use that much more paper than portrait-style. Although there are fewer lines of print on each page, there are also fewer lines of data which have to be split in two.

Some web-browsers choke if they are fed very long tables. Breaking the pages into short tables gets them on-screen faster (they take about half as long to be formatted); but it means that each table is rendered independently, with a different set of column widths. When I have tried to provide some hints, these tend to be over-ridden.

One alternative would be to use a fixed-width font and pre-format the data, but in the simplest implementation this would require some fields to be harshly truncated.

If any HMTL experts can suggest improvements, they would be very welcome.

In short: because I wanted to make the site available as soon as I thought it could be reasonably usable.

I have started to add backward and forward links from marriages to births and vice-versa; but without hard data these are inevitably very speculative, and I am reluctant to go too quickly into something which could be damagingly misleading.

This situation may change if enough people (ie you!) can send me well-researched family trees.

Ultimately, it would be nice if links could be created from each chronological entry to a corresponding location on a graphical family tree; with a separate tree and homepage for each branch of the UK Healds that has been researched.

This would make very good sense -- watch this space!

I am thinking at the moment about how to turn the whole database back into a big Gedcom file, and uploading it.

Bzip2 analyses the whole file before making a compression code-book for it, unlike Gzip or PKzip, which build up their code-books as they work though the file.

In this case the pages are unusually repetitive, with the same names and phrases and HTML strings coming up again and again. Bzip2 wins out over Gzip by a much larger margin than usual, because it assigns more efficient codes to the critical few items which account for an unusually large proportion of the content.

Just how many of the Amazon customers who bought title X ever did buy one of the others as claimed... ?

But if you insist: Given a statistically large number of questions, these are the ones that might have been asked most frequently (assuming the ensemble of questioners hadn't first read the friendly manual).