* Records window customisation odd problem (FH7)

[NickWalker]

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.

[tatewise]

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.

[NickWalker]

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.

[tatewise]

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.

[ColeValleyGirl]

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?

[tatewise]

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.

[ColeValleyGirl]

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.

[NickWalker]

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.

[ColeValleyGirl]

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

[NickWalker]

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.

[ColeValleyGirl]

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

[tatewise]

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.

[ColeValleyGirl]

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.

[NickWalker]

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.

[ColeValleyGirl]

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.

[tatewise]

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.

[AdrianBruce]

... 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.

... 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.

[NickWalker]

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.

[ColeValleyGirl]

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.

[ColeValleyGirl]

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.

[David2416]

Users shouldn't have to worry about this stuff, it's the programmers job to hide this from them.

Well said

[ColeValleyGirl]

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.

[NickWalker]

I give up I'm clearly talking rubbish sigh.

[ColeValleyGirl]

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.

[AdrianBruce]

... 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.