* [Wish List 630] Template Design Preview

[Gary_G]

I've been attempting to design my own templates v7.0.19
I'm finding that envisioning the resulting citation output is a real issue.
One can't actually see a "trial" output without exporting the template to a project and entering some test data.
Making revisions, once one sees the result, is time-consuming.
It would be so handy to have a way of entering test data as part of the template design and having a preview of the result.

[sbell95]

I would also love to see this added to FH. I have become pretty quick at editing a source template definition, synching it with my current project and then creating a source to test the results, but it is still time-consuming and cumbersome when all of that could be done from within the source template definition editor itself.

[fhtess65]

I'll add a third voice in support of this wish list request...like Sarah, I've became pretty adept at editing the template, exiting, checking it "live" and then returning to edit the template again, but it would certainly be helpful to see it live while working on it in the template editor. I have chronic carpal tunnel syndrome, so anything that saves me mouse clicks is very welcome.

[cwhermann]

I will add a fourth voice in support of this wish list request - once it is added to the project, I have found it "somewhat" quicker to edit the template in the Source Template Record and then once I feel it is correct, going back and syncing the Source Template Definitions with the Source Template . It would also be nice to have the format field in the Source Templates wrap similar to the Template Definitions windows.

[ColeValleyGirl]

There's plenty of support for this, it seems. Is anyone willing to turn it into a well-formulated proposal to be transferred to the wish list?

[Gary_G]

While I really would like to see this capability included in FH, I've had less-than-pleasant experiences with proposing wish-list wording. So, I'll let someone else have a go at it.

[Peter Collier]

I'd strongly support this proposal also.

[AdrianBruce]

Sticking head above parapet time then... Bear in mind that I am not a Templated Source user so I may have missed bits that should be Bl**** Obvious. But I am the one who's put "pen" to "paper".

Background
The "proper" way of updating Source Template Definitions is via Tools / Source Template Definitions...

The Source Template Definition Editor then gives access to the list of Fields, and their Types. Those are then concatenated, along with optional fixed text, into the formats for Record Title, Bibliography, Footnote and Short Footnote. The Fields can be adjusted with styles, qualifiers, etc.

Issue
The Source Template Definition Editor only shows the "parameters" - it does not show any sample values. Many people find it much easier to assess the usefulness of their new formats if they can see sample values. Currently, that requires adding the revised Source Template Definition to a project and then creating a Prepared Citation against the new Source Template.

Any desired changes then have to be reflected back into the Source Template Definition Editor (with consequent potential for missing desired changes) and the process repeated.

Other methods are possible, such as editing the Source Template directly, but sometimes these methods store up unseen issues.

Proposal
The Source Template Definition Editor should be given a "preview" function that will show the resulting formats for Record Title, Bibliography, Footnote and Short Footnote.

The resulting formats should contain Field-appropriate sample data values (i.e. not generic "XXXX" strings unless those are explicitly entered by the user).

The resulting formats must use any currently specified styles and qualifiers, etc.

It should be possible to input the sample data values as part of the process of using the Source Template Definition Editor.

The new facility could provide a means of keeping the sample data values from one use of the Source Template Definition Editor to another. The sample values could be "keyed" by the Template Name and Collection.

[tatewise]

That is a proposal that I would support with possibly a small refinement.

I think it would be useful for the user to be able to specify more than one set of sample data values for the Fields.

The reason is that the format templates often include conditional parts enclosed in < angle brackets > and those can only be reviewed by having sample data that both includes and omits the key Field values.

With all those sets of sample data values it is important they are saved with the Source Template Definition.

[ColeValleyGirl]

With Mike's suggested amendment, I'm happy with that proposal.

[KFN]

I’m just a beginner in template use and design, so the following questions come only from ignorance!

Since most data that templates use comes from “custom fields” contained in the Source_Record, Questions 1) does the storing/saving/use of sample data change based on lumper vs splitter use, 2) does this sample data change if the data comes from GEDCOM based fields rather than “custom fields”?

If the proposal has no relationship to data location then “never mind!”

[Gary_G]

I would suggest that the "wish" should explicitly state that the goal is to; "Provide a solution that permits the user to both specify and immediately see the result of the template definition process, based upon one or more user-selectable sets of metafield data". If the design intent is not also explicitly stated as a goal, there could be many "hidden" user-requirements that a wishlist item might miss stating.

[tatewise]

