Humphrys genealogy

Genealogy research by Mark Humphrys.


Hypertext Indented Narrative format - Followup paper


Hypertext for 1-name studies
v.
Hypertext for family histories

A reply to John Bending.

Mark Humphrys

Computers in Genealogy 7(3):121-8 (Sept 2000)




Introduction

Since the explosion of the Web in 1993, every field (and especially genealogy) has seen a rush to put data online in HTML form. How hypertext should best be used to structure and present the data in each field is a topic all too rarely discussed, so this is a most useful debate. Genealogy in particular is a field that suffered by being confined to paper, and we are now in an exciting era of experimentation with ways of presenting these complex data structures online.

In [1] John Bending described the scheme he uses in his website [3]. I did not consider this scheme appropriate to my needs, and presented a quite different scheme in [6] which I use on my own website [7]. Bending and I then engaged in a most useful correspondence. His conclusions are presented earlier in this issue [2], while mine are presented here. What is useful may be as much the debate as either scheme itself - both of which will no doubt continue to evolve.


Purpose of site

Firstly, Bending is correct that we have a different purpose in mind. But it is not famous people versus not-famous people. Rather, it is connected genealogies versus disconnected lists of names.

Bending's is a 1-name study, with large numbers of disconnected individuals. Some individuals are connected to others, and some genealogies can be traced through the site. But the site does not try to isolate these genealogies. Rather they are interweaved with all the other disconnected individuals, and the main layout remains alphabetic. The "Personal Histories" [4] is as close as the site comes to an isolated pedigree layout. But there is no clear separation between pedigrees. e.g. The Bovett family begins on p.104 [5]. Joan Carnell and Mary Turpin belong to this new Bovett pedigree, while Mary Bond belongs to a previous pedigree. But it is almost impossible to see this.

In contrast, I do not do a 1-name study on any of my surnames. I am only interested in presenting a connected genealogy of people who are provably related to the family, e.g. see O'Mara [8], so that all individuals are connected by blood or marriage, on an interconnected pedigree spanning many different surnames. Sometimes I will include people who are probably related to the family, but even then I will try to format them as smaller connected genealogies if possible, e.g. see Maltass [9] or Gibbon [10]. It is simply not true that these are all (or even mainly) famous individuals. Certainly, my format is useful when there is a lot of biographical material, e.g. see Alderman Michael Flanagan [11] or Arthur Gibbon [12]. But it is also useful simply to structure large and complex family trees, with little biographical material included (either by necessity, or just by choice), e.g. see O'Rahilly [13] or Eagar [14] or La Fontaine [15].

My target is connected genealogies of individuals (whether famous or not). Bending's target is disconnected lists of names in an exhaustive 1-name study. He aims to provide an objective list of source material for the target surname, including the original sources (census, GRO, etc.) in date/alphabetical order, for use by people researching that name. I aim to provide a site whereby the history of a particular family can be read. These are quite different aims.

Incidentally, I wonder if, even in a 1-name study, it might make some sense to put some effort into making readable the pedigrees that can be reconstructed, and perhaps isolate these from the disconnected ones. e.g. See my small list of miscellaneous Gibbons [16].


Virtual pages

I simply disagree that having multiple "virtual pages" on a single real web page is not confusing. When you arrive, the target may be at the top of the screen, but any scrolling by the user will rapidly lose that position. Often, you scroll down to read more, then scroll back up. Or you scroll up to see if there is any context or to find a title / search box / list of contents, etc. Next thing you know, you have lost your position and the target text has distracting material above and below it.

Also, if you link to an anchor towards the end of the document (or if it is a short page), the browser doesn't even display the target at the top of the screen to begin with, but rather it is surrounded by distracting material from the outset. Admittedly this is a browser issue - see discussion in [20]. A trick to fix this used by some authors (including Bending) is to add a large amount of vertical space at the bottom, e.g. see Cecil James Bending at: http://www.jbending.demon.co.uk/notes38.htm#8228 or George Bending at: http://www.jbending.demon.co.uk/notes71.htm#9941. This trick may not work, though, if the viewer has a different size screen and fonts. On my Netscape for UNIX browser, for example, the vertical space used above is not enough to bring the targets to the top of the screen.

Finally, as I mentioned in the article [6], what if each virtual page has its own embedded images, list of links, and other miscellaneous additions? Imagine combining Capt. Robert Gibbon [17] and his son Arthur Gibbon [12], with all their associated images and additions, into 2 virtual pages one above the other on 1 web page.

You might say you would never combine such complex pages. But the point is they would have started small, and been put together as 2 virtual pages on the same web page. As they grew and gathered additions, either the web page gets more and more confusing, or else you break the web page - and thereby lose permanent URLs.

Whether it is just me who finds virtual pages confusing, or whether others do too, requires a proper study by web usability researchers. But certainly no one could claim that virtual pages have better usability than isolating the information on its own page. So why use them?


Permanent URLs

As Bending notes, I am not opposed to multiple people per page - indeed, that is the scheme I use myself. Rather, I am opposed to "virtual pages" where the virtual pages above and below the target may be distracting, out-of-sequence, or even entirely irrelevant (pages from a different pedigree).

