Improve result list headers about myopicvicar HOT 9 CLOSED

After some discussion about whether or not we should make headers record-type-specific at the cost of restricting searches to a single record type, Eric writes:

Given that you clearly wish to have just 1 general table form for all results, then i suggest:-

Participants > Searched person

Other Names > Others in this record.

But there is an issue here. We had previously decided to have 'fields' in the input system for either 4 or 6 people as witnesses to a marriage [I can't exactly recall what EricD said] and arrange that future transcriptions can populate as many of these fields as necessary. but we would not go backwards through existing files to fish out extra witnesses from wherever they have been recorded.

Now this reflects on theSearch Results page: do we really need to display here all the witnesses? The key players here (in marriage) are the bride and groom. That's all that I think should be displayed. All the rest come in details.
You could put a flag on the search result record saying "search name is a witness -see detail" in tiny font, so it does not clutter up the page.

from myopicvicar.

I responded:
That raises two separate issues:
Should searches match witnesses? This is pretty easy to do -- right
now I'm just matching father names for marriages. If I add it, it'll
appear under the "Other Names" column.

This reminds me that we should display the person's role alongside
their name in the result list -- so rather than
Participants:
Esther NEEDHAM
John BRIMBLE

Others:
Charles BRIMBLE
Joseph NEEDHAM
Joseph NEEDHAM
Gertrude Lavinia CANNARD

We'd have
Participants:
Esther NEEDHAM (Bride)
John BRIMBLE (Groom)

Others:
Charles BRIMBLE (Groom Father)
Joseph NEEDHAM (Bride Father)
Joseph NEEDHAM (Witness 1)
Gertrude Lavinia CANNARD (Witness 2)

[This assumes we want to include witnesses in search results]

from myopicvicar.

Discussion of adding roles to name display and searching witnesses is moved to new issues.

from myopicvicar.

On the same subject, Andy had earlier written:

I think we may need a different results summary screen depending on whether the search is BA, BU or MA.

Specifically for Baptisms:

"Participants" is not the correct description. It should be something along the lines of "Name".
"Other Names" should be "Parents"
"Date" as already reported is not being displayed
"County" should be the name not Chapman Code

from myopicvicar.

My response on the subject:

This is the first suggestion that I'm going to push back on.

One of the big differences between Freereg1 and 2 is that we don't
require researchers to choose a record type, and present results
across baptisms, marriages, and burials together. I personally think
that this is a real help to researchers, who are often just looking
for John Smith, and don't care which kind of record he appears in. I
would be surprised if, on launching the site and analyzing the
searches performed, we found a majority of searches specifying record
type at all.

The down-side of mixing record types in search results is that we're
stuck with generic labels for our column headers. "Participants" is
what I chose for Decedents, Baptizees, and Spouses, while "Other
Names" is what I chose for parents, relatives, and such. I'd be happy
to change those labels to something better, but would like more
discussion before we change search results to be type-specific, and
force researchers to conduct three separate searches per record type.

from myopicvicar.

Andy replied:

I would disagree. As a researcher myself and a frequent user of FreeBMD, which does give the option of selecting one, two or three event types, I rarely use nore than one, sometimes two but never three. This is quite simply because the range of years to encompass more than one event for a particular person can be +/- 80 years. For example a person born in 1800 might marry between 1820-1830 and die anytime up to 1870-1900. The only time I find the facility useful is when I know there is a birth closely followed by an infant death when the year range can be significantly reduced.

from myopicvicar.

Andy pointed to the FreeBMD form as an example of mixed searches.

from myopicvicar.

We are now displaying roles beside each name, but the headers still are unsettled.

from myopicvicar.

There has been considerable improvements to many of these displays in the past year. It is likely time for a review of the current status and develop new stories where needed.

from myopicvicar.