Family Historian User Group

David, you still seem to be missing the point.
To be explicit, one Available Item is Name whose Type is Data.
That is not an Attribute nor an Event so where is its Diagram Block definition held?

The same question applies to Name (a.k.a.), Notes, Shared, Notes, Individual, Sex, Custom Id, Record Id, Life Dates, Ahnentafel Number, etc, etc...
None of those are Attribute or Event Facts so where are their Diagram Block definitions held?

If all those are held in some master Available Items Block Definition data structure then it would be more consistent to hold all the Attribute and Event definitions in that same data structure rather than separately in the Fact Type definitions.
So your proposal reduces to a single Available Items data structure with standard predefined entries supplied with FH that the user cannot edit but can clone and edit the custom clones. That is very similar to the concept of standard and custom Queries.

Ah, the difference has dawned!

(You may notice in my "mocked up" Selected Diagram Blocks I had selected Names & Titles - Detailed - treating the Name as any other "fact".)

tatewise wrote: ↑

13 Oct 2022 14:44

If all those are held in some master Available Items Block Definition data structure then it would be more consistent to hold all the Attribute and Event definitions in that same data structure rather than separately in the Fact Type definitions.

That may (realising that "Name" is not a "Fact") be the case. We could get hung up on where the data structure actually is - to an extent we are designing the solution rather than specifying the requirement (but sometimes discussing a possible solution flushes out issues).

I came at it from a Fact Type Definition, because my "new fact workflow" is

1. define the fact,
2. think about display in the Fact tab of the Property Box
3. think about how you want it in diagrams (my main work area),
   1. get it right in one Text Scheme and
   2. then laboriously copy it to all other schemes
4. set up any necessary queries

I can see that the dialogue to Edit Diagram Blocks needs to be accessible from both Edit Text Scheme and the Fact Definition dialogues. (Possibly also in Reports - but that is an unexplored area for me). For the user what is important is whether the dialogue and controls are available when you want them and organised and presented in such a way that the user is clear whether they are for instance editing the definition of one of their custom Diagram Blocks or a Diagram Block in a specific scheme.

The organisation of the presentation need not necessarily follow the organisation of the data - sometimes there are good reasons for that. As an aside: What would be the implications for instance of treating (for presentation to the user) the data type items as "facts". To me there seems little difference between %INDI.NAME% and %INDI.BAPM%. How do you, for instance, currently set up a sentence template for "Names"?

tatewise wrote: ↑

13 Oct 2022 14:44

So your proposal reduces to a single Available Items data structure with standard predefined entries supplied with FH that the user cannot edit but can clone and edit the custom clones. That is very similar to the concept of standard and custom Queries.

Yes? Although proposing a "data structure" might be thought a bit too "solution specification" rather than "requirements specification". I am concerned about the interface because wrapped up in this I want to see:

• Drag and Drop
• Preview
• Shareable Chunks of Scheme
• Chunks of scheme common to multiple schemes (changes being reflected in all)
• A presentation of text schemes that is less daunting on the surface but none-the-less more powerful
• A better division between the data being displayed and how it is displayed (heavily influenced by my experience with CSS in web-development)
• An ability to specify diagram appearance at Application, Project, Diagram, Specific Individual(s), and even specific block within an individual.

The latter I have not discussed in detail, but I can see a need to produce diagrams where the main ancestral line is in detail and everything else is in summary, that for certain key individuals additional data may be shown or some data may be shown in greater detail.

(So if you wanted to show how Wales lost autonomy to England in the 13th century, you need to see the ancestral line of Llywelyn the Great, the Ancestral lines of King John of England and to highlight the parentage and marriage of Siwan, (Joan, Lady of Wales). Ideally that requires multiples "styles" in the same diagram. Apologies for that summary of Welsh history!)

I'm glad I've got through

What would be the implications for instance of treating (for presentation to the user) the data type items as "facts". To me there seems little difference between %INDI.NAME% and %INDI.BAPM%. How do you, for instance, currently set up a sentence template for "Names"?

It is not currently possible to define a Sentence Template for Names, but that is because Names do not have narrative sentences in reports. What would such a sentence look like?

