* Records window customisation odd problem (FH7)

Questions regarding use of any Version of Family Historian. Please ensure you have set your Version of Family Historian in your Profile
User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 12:29

There are a reasonably small number of field types but each one can have different names. There would be nothing to stop a template having 20 repository fields if it wanted to I think. To add to the complication they could be citation fields or source fields.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
tatewise
Megastar
Posts: 20130
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by tatewise » 10 Jan 2021 12:44

Yes Nick, but as I said, FH copes with large numbers of other types of 'definitions', e.g. Fact Types, Named Lists, Plugins, Queries, not to mention thousands of records. It can't be too difficult. It is what computers are supposed to be good at.
By comparison to Fact Types, the Template Fields are trivial.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 12:49

Sorry yes I was just adding to the general discussion about the complexities of templates and the difficulties you would have in dealing with exporting them.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
tatewise
Megastar
Posts: 20130
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by tatewise » 10 Jan 2021 13:03

Ok, I thought you were talking about the Data Ref Assistant not supporting Templated Fields.
Exporting & Importing Templated Fields would be feasible if there was a mapping between them and generic fields.
i.e. For each generic such as %SOUR.REPO% there was an associated templated such as %SOUR.~RP-REPOSITORY%
IMO: Even simpler, just incorporate {%SOUR.REPO%} into a set of Source Templates for users who want generic Sources with formatted Footnotes and Bibliography, etc. Then imported & exported GEDCOM don't need conversion at all.
Earlier the impact on few and many was mentioned when dealing with these 'complexities'.
If a very few built that set of Source Templates then many would benefit.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 13:29

tatewise wrote:
10 Jan 2021 13:03
Exporting & Importing Templated Fields would be feasible if there was a mapping between them and generic fields.
But the whole point of Templated Sources is that they're more complex/granular than generic fields can support.

Perhaps I'm missing something and you can explain how to map (for example) the Legal Document, Unrecorded template from the Essentials field into generic fields?

User avatar
tatewise
Megastar
Posts: 20130
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by tatewise » 10 Jan 2021 14:39

I've never said that every Source Template could be mapped onto generic sources.
Just that within the limits of generic sources there could be a set of Source Templates that would give users the benefits of Footnote, Bibliography, etc, formatting without needing to convert on both import and export.

In the Adding Citation information to Templated Sources (18646) thread I said:
Yes, it seems to combine most of the benefits of Generic Sources with Templated Sources.

Note that standard Repository links {%SOUR.REPO%} work as expected.
Other fields that can be used are Custom Id {%SOUR.REFN%}, Type {%SOUR._TYPE%} & Publication Info {%SOUR.PUBL%}
Also, citation Note {%CUR~CITN.NOTE2%} and Entry Date {%CUR~CITN.DATA.DATE%}

Those are all TEXT fields except for Repository and Entry Date, but you can still use Source Template fields with type NAME, DATE, PLACE, ADDR, ENUM & URL although they won't map onto Generic Source fields for import/export.
However, rich text Note and Text From Source fields can hold URL web links and NAME & PLACE record links.
So the only significant loss would appear to be DATE, ADDR & ENUM.
If users wish to work primarily with generic sources then that mapping gives them many benefits.
They can have additional template fields if they wish, but they will have blank values on import and won't export.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 14:57

I'm thoroughly confused about wjat you're suggesting, Mike. A set of Templated Sources that mimic generic ones? Or something else? A worked example of the beast would help.

User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 15:17

I think Mike just means there would be one template that would mimic the generic source fields but would give the benefits of being able to format footnotes and bibliography, etc. It would then also mean they could be easily exported.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 15:29

I'm definitely missing something. You can format the footnote and bibliography for generic sources now.

User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 15:48

I must admit I've not looked at footnotes, etc. (I've had no time to really use FH for anything except testing AS) but from what he's been saying I'd assumed there was some additional formatting that wasn't available to generic sources.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 15:51

NickWalker wrote:
10 Jan 2021 15:48
I must admit I've not looked at footnotes, etc. (I've had no time to really use FH for anything except testing AS) but from what he's been saying I'd assumed there was some additional formatting that wasn't available to generic sources.
Ditto re lack of time but my excuse is DEAs :)

User avatar
tatewise
Megastar
Posts: 20130
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by tatewise » 10 Jan 2021 16:25

Helen is referring to Tools > Preferences > Sources tab Generic Source Formats... where the Format for Footnote, Short Footnote & Bibliography can be defined via View Format and Customize at the bottom, but only once for ALL generic sources in all Projects.

In practice, despite only a limited number of fields, there are typically different types of generic source record.
That is what the Source Type field helps with, and AS creates different source record 'styles'.
Also, imported generic sources from different products will have their own 'style'.
There are of course the Method 1 and Method 2 flavours of source records. Do I need to go on?