KFN ~ The proposal must cater for all those use cases.
1) lumper vs splitter templates are different and distinct so will have their own sets of sample data.
2) sample data must cater for any standard GEDCOM field used in the format templates.

Gary_G ~ I agree with your goal statement.

Does the proposal need to explicitly mention any of the following:

1. Review of conditional formatting such as < angle brackets >
2. Sample data for GEDCOM standard fields used in formatting such as %SOUR.AUTH%
3. Review of Tools > Preferences > Sources > Generic Source Formats...

[fhtess65]

Me too!!! While I'm now used to editing a template, going through Compare/Sync, then viewing the source, noting changes that need to be made, rinsing and repeating, it would be so much easier to have a sample to view within the template editor, with values.

With Mike's suggested amendment, I'm happy with that proposal.

[Gary_G]

KFN ~ The proposal must cater for all those use cases.
1) lumper vs splitter templates are different and distinct so will have their own sets of sample data.
2) sample data must cater for any standard GEDCOM field used in the format templates.

Gary_G ~ I agree with your goal statement.

Does the proposal need to explicitly mention any of the following:

1. Review of conditional formatting such as < angle brackets >
2. Sample data for GEDCOM standard fields used in formatting such as %SOUR.AUTH%
3. Review of Tools > Preferences > Sources > Generic Source Formats...

Tatewise;
I believe I understand your concern, but would suggest that it may be implicit that the "preview" capability must handle any situations possible with the current template-definition capability.

[AdrianBruce]

I would suggest that the "wish" should explicitly state that the goal is to; "Provide a solution that permits the user to both specify and immediately see the result of the template definition process, based upon one or more user-selectable sets of metafield data". If the design intent is not also explicitly stated as a goal, there could be many "hidden" user requirements that a wishlist item might miss stating.

While stating overall goals might be useful in a larger item of work, I'm having difficulty seeing the need for it here, given that the proposal is fairly short. "Immediately see" is probably a useful thing to add in, i.e. alter

a "preview" function that will show the resulting formats for Record Title, Bibliography, Footnote and Short Footnote.

to

a "preview" function that will show the resulting formats for Record Title, Bibliography, Footnote and Short Footnote without exiting the Source Template Definition Editor.

[tatewise]

However, we have previously fallen foul of specifying goals without express cases and CP didn't implement all aspects of the goals, perhaps because they did not interpret the goals the same as FHUG.

IMO: If we don't identify the cases we wish to be included they may not get implemented despite being within the goal statement. For example, it would be easy for CP to overlook reviews for Tools > Preferences > Sources > Generic Source Formats... and just focus their attention on Template Source Definitions.

[KFN]

However, we have previously fallen foul of specifying goals without express cases and CP didn't implement all aspects of the goals, perhaps because they did not interpret the goals the same as FHUG.

IMO: If we don't identify the cases we wish to be included they may not get implemented despite being within the goal statement. For example, it would be easy for CP to overlook reviews for Tools > Preferences > Sources > Generic Source Formats... and just focus their attention on Template Source Definitions.

I brought up GEDCOM because my current design of templates use both “custom tags” and GEDCOM specific tags. So where a Standard tag does not exist, I create use a “custom tag” in the same template. I also use several “functions” to grab pieces of data from, for example, the first paragraph in the multi-line SOUR.PUBL tag! It is these that most required my need for test material, and what frustrated be the most about the process!

Again, I could be asking too much from the request, sorry!

[Gary_G]

I would suggest that the "wish" should explicitly state that the goal is to; "Provide a solution that permits the user to both specify and immediately see the result of the template definition process, based upon one or more user-selectable sets of metafield data". If the design intent is not also explicitly stated as a goal, there could be many "hidden" user requirements that a wishlist item might miss stating.

While stating overall goals might be useful in a larger item of work, I'm having difficulty seeing the need for it here, given that the proposal is fairly short. "Immediately see" is probably a useful thing to add in, i.e. alter

a "preview" function that will show the resulting formats for Record Title, Bibliography, Footnote and Short Footnote.

to

a "preview" function that will show the resulting formats for Record Title, Bibliography, Footnote and Short Footnote without exiting the Source Template Definition Editor.

Adrian;
I've found your original description a bit difficult to conceptualize. I've found in writing specifications that a goal statement generally avoids a lot of programmer misconceptions and the need to be painfully explicit in exactly what the user expects to see. By all means; put in as much additional detail as desired, but it is usually not possible to explicitly specify every aspect of the desired feature in a typical-length Wishlist entry.

