Family Historian User Group

Evening,

I have tried a few different searches and can't find any help for my problem. I tried to add a divorce using the DEA, but once I enter initial information and click Data Entry Assistant there doesn't seem to be anywhere to go. There is no Record Divorce Data (UK) option, am I missing something? Any help would be useful.

What you can do is prompt the fact tab then from there prompt more fact types which will show a list of facts including divorce. Prompt that.
If divorce is nt listed prompt the add facts button

Victor

I have the fact in, it's adding a citation via the DEA that's the problem

No, there isn't a Divorce DEA yet. What facts would you expect cite a divorce document for except for the divorce itself i.e. what information would you expect to find in the source? If only the divorce then I'm not sure what the benefit would be.

As you have already created the fact anyway, why not just copy and paste the citation?

Helen

I was only asking because there was an option and I thought I was missing something when I was trying to use it. I take it that there are not DEA's set up for all things that options have been set up for. Maybe not worded well but I am sure you know what I mean (I hope). I had noticed before that birth for Australia wasn't supported, I had kind of presumed that if CP had put in an option there would be support for that option.

If by 'option' you mean the DEA button at the bottom of the Prepared Citation window, that's there by default. CP can't know if you or anyone else has written a DEA to handle a particular source type.

What I meant Helen was when you click on something you expect there to be an option to use it. When I selected Create Source from Template and then in the CR Certificate option you get the option to add a divorce, yet as you have said there is no Divorce DEA. If I was expecting to create my own DEA I would also have added Divorce to the type menu when I did it. I just feel that templates have been done a little half hearted and are like pluggins being left to users to do CP's work.

I may be misunderstanding but, are you saying that if there is no DEA for Divorce, there shouldn't be source template for a Divorce source, even though many people will never use DEAs? That doesn't seem right to me.

The dropdown for DEAs does do some filtering, on the source template in use, but where a template caters for multiple events, it doesn't go that far -- if you think it should, please raise a wish list request; it's not a bad idea although I suspect the perms and cons would make it difficult to implement. If you do try to use an inappropriate DEA you will get a message telling you that it doesn't work for the relevant source.

And yes, DEAs are plugins and are being left to users (just as Ancestral Sources was developed by a user). Templates, however, can be used without DEAs and very often will be. The templates provided are reasonably complete and if they don't suit you out of the box, you can produce custom ones. So I'm not sure why you're saying templates are 'a little half-hearted.'

Also, plugins are a great way for users to add functionality that we would have to wait a long time for CP to implement (if ever). No software company has unlimited resources to implement everything some users want; plugins allow suitably-skilled users to fill a gap if they think it's a useful feature. Moreover, they're open source, so not dependent on any one user/company to maintain and enhance.