Page or "virtual page" content

Bending has a system whereby the information for an individual is spread across a number of virtual pages, each on different real web pages.

For example, take Cecil James Bending on: http://www.jbending.demon.co.uk/notes38.htm#8228. On that page is some biographical information which is found nowhere else. On a separate page: http://www.jbending.demon.co.uk/zphotocecil.htm is an index of photographs, which refers you to 2 further pages. On yet another page is his list of issue: http://www.jbending.demon.co.uk/family16.htm#h8228. And on yet another page is full details of his dates: http://www.jbending.demon.co.uk/diary72.htm#8228.

Under my scheme, all this information (including the photographs) would be on a single page, something like: http://../Bending/cecil.james.html. For example, see Capt. Robert Gibbon [17] at http://../Gibbon/capt.robert.html. Or see Frank Flanagan [18] or Dick Humphreys [19].

Bending says his scheme is appropriate "for ordinary, relatively insignificant persons, where we want to see the basic information first, before incurring the liability of a long download time, and if interested can then link to more details and to illustrations." But this is only true when you are making your first hopeful search for someone that you don't know is connected. Once you have connected to a family and want to actually read its history, you don't want to have to pick your way through hundreds of tiny virtual pages. You want a relatively small number of pages on which the history is presented in an integrated manner.

I can see the motivation for having multiple views of the same data, but sometimes "less is more", and it is easier to read a family history when you are not presented with a thicket of links to click through. For a discussion of why too much clicking is bad usability see [21]. In my system, not only do I reduce each pedigree to a relatively small number of web pages, but I use bold links to highlight the most important links for the reader to follow from each page, to help them cut down further on the number of choices.

All links are now bold. Structural links use this style.

A related question in Bending's model is, if I want to link to Cecil James Bending (e.g. when referencing him in some other text), which of those many pages should I link to?

Even if you can name the "recommended entry point": http://../pageNNNN.html#MMMM, who is to say the database won't be renumbered some day, and the link target become meaningless? Doesn't the URL http://../Bending/cecil.james.html inspire more confidence that it will always exist and point to what we want? Also, such a URL gives some idea of what to expect at the end of the link, adding to usability. See discussion of URL usability in [22].

The reader may feel that we can't use identifiers like: http://../OMara/james.html because they won't be unique - there will be multiple people called James in the family. The answer is that we only need URLs for the tiny minority of people in the family who get their own web page - the others will appear packed onto someone else's page. Less than 5 percent of the family gets a page named after them and so needs a unique identifier. For pedigrees like mine, only showing people provably connected to some family, this naming scheme works fine. For a 1-name study, with many pedigrees all of the same surname, there might be more uniqueness problems.


External Hyperlinks

It is simply not true that external hyperlinks are only for famous families. I would hardly describe my Flanagans, O'Rahillys, Gibbons and Maltasses as particularly world famous, yet I find there is a vast amount of information online that can enhance and augment their family trees. It is simply a matter of being creative.

To illustrate, I will take Bending's own tree. For instance, William Bending was baptised at Ottery St Mary. Why not link to a map of the area to show where this is? John Henry Bending was born at Carysfort Road. Why not link to a street map of the area so that the reader can see where it is? Charles Garnet Eden was educated at Magdalen College Oxford. Why not link to its site so that the reader can read further about it? George Bending died in WW2. Why not link to his entry at the Commonwealth War Graves Commission? James Bending died in the Boer War. Why not give some historical background by linking to the Yahoo category for the Boer War? Exeter City Library is referenced. Why not link to its site where we can see the address, opening times, etc. - in case we want to visit to follow up that reference. And shouldn't the GRO index actually link to the GRO? And the census index actually link to where the census information is held? And so on.

And every tree, no matter how obscure, intersects with some other. For instance, I note that Mary Bending has an entry in the LDS Ancestral File. Why not link to it? Indeed, in another part of the article Bending says it is important to share with other researchers who are interested in the same material. So you cannot then claim that there will be no external links. For more on the neglected art of linking see [23].

Bending says his database system can include hyperlinks, and illustrates with an invisible, unlabelled asterisk on the page: http://www.jbending.demon.co.uk/othersbi.htm. This page illustrates perfectly why I do not use databases. As I said in the original article [6]:

"For many of us, committing to a database means a fear of having to interact with our data through a narrow set of pre-defined menus. Consider the problem of embedding hyperlinks in our data .. We may understand what a hyperlink is, but we have to wait until the database understands before we can use them. Hence the impoverished linking of almost every genealogy online today."

Family trees by hand

By "as little duplication as possible" I am referring to what the author, writing by hand, has to write and maintain, not what may be generated from the data later.

I accept that a database is perfect in this area. e.g. With a database one only has to enter a date of birth once, and it is propagated throughout the database.

Whereas anything written by hand may risk some duplication being necessary for clarity. e.g. With my scheme one may need to enter and maintain 2 copies of the birth date - 1 on the individual's page, and 1 on their parents' page (if different). I believe I have reduced the number of such duplications to the absolute minimum necessary.