[AdrianBruce]

... I've found in writing specifications that a goal statement generally avoids a lot of programmer misconceptions and the need to be painfully explicit in exactly what the user expects to see. By all means; put in as much additional detail as desired, but it is usually not possible to explicitly specify every aspect of the desired feature in a typical-length Wishlist entry.

Umm. As far as I am concerned, this is a "small" change, where I am responsible for defining what the user expects to see at the level of the User Interface. This is one of those instances where I find it more difficult to conceptualise the goal than to write down the specific changes. In a very real sense, I'm not introducing new functionality - I'm just pulling it into the Source Template Definition Editor.

[AdrianBruce]

... For example, it would be easy for CP to overlook reviews for Tools > Preferences > Sources > Generic Source Formats... and just focus their attention on Template Source Definitions.

Not sure what you're advocating here - as far as I'm concerned this request is solely about the Source Template Definition Editor and the introduction of a preview mode there.

There is a "however" that I am about to put into another post on this thread.

[AdrianBruce]

... Does the proposal need to explicitly mention any of the following:

1. Review of conditional formatting such as < angle brackets >
2. Sample data for GEDCOM standard fields used in formatting such as %SOUR.AUTH%
3. Review of Tools > Preferences > Sources > Generic Source Formats...

OK - so 3rd bullet: As I said above, I consider Tools > Preferences > Sources > Generic Source Formats... to be out of scope. Probably useful for me to state the scope explicitly.

1st bullet: Conditional formatting etc. Yes, I need to mention that, thanks, because it feeds into the need for multiple sets of sample data values per Source Template Definition.

2nd bullet: Sample data for GEDCOM standard fields used in formatting such as %SOUR.AUTH%. This opens up a can of worms in my view.

My mental model of the preview process was that sample values would be held for the Template Fields, as seen in the Source Template Definition Editor, and only for the Template Fields. When you mentioned "Sample data for GEDCOM standard fields" that hadn't occurred to me so I went to my notes and discovered a discussion that involved Record Title, Footnote, Short Footnote and Bibliography Formats all containing items like

• {%SOUR.AUTH%}
• {%CUR~CITN.PAGE%}
• {=GetLabelledText(%SOUR.NOTE2%,"Date:")}

Now, I have zero idea of the "correct" way to enter such GEDCOM items in the Source Template Definition Editor - but I did hack them in by manually editing the Footplate format etc to add the GEDCOM item. In other words, they were not set up as Fields. (Told you I didn't use Templated Sources except as experiments...)

(Feel free to tell me how I should have got those items in...)

But the worrying thing about these GEDCOM items is how can we possibly label them and so specify sample values for them, given that they are intended to be in GEDCOM Source-Records at the closest, or Citations to GEDCOM Source-Records, or labelled text within a Note or ... (Because the Source Records and the Citations to them haven't been created yet... )

OK - right now I'm lost. And the question I need to ask is, am I specifying preview functionality for two (arbitrary guess) people when I try to think about preview functionality within templates for non-templated GEDCOM items?

[tatewise]

Surely it is up to CP to decide how to implement the requested functionality and whether they implement all the features we would like. We just have to mention all aspects of the request that would be useful.

Reviewing Record Titles, Footnotes, and Bibliography involves all means of formatting those with Templates.
IMO since standard GEDCOM fields and Generic Source Formats are supported by FH they should be included.

[KFN]

While I agree that a request can’t suggest code to CP, the request can use words to suggest a path to the solution.

Words like: “Test potential template designs against a set of record instances from a specified project, before adding the template to the project!”

[tatewise]

I don't think anyone is disputing that kind of request.
The latest discussion is about whether specific features of template design previews should be highlighted to ensure they are not overlooked by a misinterpretation of the general goal statements.

For example, the words you propose are fine in principle but:
Does "potential template designs" include Tools > Preferences > Sources > Generic Source Formats... or might it be misinterpreted as only applying to Tools > Source Template Definitions...?
Does "a set of record instances" include standard GEDCOM field values such as %SOUR.AUTH% used in templates or might it be misinterpreted as only applying to defined metadata Template Field definitions?

None of those highlighted features suggest to CP how to code the solution. They simply provide clarification of the features to consider when implementing the solution.