%INDI.NAME% does not support the %INDI.BAPM% fields such as Date, Age, Place, Address, Witnesses, etc, etc.
So when defining Text Scheme formats the codes that invoke those fields must be inhibited and complicates the GUI.

You have only focussed on Name fields to the exclusion of all the other Calculated, Data, Identifier, or Pre-Formatted Data types I listed, including Notes, Sex, Custom Id, Record Id, Life Dates, Ahnentafel Number, etc, etc, that IMO can't be treated as Facts.

davidf wrote: ↑

12 Oct 2022 22:03

... For most users who are advanced enough to want to define a new Fact, would I think also find it logical (particularly for those who "work in diagrams") to want to also consider various ways the fact information could be displayed. (As it is already envisaged you would consider the sentence template). ...

I'm not convinced. There's a very basic level at which I might wish to slap something down as a marker, but I feel that when I create the fact, potentially with witness roles that I really haven't sorted out in my head yet, then I'm not yet interested in sorting out the layout on a diagram.

There may be an important distinction between my "working in diagrams" and other peoples' working in diagrams. I use diagrams to show relationships, add new children, parents, etc, and act as a visual index of a limited group - therefore I only show certain events and attributes (BMDs, other PR stuff, censuses and names is not far off the total). Therefore I'm not likely to think diagram representation at fact definition time. Indeed, I probably envisage that I won't show the new fact at all, unless something happens to make me think "Wow, wouldn't it be useful to show the lease attributes that I've been collecting, on a new sort of diagram?" But this would be later, I'm sure of it.

But in all conscience, if the same stuff is accessible from both places (fact definition and text schemes?) then it may not matter greatly. I'm just saying that I don't think I'd be accessing via the fact definition route myself.

The narrative sentence angle is a bit of a counter argument against my instinct, except that since there is (currently) only one narrative sentence, then it's a 1 to 1 mapping between definition and sentence, and therefore possibly it doesn't matter too much where it goes.

Yes, I think that you've got there with Mike's points - but here's a screen shot "I made earlier" before you had... The Identifier type and Calculated type items don't appear in the Fact Definition dialogs (because they're not input values per se) but do appear in the Edit Text Scheme dialog - it's therefore logical for then to appear only in the latter when it comes to their diagrammatic representation. And there's a Custom Item as well, that definitely can't come up at Fact Definition time.

So for me, I'll still be thinking about accessing this stuff at Edit Text Scheme time.

AdrianBruce wrote: ↑

13 Oct 2022 16:38

There may be an important distinction between my "working in diagrams" and other peoples' working in diagrams. I use diagrams to show relationships, add new children, parents, etc, and act as a visual index of a limited group - therefore I only show certain events and attributes (BMDs, other PR stuff, censuses and names is not far off the total).

That's exactly what I do. I always work with diagrams (I have FH set to open on the Records window, never use the Focus window) and I have a custom diagram type which displays BMDs, baptisms, burials, occupations and censuses, with my preferred colour coding for the boxes. For any extra details I refer to the individual's facts tab. I also have a couple of other custom types which I use occasionally for other purposes.

I created these years ago and have only needed to 'tweak' them once (to add "(?)" to the text scheme for facts which I have flagged as Tentative in V7). So if the proposed diagram 'Blocks' had existed they might have saved me a few minutes several years ago but I don't think I would ever have needed them again. In all honesty (and I say this as an avid diagram user) I still think this would be a minority interest, even among diagram users. That doesn't mean it's not worth creating a Wish List item, just that it might be a very long wait for it to be implemented!

AdrianBruce wrote: ↑

13 Oct 2022 16:38

since there is (currently) only one narrative sentence

As I said before, there are multiple Sentence Templates; one for each installed Language Pack.

tatewise wrote: ↑

13 Oct 2022 18:35

AdrianBruce wrote: ↑

13 Oct 2022 16:38

since there is (currently) only one narrative sentence

As I said before, there are multiple Sentence Templates; one for each installed Language Pack.

Yeah, sorry I forgot that aspect. For me, there is only one narrative sentence and even were I to exploit different language charts, it would still be one logical sentence. Just in different translations...

Except... As Mike said, there is the possibility of exploiting multiple language packs in English to concoct different sentences in English. Though that might be a solution in search of a problem for me, right now....