Mike Tate is, for example, currently working on a plugin that helps users identify places that might have been wrongly geocoded -- I doubt CP would ever commit their limited resources to that (and would actually prefer that they didn't because there are things I value more on the Wish List -- and I suspect that goes for you as well.) I will never use Mike's plugin but I'm grateful that he's written it; and I'd hope that others are grateful for the plugins/DEAs I've written/am writing.

ColeValleyGirl wrote: ↑

19 Jun 2021 06:13

What facts would you expect cite a divorce document for except for the divorce itself i.e. what information would you expect to find in the source? If only the divorce then I'm not sure what the benefit would be.

If you tell me what you'd like to see in a Divorce DEA, I'll put it on my to-do list (not close to the top unless it's easy, which I suspect it will be once the DEA frameowrk I'm constructing is complete).

The new DEA-driven approach needs time to settle down. DEA authors have to tick two boxes - be reasonably experienced plugin authors, and be enthusiastic about the methodology. So far, it is only Helen (and Jane in the early weeks) who have risen to the challenge, and they both had several months start through beta testing.

AS has demonstrated that something can be very successful with a limited support base (just Nick doing the heavy lifting of designing and coding), but it doesn’t happen overnight. On balance, I think CP made the right call in releasing it when they did. Hopefully, it evolves and develops with user feedback and participation.

I think this will just go round in circles, but when I am looking for a plugin I go to Tools then Plugin and either select a plugin I use or search the plugin store to hopefully find something that will help me, if I find what I want I download and use it (No intentions of writing my own). I don't expect to halfway through using the plugin to be told sorry but this pluging doesn't do what it said it will do.

That's basically what DEA's are doing, an example is I enter birth template for my wife enter the info then click on DEA and it says Sorry Australia not supported why wait until I am half way through to tell me this. Why give the option if it is not supported? Does the pop up mean that Australia will never be supported or just not until someone can be bothered to do something about it. Again why give the option.

I think plugins are a great addition in FH, but DEA's should have been implimented in a better way. They work well when they work but some things either don't work (My examples) or when entering an address in a birth (generally all the same for parents and child) have to be typed in seperatly. It could have been all added at once, as this is how it is done in Ancestral Sources. Now I know copy and paste solves this example, but should it really be that way to start with? Much as AS is not for me I do think it does a better job of implementing templates.

On a different point can you copy a template and paste it with table outlines into Microsoft Word? I was asked by a relation for some information and being able to do this would have made it a bit easier to read for them.

Good summary, William. You have no intention of writing your own plugins, either for your own use or to help others, and you are annoyed that nobody can be bothered to write the one you want now.

Wulliam, I'm going to assume you didn't try the plugins I posted here Some new Data Entry Assistant plugins for testing (V7) (18293) for testing?

I'm also going to assume you're never going to tell me what you'd like to see in a Divorce DEA, although I've asked a couple of times. Perhaps third times the charm?

P.S. Why did you expect a plugin called Record Birth Data (UK) to handle Australia?

Mark1834 wrote: ↑

19 Jun 2021 15:56

Good summary, William. You have no intention of writing your own plugins, either for your own use or to help others, and you are annoyed that nobody can be bothered to write the one you want now.

YES, I have no intention of writing a plugin for myself or anyone elses use. I am not annoyed that nobody else is writing plugins for me, I am annoyed that CP haven't supplied what they are advertising and giving options for. My view is that CP should supply the DEA's that they give options for and if people want to add to this then that is where the plugin writer should step in. If there was no option for Divorce within Templates or Australia within birth templates then I wouldn't be asking these questions I would probably be looking into how I could make a one off template for my wife's birth or parents divorce, but they are there, so should be included. I buy software to do a job for me, I don't buy it and expect to have to write things to do what the developers say it does. I don't feel Helen & Jane should be doing this, I feel they should be there helping people suppliment what isn't there not doing what should be there, as we are all in a predicament if they get fed up and say No More and the same goes for all the other peeps beavering away in the background.

I waited a long time for these templates and feel a bit cheated by the results, I like how they work better than AS (in my opinion, sorry Nick), but think that there are some basic things that could have been done better and leaving it to Helen's never ending todo list is not how it should have been done. Getting the basic DEA Templates right and then adding to them with updates as you go would have been better. A simple "these are the templates we are and will be working on" that way people would have known what to expect and would not write a DEA/template that was in the pipeline and ending up with two.

William,

1. Source Templates and DEAs are two separate things.

You don't have to use DEAs to use Templates, as I've already said; and I strongly suspect nobody will or could ever write DEAs for all the combinations of options in all the Templates. There are some low hanging fruit (BBMDB and census) but beyond those, the expectation is that people will use ASC and/or copy and paste as they do now. As for regional variation, it would be a huge job to develop bespoke DEAs for every possible region and in many cases, it would be wasted effort.

You also don't have to use source templates to use DEAs (although all the example ones CP provided were for templated sources).

The reason it's taking so long for me to produce the DEAs I'm currently writing is that I'm attempting to create DEAs for e.g. Birth that will handle ALL relevant sources (including Generic ones), ALL regions, etc. It will be up to users to create the autotext template suitable for the source they're dealing with -- there are too many possibilites for one person to create them all.

2.

we are all in a predicament if they get fed up and say No More and the same goes for all the other peeps beavering away in the background

With plugins, at least they are open source -- anyone can maintain them once they're used to Lua. Should I turn up my toes, somebody else can take them over (which is not true for Family Historian or -- sorry, Nick -- AS).

3. Plugins are an integral part of the Family Historian architecture, and have always been user developed/maintained since they were introduced in FH5, in 2012 -- this may have been before you started using it. It may not be a model that you like, but it's a model that's been in place successfully for 9 years now, and is unlikely to change.

Helen

You seem to think I am having a go at the great work you have been doing, I am not, I appreciate everything you and others are doing.

I'm going to assume you didn't try the plugins I posted here Some new Data Entry Assistant plugins for testing (V7) (18293) for testing?

Yes I have and prefer the ones that were already there, I kind of like that they look like the certificate I have input.

As for what I am looking for in the Divorce DEA, I don't really know as I was hoping that was what templates were for and were going to do for me as I had never entered a divorce into my tree before. I thought that was the reason for DEA's, to help standardise data entry. The very least citations to the two peeps who got divorced, date and location and media.

P.S. Why did you expect a plugin called Record Birth Data (UK) to handle Australia?

Because there was no other option and as FH now supports other languages, I presumed (wrongly) that these were the UK versions.

Should I turn up my toes, somebody else can take them over

This has always been my worry, what if no one takes an interest in the DEA's, it's only you at the moment who has shown an interest and you seem to be busy enough. This is why my view is this should be a CP thing not a user thing, they kept me hanging on for a year and if they had said "If you learn a new programming language you will be able to produce your own templates/DEA's or hopefully someone will do it for us/you I wouldn't have waited for FH7 to redo my tree. As I said I like plugins but am not that interested in learning a programming language just to write one, so I will always be at the mercy of others for that. As I said in another reply I buy software to do a job for me, I don't want to do the programmers job for them.

GeneSniper wrote: ↑

19 Jun 2021 19:46

As for what I am looking for in the Divorce DEA, I don't really know as I was hoping that was what templates were for and were going to do for me as I had never entered a divorce into my tree before. I thought that was the reason for DEA's, to help standardise data entry. The very least citations to the two peeps who got divorced, date and location and media.

We're probably getting towards the end of this discussion, but it is important to clear up this misunderstanding of what a DEA does to avoid confusion.

The DEA does not define the data fields. It is the template that defines the structure of the source. CP provide standard templates, but any user can modify these as they wish or create completely new ones simply by using the FH menus. No programming skills are required.

The DEA provides a tool for entering data in a structured way. The clue is in the name - Data Entry Assistant. If you don't like the concept of DEAs, or there is not one available for the template you want to use, the template works just fine without one.

I am sympathetic to criticism of how DEAs have been implemented in the FH menus. If you don't want to use Ancestral Sources or a particular plugin, they are easy to ignore. A new user who doesn't know what they are is unlikely to be confused by them, as they won't see them unless they go hunting. However, DEAs are front and centre of the new sources menu. IMO, it is this prominence that creates confusion, and many users get the impression that you have to use a DEA to enter data.

I can see why CP took that approach. Personally, I would have been perfectly happy if FH7 had been implemented just with templated sources, but they would be open to criticism of simply producing a "me too" feature several years after their major competitors. To their credit, they have tried to do something a little different, by exploiting the unique expandability of FH via plugins. There is a potential mismatch between the prominence of DEAs and how easy/difficult they are for users to create or modify, but the test will be how many users have contributed their own DEAs by say the end of next year. When plugins were first introduced, a lot of people (relatively) contributed to the store. That has now largely dried up, and I suspect DEAs will be the same, but that doesn't mean the concept is wrong.

Mark

I fully understand the consept of what DEA's do, my gripe has always been through out this post that they are not all there. It is pointless bringing in a system that is there to, in the words of CP-

The purpose of these tools is to make data entry significantly quicker and easier by automating tasks as much as possible, in a way that is fully transparent and under user-control, while providing more consistent, comprehensive and professional results

and not have the ones you have in the options available. I accept that making all of the options worldwide wide be a pointless and costly exercise for any company no matter how big or small, I am just saying don't put the options in drop down menu's if you are not supplying an option to put the data in. I presume that CP are not going to add any more so I am left at the mercy of other users or I have to learn how to make DEA's myself (Not happening), I looked in the plugin store and there are only 8 DEA's all last updated in Oct 2020, bar one updated Jan 2021, so I am guessing from that and your comments about Pluggins drying up after time that this is pretty much what we are stuck with apart from what Helen is working on. So really CP have introduced something that will probably not be fully used unless they work on it on over time, which doesn't look like it is going to happen.

If your central criticism is that DEAs have not been implemented particularly well, I would agree with you, but you muddied the waters somewhat by appearing to be unclear what you wanted in a divorce template because there is no DEA available, and apparently criticising those who haven’t “bothered” to write the one you want to use.

William,

No, I don't think you're having a go at my work -- and if you were, you'd be within your rights. Nobody has to like or use what I do; many people don't/won't -- they'll continue using AS, or otherwise doing data entry the way they've always done it. And there may be things I do that could be implemented better, so constructive criticism is always welcome (although I reserve the right to say, e.g. 'too hard and difficult', 'too niche' or whatever. I will not be implementing all suggestions willy-nilly).

I do worry that you seem to have some misconceptions about what a DEA is/does, and that's confirmed by your statement:

Yes I have and prefer the ones that were already there, I kind of like that they look like the certificate I have input.

So, let's step back and review a few things -- all of which are independent features of FH and can be used separately or together, as part of a source-driven data entry approach but also as part of fact-driven approach, and/or to improve the consistency of data entry and/or the speed/ease of data entry. Excuse me if I tell you some things you already know, but I don't want make any assumptions. At the end, I'll explain what it means for you.

1. Source Templates

These are intended to make entering source-identifying and citation-information as consistent and easy as possible. Just that, nothing else. The source-identifying information might replicate some of what goes into facts (typically a date, maybe a place/address etc.) but there are templates (particularly in the Advanced collection) that have almost no overlap with the info in a fact.

You can use the ones provided, clone and customise them, generate completely new ones or import ones that somebody else has constructed -- that's up to each user.

2. Standard Autotext

This is another mechanism intended to help make data entry as consistent as possible. It allows you to have a set of predefined text layouts for e.g. Text from Source within a Source, or the note associated with a fact, or a Citation note -- anywhere you can add a multi-line note. Calico Pie have provided some example Autotext for Text from Source entries, including e.g. blank forms for the UK censuses that you can use to make manual transcriptions of a census entry.

When working with sources, there's likely to be a significan overlap between the information you put into Text from Source and the information entered in Facts (how coud there not be, when they're both derived from the information in the source).