A variety of Source Templates can be defined using generic source fields {%SOUR.REPO%}, {%SOUR.ABBR%}, {%SOUR.AUTH%}, {%SOUR._TYPE%}, {%SOUR.PUBL%}, {%CUR~CITN.PAGE%}, {%CUR~CITN.NOTE2%},{%CUR~CITN.DATA.DATE%}, etc.
It is also possible to use {=GetLabelledText(%SOUR.NOTE2%,"Data:")} to define several labelled Note fields.

Such Source Templates can use different fields in different combinations to format Footnote, Short Footnote & Bibliography for a variety of generic source record 'styles' and can be different in each Project.
All Queries, Records Window Columns, Diagram Expressions, etc, will continue to work with those established generic source record 'styles' without change.
There is nothing to stop templated fields to be added to such templates if desired but they would fall outside the scope of imported & exported source records, except they can be included in the exported Source labelled Notes.

It would be relatively easy to add those Source Templates to generic source records according to criteria such as its Source Type field by using a very simple Plugin. No data conversion is needed, just linking a Source Template.

As Nick and I have said, we don't understand why CP needed to invent a Repository (t) field instead of sticking with %SOUR.REPO%, and a similar argument can be made for Author (t) and %SOUR.AUTH% that may templates use.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 16:43

tatewise wrote:
10 Jan 2021 16:25
As Nick and I have said, we don't understand why CP needed to invent a Repository (t) field instead of sticking with %SOUR.REPO%, and a similar argument can be made for Author (t) and %SOUR.AUTH% that may templates use.
In many Source Templates in the Advanced collection a repository is not a standard field; in fact, it's rarely used --ESM says that repositories are only cited as follows:
  • We cite repositories for manuscripts that exist only in that one place because otherwise nobody would be able to find the manuscript.
  • We cite a repository for a book only if it is so rare that others would not be able to find it.
Neither is Author used a lot.

However, I hear you say, why not use the generic fields where they exist?

IMO, mixing generic fields and non-generic fields in a template is un-necessarily complex. Different syntax for referring to them in queries? -- confusing for new users who've never used generic sources.

It's a balancing act between upgraders and new users, or course, and exporters versus non-exporters... and I think it's too easy to view the solution through just a single lense.

User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 16:53

As I've said there may well be a good reason for it, I just don't know what it is. I don't understand why there has to be a different syntax when querying generic fields as opposed to template fields - they could surely abstract to the same syntax. Users shouldn't have to worry about this stuff, it's the programmers job to hide this from them.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 16:59

I don't understand why there has to be a different syntax when querying generic fields as opposed to template fields - they could surely abstract to the same syntax
So, if the syntax for template fields was %SOUR.FIELDNAME% rather than %SOUR~FIELDNAME% you'd be happy. When FIELDNAME for templated sources was of the format AA-NNNNNNN?

Except I seem to remember that ~ means something different than . in a data reference -- Mike will set me straight.

User avatar
tatewise
Megastar
Posts: 20130
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by tatewise » 10 Jan 2021 17:04

Good point. Has anybody else noticed that in GEDCOM 5.5.1 and FH V7 GEDCOM files custom attributes use the FACT tag, whereas all data references still use _ATTR tag form FH V6?
Now which one confuses new users, and which one hides the change? Perhaps both should be allowed as synonyms.

Yes, ~ means it is a synthetic shortcut whereas . means it is a real subsidiary field.
BTW: the syntax is actually %SOUR.~AA-NNNNNNNN%

But this where my concept of mapping could be employed where %SOUR.~RP-REPOSITORY% = %SOUR.REPO% is in the template definition so either syntax will access the same generic field.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
AdrianBruce
Megastar
Posts: 1071
Joined: 09 Aug 2003 21:02
Family Historian: V6.2
Location: South Cheshire
Contact:

Re: Records window customisation odd problem (FH7)

Post by AdrianBruce » 10 Jan 2021 17:32

ColeValleyGirl wrote:
10 Jan 2021 16:43
... in fact, it's rarely used --ESM says that repositories are only cited as follows: .. [omitted. AB] ... Neither is Author used a lot.
Although ESM is always at pains to point out that her standards are about the final, printed output, and what goes in your file can contain more - such as web-sites recorded as Repositories if you feel it useful.
ColeValleyGirl wrote:
10 Jan 2021 16:43
... It's a balancing act between upgraders and new users, or course, and exporters versus non-exporters... and I think it's too easy to view the solution through just a single lens.
Certainly I'd agree with the dangers of the single lens view. However, I find myself wondering just who these new users are... Real newbies can indeed build stuff up from scratch. But I guess that the real target of the templated sources is the user of a slightly obsolescent bit of software that uses templated sources. Who else is going to use any ESM type templates? But if they do come to the FH Party - how on earth are they going to convert their templated sources? If they've produced a GEDCOM, then loading it into FH will require a huge amount of work to re-template - most of it inevitable, I suspect. But at least mapping things like Author and Repository over in the obvious way would be a start? Even if a very small start?? (I have absolutely no idea about direct reads of databases containing templated sources...)