Sharing information

Bending points out that with a common format like GEDCOM you can share family tree data. In my article [6] I argued that you should link, not share. Bending counters that he can bundle his database onto a CD-ROM, so that it can be read offline "without the delays and cost inherent on access through the Web".

Of course, it is possible to do that with any set of web pages, including mine. Bending reminds me that I should set up such a system myself, whereby my entire website can be downloaded as a single zipfile, unzipped onto local disk, and then navigated offline. I will set up such a scheme shortly.

I still maintain that sharing - taking your own, soon-to-be-obsolete snapshot of the data that someone else is working on, instead of just linking to the always-up-to-date version online - is very old-fashioned. Remember that links do not have to be either public or point to public things. Links can be embedded on public or private web pages, and can point to public files on the Web, or files on the Web protected by password, or even to local files on disk. I have both public and private pages, pointing to pages in all 3 of these categories.

The only reason I can see to take your own snapshot of the data is as insurance in case the website vanishes someday. In which case you can simply alter your links to be private links pointing to your local copy on disk. This should be just a simple text substitution, changing something like:   http://site/User/   to:   file:///C:/My Documents/Backups/User/   throughout your pages.


Conclusion

My system is not designed for the presentation of page after page of disconnected entries from original sources, as Bending most usefully presents. But I do maintain that if you actually want to read a connected pedigree, something like my system is preferable.

This has been a very useful debate. I hope I have not been too robust in my comments! My experience in science is that the most enlightenment comes not from the presentation of one point of view, but from vigorous debate between two or more hotly-defended points of view.





References

[1]   Bending, John (1998), The presentation of genealogical information using HTML, Computers in Genealogy 6(6), June 1998.

[2]   Bending, John (2000), Thoughts on the presentation of information on the Web, Computers in Genealogy 7(3):116-21, Sept 2000 (this issue).

[3]   Bending 1-name study, by John Bending, http://www.jbending.demon.co.uk/

[4]   "Personal Histories", Bending 1-name study, http://www.jbending.demon.co.uk/diary1.htm

[5]   "Personal Histories", page 104, Bending 1-name study, http://www.jbending.demon.co.uk/diary104.htm

[6]   Humphrys, Mark (2000), "Hypertext Indented Narrative" pedigree format: Adapting the Burke's Peerage format for the Web, or: How to draw indefinitely large family trees by hand, Computers in Genealogy 7(1):26-46, Mar 2000. Online at: https://humphrysfamilytree.com/hyper.html

[7]   History and Genealogy Web pages of Mark Humphrys, https://humphrysfamilytree.com/

[8]   James O'Mara, https://humphrysfamilytree.com/OMara/james.senior.html

[9]   Maltass family tree, https://humphrysfamilytree.com/Maltass/

[10]   Gibbon family tree, https://humphrysfamilytree.com/Gibbon/

After re-organisation, the Maltass and Gibbon home pages are not good examples any more of showing multiple fragments on one page.

[11]   Alderman Michael Flanagan, https://humphrysfamilytree.com/Flanagan/alderman.html

[12]   Arthur Gibbon, https://humphrysfamilytree.com/Gibbon/arthur.html

[13]   Conn O'Rahilly, https://humphrysfamilytree.com/ORahilly/conn.html

[14]   Eagar family tree, https://humphrysfamilytree.com/Blennerhassett/eagar.html

[15]   La Fontaine family tree, https://humphrysfamilytree.com/Maltass/la.fontaine.html

[16]   Miscellaneous Gibbons in the Aberdeenshire area, https://humphrysfamilytree.com/Gibbon/misc.aberdeenshire.html

[17]   Capt. Robert Gibbon, https://humphrysfamilytree.com/Gibbon/capt.robert.html

[18]   Frank Flanagan, https://humphrysfamilytree.com/Flanagan/frank.html

[19]   Dick Humphreys, https://humphrysfamilytree.com/Humphrys/dick.html

[20]   Discussion of how browsers display links to labels on a page, Henry Churchyard, http://www.pemberley.com/janeinfo/pridprej.html#useppjaht

[21]   Hoffman, Michael (1997), Enabling Extremely Rapid Navigation in Your Web or Document, http://www.hypertextnavigation.com/infoaxcs.htm

[22]   Nielsen, Jakob (1999), URL as UI, The Alert Box, 21st Mar 1999. Online at: http://www.useit.com/alertbox/990321.html.

[23]   Humphrys, Mark (1999), Why on earth would I link to you?, The Irish Times, 15th Feb 1999. Online at: https://humphryscomputing.com/why.link.html




Return to Hypertext Indented Narrative format paper.


Donation Drive

Please donate to support this site. I have spent a great deal of time and money on this research. Research involves travel and many expenses. Some research "things to do" are not done for years, because I do not have the money to do them.
Please Donate Here to support the ongoing research and to keep this website free.

Help       Conventions       Abbreviations       How to read the trees

Privacy policy       Adoption policy       Image re-use policy       New 250 G VPS server.