Again, you can use the ones provided, clone and customise them, generate completely new ones or import ones that somebody else has constructed .

You can use Autotext without using Source Templates, and you can use Source Templates without using Autotext.

3. Tools to help make source citation consistent

These are not new in V7, but are worth mentioning as they're visible from the Prepared Citation Window: Automatic Source Citation, and Citation Copy and Paste. If you're using a source-driven data entry approach (which has always been possible in earlier versions; V7 just collects the necessary toolset in one place -- the Prepared Citation Window), these are how you maintain consistency of source citations if you're creating facts 'manually', either by choice or because a Data Entry Assistant isn't available for the Source you're using.

If you're using a fact driven data-entry approach (fact first, then create/cite source) you can use the same tools to get consistent citations but you'll access them from elesewhere in the programme (broadly speaking, the same places as you accessed them in V6).

4. Data Entry Assistants

These are plugins implemented to run in the context of the current Prepared Citation. You don't have to have the Prepared Citation window open to run one, as long as a Prepared Citation exists, but running them from the Prepared Citation window allows some basic filtering to be done, to show DEAs that are coded to work with the Source type/template of the source concerned.

DEAs may need to do some more validation -- e.g. check that they can handle the Region for a Certificate, that the Certificate Type is one they can handle, or that all their prerequisite data is present in the source definition -- but they will do this before the user is required to do any entry of additional information from the source, so the user doesn't waste any effort putting in information that won't be used. (The source-identifying information is needed whether you're using a DEA or not, so always needs to take place before a DEA is run or some other data entry mechanism is deployed -- filling it in is not part of running the DEA).

DEAs can theoretically do a whole range of tasks; however, all but one of those written so far:

• Prompt for information from the source that has not already been entered via a source template
• Use that information to:
  1. Create facts derived from the information entered, and cite the source for each of them
  2. Create Text from Source, based on Autotext

5. Plugin Autotext

There's a special set of Autotext for use by plugins, which contain placeholder tokens e.g. {PRINCIPAL.NAME} which the plugin will replace with information provided by the user and/or the source template to create e.g. Source from Template text.

The example DEAs provided by CP generate their own autotext templates, which is why each of those DEAs has a very limited scope. Having contributed to some of them (to expand the range of UK sources they handle), I believe this approach puts too much onus on the plugin developer to be familiar with a multitude of data sources as well as with Lua, which in turn limits the likelihood that a DEA would ever be provided for (e.g.) a US Birth certificate (given the variation in certificates across 50-odd states) or Australia (where I suspect they're state-specific as well).

An alternative approach (which I am taking) is to provide a single very simple default autotext template with a DEA, plus the option not create Text from Source at all (some peope won't want a transcription; some people will copy and paste from the Internet), or to use an Autotext template (including tokens) provided/selected by the user (a similar approach to the one AS takes). There'll be a place in the KnowledgeBase to contribute/download plugin autotext templates (just as there is for AS templates) and I'll seed it with some templates for sources I am familiar with (all will be UK ones).

I note that there are not many AS templates available in the KB even though the programme has been around in some form or other for 10 years; I suspect this is because people who need 'specialised' templates develop them for their own use but don't contribute them to the KB, and expect to see the same pattern of behaviour for these DEAs.

I also note that very many sources don't lend themselves to effective data-entry automation. A Will for example contains a very unpredictable set of information (beyond whose will it is and when it was made and proven), likewise an oral interview, whereas for a DEA to be worth using, there has to be a well-defined set of facts that will be created. AS has only recently extended its coverage to include Registers/Electoral Registers, and there may be a few other source types which are equally amenable, but Newpapers, Obituaries, Memorial Inscriptions, Military Records, Land Army Index Cards, Court records, Property Records (just to name a few source types I have used in the past) are almost certainly never going to be automated. If they could be, I strongly suspect AS would already handle them!

6. What this means for you

• There will never be a DEA for every possible source you want to cite; unless you limit yourself to a very basic set of source, for some sources you will inevitably have to generate Text from Source manually (perhaps using an Autotext template) and create the facts manually, citing the source via ASC, Copy and Paste or manually.
• If there is a DEA, you may still need to create the Autotext template yourself, if nobody else has done so before you, but you won't need to learn Lua and programme your own DEA, or depend on the original author to produce the autotext template. (For the plugins I posted for testing, I also posted links to templates that will create Text from Source that looks like a certificate, which you might not have spotted).
• If the person who wrote your DEA loses interest, it will still be available to you, and if you find a bug, you could ask here in the forums if anyone was willing to fix it/take over maintenance of it. Maybe somebody would volunteer; if not, the plugin will continue to work at least until the next major release of FH (at which point I imagine that if it was widely-enough used, the plugin store management would arrange for it to be converted if necessary -- it's in nobody's interest for a useful plugin to be left stranded in an 'old version'.)

Divorce

A Divorce DEA will be possible if there's a predicatable set of facts to create from a predictable set of information, but if I create one in due course,it will be up to the user to create the autotext template from text from source if they want anything more than a simple list of information. To write the DEA, I need to know from somebody who has a divorce source in front of them. what information to cater for. OK, the two people who got divorced, the date and place/address of the divorce. Do the people have residence information? Ages? Is there any cause information? Reference information? Anything else? If I can't get this information, I will either have to arrange for a close family member to divorce, or not create the DEA...

You can use the ones provided, clone and customise them, generate completely new ones or import ones that somebody else has constructed -- that's up to each user.

Well, actually, they're front and bottom right of the Prepared Citation window; they're not on a menu at all . But yes, there is a tendency for people to leap to them immediately when they're only one option.

I can answer one of those questions. I’ve got 2 sets of detailed English divorce papers in my sources, from 1919 and 1948. They are totally different, and I suspect a more modern divorce would be different from both as divorce law evolves with time.

Is the date of divorce the date the petition was filed, when the decree nisi was granted, or when it became absolute? If there is a co-respondent are they a third principal to the event, or a witness? As ever, the devil is in the detail...

Helen - if it's any help, I have a "Certificate of making Decree Nisi Absolute (Divorce)" from 1999. Feel free to message me if you want any info from it.

Thanks, Brent, will do when I start work on the DEA.

I need to arrive at a set of fields that capture the most common information provided, so will probably need a few examples to produce something useful; and I suspect there will still be the need for users to add some facts manually.

Helen - I've not been following this sufficiently well to know if you're actually intending to do a DEA for Divorce but, for your information, I have two sets of divorce proceedings that you're welcome to copies of, if / when you want. They are from the stuff (to use the technical term) at Kew in J 77, from 1870-74 and 1893. There are preformatted pages in there, but in both cases the majority of the pages are hand-written. This suggests to me that while the clerks concerned might have a preferred format, it was easy for them to alter things if they felt it beneficial. Since both sets of papers document all sorts of things, I don't think it's possible to dictate even what the list of events to be created in FH might be from such a set of papers - there are two marriage certificates in one set, for instance, so these are definitely complex, multi-event sources.

I emphasise that the above is from the J 77 documents - if there are other types of documents, I can't comment on them, but my understanding is that J 77 is pretty much it for that period.

Thanks Adrian. I was worried that divorce sources might be too complex to automate the data entry. When I start to look at the possibility properly I shall have to do an analysis of a range of divorce documents. IMO it's not worth creating a DEA that still leaves you with a shed load of manual data entry to do.