I'm not saying that CP should have produced dedicated guides to re-templating sources rendered generic by GEDCOM etc imports - there are just way too many options. But I do wonder if enough thought has been given to the use cases arising from imports - either from FH v6 or other GEDCOM imports. And yes, I freely admit to speaking from ignorance. But it is the ignorance of a prospective customer.
Adrian

User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 17:44

There do seem to always be a number of users who are 'starting again', going back and sourcing things properly, etc. Over the years I've come across a lot of those people who have discovered Ancestral Sources and they've decided to go back and use it re-enter their data and to ensure they record all their sources, etc. 'properly'. I did that myself when I first created my software, but then I guess I only had a couple of hundred census sources and now it would be far too big of a task for me to start again. So I guess a lot of the 'new users' will actually be people who have been using software for sometime but that they can see the benefit of 'starting again' as perhaps the volume of existing data they've recorded isn't too great.

Now AS full supports 'rich text' and 'templated sources' for those who wish to use them, I expect I'll start to hear from people who are starting again (perhaps again again!) with those. I am aiming to build some tools into AS that will help to convert existing census sources to rich text and perhaps templated sources too.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 17:47

AdrianBruce wrote:
10 Jan 2021 17:32
Although ESM is always at pains to point out that her standards are about the final, printed output, and what goes in your file can contain more - such as web-sites recorded as Repositories if you feel it useful.
Except the templates record them as websites, not as repositories.
Certainly I'd agree with the dangers of the single lens view. However, I find myself wondering just who these new users are... Real newbies can indeed build stuff up from scratch. But I guess that the real target of the templated sources is the user of a slightly obsolescent bit of software that uses templated sources. Who else is going to use any ESM type templates? But if they do come to the FH Party - how on earth are they going to convert their templated sources?
I suspect they'll be in a better position than many users to migrate templates, as they're coming from one structured environment to another -- easier for them, anyway, than users of generic sources. If the structure in the originating programme is well documented, a migration plugin per source programme may be possible.

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 17:56

Real newbies can indeed build stuff up from scratch.
I strongly suspect real newbies are part of the target market for templates -- read the help which emphasises how much easier it makes data entry. I for one am looking forward to many fewer questions about how to shoehorn information into inflexible generic templates.

User avatar
David2416
Famous
Posts: 188
Joined: 12 Nov 2017 16:37
Family Historian: V7
Location: Suffolk UK

Re: Records window customisation odd problem (FH7)

Post by David2416 » 10 Jan 2021 18:26

NickWalker wrote:
10 Jan 2021 16:53
Users shouldn't have to worry about this stuff, it's the programmers job to hide this from them.

Well said

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 18:33

David2416 wrote:
10 Jan 2021 18:26
NickWalker wrote: ↑Sun Jan 10, 2021 4:53 pm
Users shouldn't have to worry about this stuff, it's the programmers job to hide this from them.
They don't have to worry about it if they use generic sources exclusively or templated sources exclusively, which is the sensible way to proceed. What muddies the waters is people suggesting the two should share some commonality (for the convenience of programmers) when they can't be made identical.

User avatar
NickWalker
Megastar
Posts: 1340
Joined: 02 Jan 2004 17:39
Family Historian: V7
Location: Lancashire, UK
Contact:

Re: Records window customisation odd problem (FH7)

Post by NickWalker » 10 Jan 2021 18:59

I give up I'm clearly talking rubbish sigh.
Nick Walker
Ancestral Sources Developer

http://www.ancestralsources.com

User avatar
ColeValleyGirl
Megastar
Posts: 2210
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Records window customisation odd problem (FH7)

Post by ColeValleyGirl » 10 Jan 2021 19:24

No nick none of us are talking rubbish. We just have different mindsets and priorities and assumptions. What you and Mike see as simplification by increasing commonality across all source kinds, I see as unnecessary complexity because I'm assuming that most people won't mix the two kinds.

I think it's too early to know which assumptions are correct. Maybe the majority of users will be happy to mix and match, even given the disadvantages. I don't know, however much I think they should no.

User avatar
AdrianBruce
Megastar
Posts: 1071
Joined: 09 Aug 2003 21:02
Family Historian: V6.2
Location: South Cheshire
Contact:

Re: Records window customisation odd problem (FH7)

Post by AdrianBruce » 10 Jan 2021 20:15

ColeValleyGirl wrote:
10 Jan 2021 19:24
... Maybe the majority of users will be happy to mix and match, even given the disadvantages. I don't know, however much I think they should not.
From my viewpoint, with something like 5,300 source records, most split, some lumped (like BMD indexes or Directories), and with all sorts of styles and mixtures in the Source-Record fields, there's no way I can contemplate a source-record do-over. I want to at least try some templated sources for new types and see what it comes out like. If it turns out that my "elders and betters" were right after all and it's so much all over the place that it's a PITA, then fair enough - at least I'll have tried and I won't have wasted Calico Pie's efforts.
Adrian

Post Reply