* Fact Sets, Text Schemes and Hierarchies

[davidf]

This is not yet a fully formed "Request", but I hope with assistance that we can knock it into shape.

I am getting increasingly frustrated with Fact Sets, Text Schemes and Hierarchies. I am currently on V6, but I have not read anything that makes me thing that V7 is any better; perhaps V8 or 7.x even?

I work mainly through diagrams and therefore when I create a new Fact I almost inevitably have to edit my text scheme. I rarely use reports.

I also (for reasons discussed elsewhere - size management (in my head not on disk) and need to ensure no accidental privacy breaches) work with multiple projects.

Hierarchies

I therefore have (or want to have) a hierarchy:

• Application default Facts and Text Schemes (as installed)
• Application customised Facts and Text Schemes
• Project customised Facts and Text Schemes
• Diagram customised Facts and Text Schemes, and even
• Individual customised Facts and Text Schemes

(Some might also want (lumped) Sources to fit this hierarchy as well)

So we might have for instance a Marriage Fact defined by Calico Pie, together with a set of text schemes that use that Marriage Fact.

I might customise those Facts and Text Schemes (even add additional ones) - and want them to be available to all projects (Let's be fair and say all projects under the \Family Historian Projects\ folder)

Within a specific project I may want to customise them further - say the project is to handle individuals in the US - there may be US specific facts or ways that I want those facts displayed (for instance death certification and notice of burial I seem to remember is different).

Then within a diagram I may well want to use a customised text scheme (possibly even customised or custom facts)

Then at individual level I may want to customise further - currently I do this by setting flags on the individual and using them as conditions to switch in or out certain facts or formats - which can get a bit mind boggling.

This can mean a lot of exporting and importing of fact sets and text schemes and gets messy. I am looking for a tidier way of managing this.

Text Schemes

I also find text scheme management gets messy because you either work at the macro level (a completely new text scheme) or you work at the micro level (at a diagram line level - except it isn't because of formatting).

I have tried to hack this around previously (influenced by Cascading Style Sheets in web-pages) but ended up getting too solution orientated rather than requirement orientated.

When you define a new Fact Type, you get a default sentence template - which presumably is used by reports - which you can edit. I would like something similar for diagrams in terms of a self-contained block of lines ("diagram blocks" usually the fact on one line and indented fact notes on the subsequent line - possibly cycling through all instances of that fact).

The diagram block could contain formatting information (typeface, size, colour etc., indenting etc.) - if it did not it would inherit the defaults of any scheme into which it was incorporated. At the moment a line in a text scheme takes what ever text format was being used by the previous line.

I would like to be able to define a new fact at Application, Project or Diagram (or even individual) level and to do the same for diagram blocks - others might like to be able to do the same for sentence templates. Likewise for customisations of default or previously added facts. Thus if I improve the diagram block for marriages (mine is pretty complex), I might well want that customisation available to all projects. (Management Issue to consider)

To add functionality I would like to be able to define alternative diagram blocks (or sentence templates) - for instance "Brief", "Comprehensive" etc. Text schemes would then consist of a series of diagram blocks - rather than the current assembly of lines of code.

For new users they can select different installed blocks say for "marriage": Choose "brief" - one line giving spouse, date and place, through to "comprehensive" - multi line for all that individual's relationships: with whom, date started, date formalised (and where), dated ended, means of end (death, divorce etc.). This can avoid needing to struggle with expressions; users just select a Name block, a Birth and Baptism/Christening Block, A relationship Block, A Death and Burial Block, A Will/Probate/Administration Block, A Census Block, An Occupation block, A Research Planning block etc.

Because these diagram blocks are pretty self-contained, they should be share-able in the way we share queries etc.

"Comprehensive" Marriage Block

Screenshot from 2022-10-10 14-56-06.png (3.85 KiB) Viewed 1710 times

Providing the "code" to produce the above is currently non-trivial and developing it required lot of to'ing and fro'ing with Mike. To share it would not currently be easy. If someone in the future was to enable a diagram block which used say the name at the time of marriage (e.g. Camilla Parker-Bowles), sharing the change would not be easy. But you could just share a new Marriage Diagram Block.

Management & Control!

"Block Management" could be through the existing Fact Type dialogue - modified to both handle diagram blocks as well as sentence templates and to allow the definition of alternatives. In a streamlined Text Scheme Management dialogue you would just select diagram blocks with an option to create/edit a block which takes you through to the Fact Type Edit dialogue.

Managing the hierarchy is potentially difficult. either you get a mass of different definitions for different places in the hierarchy, or you hold everything at Application Level (with suitable descriptions) and have a means of filtering so that specific definitions (e.g. "US Death and Burial - Comprehensive" diagram block) are visible/hidden from specific Projects/Diagrams/Individuals. Managing on a "same as (a higher level in the hierarchy) except" basis is probably going to be too challenging to understand without a very good interface.

Well implemented you could produce diagrams that have comprehensive details for those in your main ancestral line, different level of detail for cousin lines, and a possibly sparser level of detail for others (for instance related through marriage). Likewise reports might one day be able to produce different levels of detail according to the individual's place in the tree.

When "working with diagrams", I would like to be able to select an individual and either switch in a more comprehensive text scheme or just a more comprehensive diagram block to cover say greater census detail or military service (ACW, WW1 WW2 tec.) or a complex will or a research audit block.

I suspect that Calico Pie must be looking at improving the interface to text schemes and diagrams to make them both friendlier (i.e. easier) to new genealogists or FH users and manageably richer to more experienced and demanding users. I think to do this needs a rethink about how diagrams are produced. The same may be true of reports.

[AdrianBruce]

Let me just throw in a particular use case that I think David's idea might help with. Essentially I have just two Diagram Text Schemes -

• AB Research prompt w census (8pt)
• AB Name, Dates only

The first is used for 99% of my diagrams (and I work 99% of the time from a diagram). The last is used only to create pedigree charts containing just the name and life dates.

Originally, I had three variants on that first choice - the one I listed; a variant on that with no census dates; and a 5 point version of the first created when I had access to an A3 laser printer (yes, it was in the office, and because it was a good quality laser, I could read the 5 point).

The issue was when I wanted to add something new to AB Research prompt w census (8pt) (such as adding an "Ashes Interred" event) I had to decide whether I wanted to add it to each of the other two. Inevitably, sometimes I remembered, sometimes I forgot, so that the 3 schemes weren't close variants and eventually I deleted the other two.

If a content block could be defined that was inheritted by both the 8 point and the 5 point version, then that would have helped keep those two in line - especially if the font size was recorded as a "style" of "standard" and "big" that mapped in each diagram type to 8 and 9 point or 5 and 6 point.

Not totally sure how I'd like the census-less version to be defined - possibly three blocks - top, census and lower, say, with the census-less version using just top and lower. But I've not thought that bit through.

One might ask why not clone the 8 pt text scheme and alter it each time I added new event types? I'm not sure why I didn't - maybe it seemed a tricky thing if I wasn't totally sure what the differences were between the 3 schemes.

Having said all this - I worry about concepts like inheritance being understood by "normal people". I even wonder how many of them create their own diagram Text Schemes.

[LornaCraig]

David,

Like you I work with diagrams a lot but I don’t have so many different text schemes. My main working text schemes includes occupations and censuses, with addresses, but for less common facts I just refer to the Individual’s Facts tab. I can see the potential of your suggested “diagram blocks” but I suspect it might be a minority interest because many people don’t use diagrams much.

Picking up on two of the items in your hierarchy:

Project customised Facts and Text Schemes
As you don’t have V7 you may not be aware that it does offer the ability to create project-specific custom facts.

Diagram customised Facts and Text Schemes
This sounds like saving a diagram as a Diagram Type, which I often do. It preserves the combination of colour coding, text scheme, number of generations etc. in other words all aspects of the ‘style’ of the diagram. Is that what you mean? (Note that this not the same as saving it as a Chart, which additionally preserves the diagram root, hidden boxes and exact layout.)

[ColeValleyGirl]

Lorna's just made the point that I was going to make, about it possibly being a minority interest...

I'd also worry that it could make customising diagrams, fact sets etc. look even more complicated to the uninitiated. But to be fair, they're pretty complicated already

[AdrianBruce]

...
Diagram customised Facts and Text Schemes
This sounds like saving a diagram as a Diagram Type, which I often do. It preserves the combination of colour coding, text scheme, number of generations etc. in other words all aspects of the ‘style’ of the diagram. ...

I think what I was searching towards is closer to easier ways of modifying similar text schemes for use in multiple Diagram Types. E.g. to add "Ashes Interred" to the 5pt and 8pt versions of the text scheme in one go. Basically, I suggest that the contents of text scheme - i.e. what's printed, should be independent of style, i.e. looks, of text scheme. Then the content could be altered once.

At the moment, it feels to me like everything gets bundled up into the Diagram Type and if you want to alter something across the board, you need to alter all Diagram Types, one at a time, whereas conceptually it might be the same change across all types (e.g. addition of ...)

Another aspect is that, IIRC, my 5 point diagrams had smaller boxes (no real point if the boxes were the same size as the 8pt versions) - but I don't think I found a way of independently storing that aspect without generating multiple saved Diagram Types. It felt like I was proliferating Diagram Types when I only wanted to save one aspect of the Diagram Type. Again, there wasn't the independence that I might hope for. But this is a touch of an aspiration rather than a precise specification.

I take Lorna and Helen's point that, paraphrasing, many people never get beyond the Focus Window. Conversely, some people have massive text boxes on their diagrams!

[davidf]

Replying with thoughts triggered by some of the responses so far.

Diagram Types

These I have never found myself using - but they may be a means to manage settings across projects or diagrams within a project.

Hierarchies

I think I am still struggling for clarity with the existing Hierarchies. If I get to understand it, I will try to write a knowledge base article - whilst hoping someone will beat me to it! The Help system is fairly silent on the sort of details that I am looking for. What follows is my understanding from intensive use of parts of V6 (which is another way of saying that in some places my knowledge is very shallow!).

For instance if I save a "Diagram Type", is that then available only within that project, or is it available application-wide? As a "template" I would want it to be available application-wide.

If I modify my text scheme (even just adding a comma between a place and an address), is that modification then available across the active project, or is it available application-wide? I fear the former - which means you can have identically named text schemes in different projects doing different things. It's like variables in coding, you either want them to be clearly"global" (i.e. application-wide) or you want them to be clearly "local" - with an indication of what they are "local to" (project or even diagram?). Or is it specific to a Diagram because the scheme has been saved as part of a Diagram Type?

(It may be worse. The little bit of "diagram code", which I modify - with the extra comma in the example above, I may have copied to multiple text schemes and if those text schemes are used in multiple projects, cascading the minor modification is a major task. Hence my trying to formulate a wish list request which includes creating text schemes from "diagram blocks" (say for "Census details", or "Relationships") - which I ideally would like to be "global" (application-wide), so that by modifying the single global block, that modification cascades through everything. Inevitably there may be circumstances where some may want a "local" diagram block rather than an alternative "global" block.)

In V6 Facts are sort of global (?), so presumably sentence templates are as well; why not also (by analogy) "diagram blocks"?

I would also like styling of diagram elements to be definable at global or varying degrees of local. For instance, I would like to be able to say "by default in all my diagrams in all projects, I want census details to be blue 8pt. etc." or "by default I want all diagram boxes to have rounded corners and blue or red shadows depending on the sex of the individual". I might then at project or diagram level (or even individual level) want to specify local styling (say something fancy for printing).

At the moment it is a bit of a mess, unless you put in a specific formatting line, census details take whatever format was previously defined; and if you put in a format line it then effects all subsequent elements. Moderately advanced users of spreadsheets, word-processors etc, are used to tailoring these default formatting matters, and new spreadsheets/documents etc then taking those defaults (even using templates for "different defaults") and then specifically formatting particular elements, why not for FH projects?

As you don’t have V7 you may not be aware that it does offer the ability to create project-specific custom facts.

Partly answers a similar question about facts and associated definitions (e.g. the current "sentence template" and "fact tab template" - behind the advanced button). Again is it clear what are "global facts" and what are "project facts"?

A new source is clearly (!), project-specific, but I would really like them to be application specific - if only to get the spelling of the name consistent across projects (useful when merging etc.). Because sources are held in the GEDCOM as specific records, this may have to be realised by a different means when compared to other items mentioned above.

Use of diagrams and text schemes

I'd also worry that it could make customising diagrams, fact sets etc. look even more complicated to the uninitiated. But to be fair, they're pretty complicated already

many people never get beyond the Focus Window. Conversely, some people have massive text boxes on their diagrams!

I can see the potential of your suggested “diagram blocks” but I suspect it might be a minority interest because many people don’t use diagrams much.

A lot of this is chicken and egg! "If it is complex people don't use it; if it is little used, why try to improve it?"

I think there is so much that could be done and I feel that an overhaul of the whole diagram formatting, text scheme editing area must be up for renewal, as I said in my initial post, to make it easier for newcomers, but accessibly powerful for advanced users.

Part of this relates to the User Interface (surely "drag and drop" has to be coming to editing text schemes!?), but part relates to the underlying functionality.

This moves a bit into the area of specifying a solution rather than a problem, but ... here goes.

I would like the text scheme editor to be a three column design compared to the current two column design.

The addition column (logically the right hand one) being a sort of "preview" using data from say a copy of an individual from the sample project (one with a lot of facts!).

Three Panel Text Scheme editor using Diagram Blocks

Screenshot from 2022-10-11 13-45-47.png (79.29 KiB) Viewed 1583 times

The left hand one instead of being the large range of "available items" is replaced with "available diagram blocks" arranged by fact - possibly with frequent ones at the top of the list (as we have with fact selection in the fact tab). So you might have a line that says "Census" which is a "concertina" or accordion" control. Clicking on the arrow opens up the accordion to show all the available "Census diagram blocks" (minimal, detailed, comprehensive, supplied by FH, and then custom ones built by the user etc.). With a mouse you can grab one of these and drag it to the centre panel and place it in the order required (no more adding at the bottom and multiple clicking to move it up to the right position). Grabbing an unopened accordion control for say "census" would drag the default "census diagram block" into the desire position in the centre panel. New users might never have to open an accordion control.

As per my original post definition and editing of diagram blocks would be done via the fact definition dialogue - just as sentence templates are currently managed. The main difference being that you could have multiple alternate diagram blocks (minimal, detailed, comprehensive etc.) with the ability to clone to create custom blocks. Fact-level default styling would also be handled here.

Within the text scheme dialogue there would be an option to open the Fact definition dialogue for a fact selected in the left hand column.

Specific styling (if required) would be done by an option on the third "preview" column which would open a panel (that could occupy the area normally occupied by the first two columns) that would give WYSIWYG options that would be reflected in the preview panel. This could be done either at the diagram box level or at the fact block level.

Stock take

I have wondered whether this is two wish list items wrapped up together (improving text schemes and hierarchy management). However I feel that because so much of this is dependent on some form of determination of what is global and what is local, they need to be, at least initially, considered together.

Non-programmers may dislike the idea of "global" and "local" - I use the concept here to draw the analogy with coding (and the inherent benefits and issues). In realisation we may instead talk about "scope"; does this item apply to

• just an individual's diagram box
• a specific diagram
• a specific diagram type
• the project
• to all the projects in the Family Historian Projects directory

[tatewise]

David, in FH V6, virtually all customisations are global. They affect all Projects on the PC in the same way.
That goes for Report Types, Diagram Types, Text Schemes, Queries, Fact Sets, Plugins, Flags, Icons, etc, etc...
There are a few exceptions including Websites & Family Tree CD/DVDs and some Tools > Preferences.
See FHUG Knowledge Base Understanding the Scope of Features for details.

The only significant difference in FH V7 is that local Project only Fact Sets are supported.

[davidf]

David, in FH V6, virtually all customisations are global. They affect all Projects on the PC in the same way.
That goes for Report Types, Diagram Types, Text Schemes, Queries, Fact Sets, Plugins, Flags, Icons, etc, etc...

Thanks for both the reference and the confirmation, I think I may have got mislead by the fact that I think for instance Text Schemes get cached when a project is open, so if you have two projects open, a change in the text scheme of one will not be reflected in the other (unless you close and reopen it). Presumably that may apply to a few other items as well?

[tatewise]

It is not clear when customisations are saved/loaded, especially as some are held in files and others in the Windows Registry.
So having two instances of FH open at the same time whilst changing customisations could have unexpected consequences.
I would advise against customising with two instances of FH open at the same time.

[AdrianBruce]

... Moderately advanced users of spreadsheets, word-processors etc, are used to tailoring these default formatting matters, and new spreadsheets/documents etc then taking those defaults ...

But slightly playing devil's advocate here, my experience is that very few "normal people" use styles in MS Word (say). Or perhaps those who do, use the ones that are there, but just apply hand-crafted formatting to things that aren't "obviously" matching the supplied styles. Even I, who am quite happy to concoct all sorts of styles in MS Word, have never touched equivalent features in Excel. Heck, I don't even have consistent default footers in my spreadsheets.

I know there's a chicken-and-egg argument - but there also has to be an irreducible minimum of complexity and I worry that getting more sophisticated might "frighten the horses."

To add some specific comments for myself:

• I don't think that I have a need for printing different fact types differently - beyond the name;
• I do (or did) have a need to manipulate font sizes and box sizes together - the 5 point version of the normal 8 point charts destined for the A3 laser printer, had smaller boxes, IIRC;

Does this imply my choices are in a different dimension than David's? Not sure....

[davidf]

But slightly playing devil's advocate here, my experience is that very few "normal people" use styles in MS Word (say). Or perhaps those who do, use the ones that are there, but just apply hand-crafted formatting to things that aren't "obviously" matching the supplied styles.

But we are talking about computer using genealogists not "normal people"!

We unfortunately don't know how many people just use FH "out of the box" in the way that many early users of MS Word used it "out of the box" and put up with American paper sizes - even going so far as to buy "Word compatible" paper. We would probably be surprised at how big that majority is - they just use FH to produce basic diagrams with Names and BMD detail.

But operating systems and applications have become more configurable often with hand holding installation / first start routines that do some basic configuration showing that complexity can be hidden from newish users - and can be made easier to access by more mature users.

Often it is a case of pushing the complexity back deeper into the application. Thus in this instance I am thinking about pushing much of the complexity of Text Schemes back into sub-dialogues of the Fact Definition screen, thinking that people are more likely to want to slightly change the appearance of diagrams than do surgery on Fact definitions.

I think the way that my thoughts are shaping up is to make Editing a Text Scheme a "point and drag" exercise with no obvious coding. If users want to go further they either discover how to create/edit "diagram blocks" themselves through thinking - fearlessly - "wonder what happens if I click on this icon with the tooltip that says 'configure'?" or they are pointed that way by one of: the Help Screens, the Knowledge Base, or this forum.

If schemes are more easily configurable (by clone and edit), we might be able to reduce the number of text schemes initially offered (currently two screens worth) to a more handleable and less daunting set?

Data References and Formulae look daunting and should be wherever possible pushed back to a depth that is only visited by those who want to "do things" that can only be done by direct interaction with data references and formulae.

[AdrianBruce]

... I am thinking about pushing much of the complexity of Text Schemes back into sub-dialogues of the Fact Definition screen, ...

I don't see the virtue of putting the Text Schemes into / under the Fact Definitions. Surely presentation of the fact should be defined separately from the structure of the fact? I might want several definitions of the presentation of the Census fact for display in different diagram types.

Mind you, one might say the same about the definition of Narrative Sentences... Although there is only one type of Narrative Report (forgetting about the choice of who appears) and potentially several radically different diagrams.

[tatewise]

I might want several definitions of the presentation of the Census fact for display in different diagram types.

Mind you, one might say the same about the definition of Narrative Sentences... Although there is only one type of Narrative Report (forgetting about the choice of who appears) and potentially several radically different diagrams.

I believe the Publish > Miscellaneous > Individual Timeline report uses Sentence Templates and there is nothing to stop any Report Plugins from using them. Actually, even Text Schemes can use them via the =FactSentence () function.

In FH V7 the Fact definition has a Go To Language Variant... button to work with each of the installed Language Packs. So the chosen Language invokes its own Sentence Template.

A similar feature could select alternative fact displays in Text Schemes based on some user criteria. Actually, you could do it now by defining a dummy 'Language Pack' for each different Diagram Text Scheme display.

[AdrianBruce]

...
I believe the Publish > Miscellaneous > Individual Timeline report uses Sentence Templates ...

So it does... Never realised that.

I was trying to justify why I didn't worry about seeing the Narrative Sentence as part of / directly under the Fact Type definition, with the excuse that there's only one of them. Apparently not so, especially if there are dummy "language packs"!

[davidf]

Adrian, we may just be at a point of disagreement but ...

When you create a new fact, you create a new "Available Item" in the list of "Available Items" on the Edit Text Scheme dialogue.

If you select it, you then get a dialogue that allows minimal (code-free) customisation:

Text Scheme Item customisation (V6)

Screenshot from 2022-10-12 16-00-50.png (9.7 KiB) Viewed 1418 times

That then creates one or more lines of "Scheme"

Text Scheme with new item added (V6)

Screenshot from 2022-10-12 16-05-58.png (32.02 KiB) Viewed 1418 times

If you wish to customise further you have to get into the code and if you ask for help in the forum, you end up transcribing any code that is offered. This is unlike say for queries where you can be offered a download to share - unless you share the whole scheme - and then try to merge schemes and get rid of the bits you don't want.

That issue would point towards recognising a "diagram block" as an entity - which amongst other things can be exported and then shared. It could then appear in the list of available items and be available to any of your text schemes - if we started to think of the list of available items in a slightly different way. The alternative would be to import it directly into a single text scheme via effectively an import into the right hand column of the existing Edit Text Scheme Dialogue. That would make the block primarily an entity related to the Scheme in question.

Data Structure

Thinking of a diagram block as an "Available Item" means that it is in effect a "Meta Fact" - available to any scheme and therefore more related to the facts in question. (There is for instance no reason why someone should not develop a series of "Birth & Baptism" diagram blocks where you might chose to only display baptism details if the birth details were blank.)

We are on the border line between your "structure" and "presentation" warning and I am trying to get my mind around how your keep them separate (which I think - like you? - can be beneficial).

The Diagram Block as I envisage it is about the structure of the various parts of the information that may be stored against a fact (or facts) - date, place, address, cause, age, witnesses etc. and which it is desired to display. Again this pushes me towards saying the "diagram block" definition is a subset of the fact definition (like the sentence template).

With good design a lot of this can be set up either in the set of diagram blocks that would come with a vanilla installation (e.g. a variety of diagram blocks with alternative levels of information about say a census) or created automatically when we create a new fact.

When we create a fact, just as a default sentence template is automatically created, we could have say three "standard" diagram blocks defined. These might be for instance:

1. Date - Event/Attribute, Place (Brief) [one Line]
2. Date - Event/Attribute, Place (Full), Address [two lines - Normal Default]
3. Date - Event/Attribute, Place, Address, Notes [three lines]

By cloning and editing, other diagram blocks can be created. This might be done with an improved variation of the existing Edit Text Scheme Dialogue (as "Edit Diagram Block Dialogue").

By talking about "lines of display" I could be accused of straying into "presentation", but this is actually quite close to recognising the structure of the data in the GEDCOM.

Presentation

In terms of presentation of these structures in a diagram, default typeface details are defined at the Text Scheme level - presumably the default typeface details used when a new text scheme is created are taken from some setting somewhere (I expected to find it in (V6) Tools, Preferences - but it does not appear to be the Display default and I don't have a Diagram default).

Once you have selected Measurement in Tools, Preferences, General, it would appear that default indents etc. are hard coded.

Names in schemes also appear to have some hard coded defaults (Centred, bigger typeface etc.).

If these sorts of defaults do not suit, do you want to be able to "globally change them" or do you want to edit every scheme to match your preferences? It looks like the latter at the moment. If you want to change the "default" presentation in diagrams of say the census fact, where is the logical place to set them? To me a dialogue associated with the fact would be the logical place to set them. In practice when you create a fact the associated standard diagram blocks would take on the system default styles. If having cloned a block to have an alternative diagram block, you want that block to have an alternative style, logic would associate that style definition with that diagram block definition.

Associating the style with the diagram block would break the current problem of styles being set in a scheme line where if you set a style for a current fact line or lines, you have to accurately set it back to whatever it was before to avoid subsequent facts having that style.

When you drag a diagram block into scheme, the preview pane would show both the data structure defined in the diagram block and show it presented in accordance with the associated style.

Without going into too much detail a diagram block placed in a scheme could have two options accessible either by right click or by icons. One option would be "ignore diagram block style" (in which case the specific text scheme defaults would apply). The other option would be "edit style" allowing the specific diagram block in that specific scheme to be specifically customised. (This would operate very much like Cascading Style Sheets in website development - The root style sheet contains "system defaults", which would be inherited unless you had specified different scheme faults - which would be equivalent to a webpage's specific style sheet, The diagram block (in a scheme style) would be in some ways similar to <style> tags).

Aside: An extension to this idea might be to pursue your division of data structure from presentation. The association of a diagram block with a style (which could imply that under the hood, the style is stored with the data structure definition) could become the ability to associate a diagram block with one of a choice of diagram block styles. Then within the scheme as well as being able to edit a specific "diagram block within a scheme" style as detailed above, you could also swap the style. (Following the web development analogy the diagram block could have a style sheet associated with it. Each diagram block is like a "<div>" with a "class" and if required an "id"; the class would specify the default style for that diagram block, but an id would over-ride it with a specific style.) For those who have hand-crafted web-pages with html and css this will be familiar. For those who are not, this further extension is probably a step too far unless it can be hidden behind an advanced button.

[AdrianBruce]

David, I don't have any problem with what you said in the response above. Customising in the "Add Item to Text Scheme" dialog to either a minimal degree (as now) or maybe to a deeper, future, degree, seems fine to me.

My concern is that I had got the impression (rightly or wrongly) that you were suggesting shifting(?) stuff from here to the earlier "Fact Definition" dialog. Because I could see multiple options for how the Census event (say) could be output in a Text Scheme, it seemed inappropriate to include them in the original Fact Definition of Census. Not least because I think there might be more than just the Census data in the Text Scheme for a "Census"...

If that ("Add Item to Text Scheme") is as far back as you want to push the stuff of Text Scheme definition, then I'm fine with that.

[tatewise]

David, you are correct that it is not clear where the Text Scheme default font is defined.
If a standard Text Scheme is reset using Restore Defaults then the font is Arial, 9 pt, Black.
However, if a New... custom Text Scheme is created, its default font is Tahoma, 8 pt, Black.
( That is my experience but it might be different for others. )

I understand your proposal for diagram blocks, but using Fact Type definitions only partially resolves the Available Items.
If you sort the Text Scheme list of Available Items by Type then Fact Type definitions might work for Attribute and Event, but what about Calculated, Data, Identifier, and the other Types?

[davidf]

...
My concern is that I had got the impression (rightly or wrongly) that you were suggesting shifting(?) stuff from here to the earlier "Fact Definition" dialog. Because I could see multiple options for how the Census event (say) could be output in a Text Scheme, it seemed inappropriate to include them in the original Fact Definition of Census. Not least because I think there might be more than just the Census data in the Text Scheme for a "Census"...
...

I'm seeing the Fact Definition Dialogue as the natural home for defining diagram blocks for displaying those facts - but in practise the difference may not be that obvious.

To many users, the difference may be scarcely noticeable - except that when they start trying to enhance their text scheme it is hopefully simpler.

When they access their text scheme they see a three panel dialogue - as I mocked up earlier.

Using Diagram Blocks mock-up

Screenshot from 2022-10-11 13-45-47.png (79.29 KiB) Viewed 1380 times

Say they don't like the current census block which would be the "Census - detailed" block that FH would supply as a default in the example above. With drag and drop they can try the other two supplied standard census blocks - which will probably satisfy most users.

In the Available Diagram Blocks you will see "Diagram Block Groups" - which are accordions which can be opened to show the available Diagram Blocks in the Group. Most "Facts" will have a Diagram Block Group with probably three alternative displays of various amounts of the information associated with a Block (for instance: minimal, detailed and comprehensive).

I would suggest that these "Diagram Block Groups" are sorted so that the most common ones appear at the top of the list, followed by the more obscure ones. (This follows the way that the "Add Fact" icon works in the Facts Tab).

But what if the available Diagram Blocks don't suit? You clone the nearest match and edit. Now where and how that works may look different to where in system terms it fits.

I would envisage two ways to create the clone and go to the Edit Diagram Block dialogue. If you are in the Edit Text Scheme dialogue and you discover you need a new Diagram Block, you would could use a context menu to "Clone this block and go to Edit", or possibly click a small icon on the actual block. This would open a new dialogue to Edit (the cloned) Diagram Block. In practice it would look like a stripped down version of the current Edit Text Scheme Dialogue (but with the addition of a Preview pane and drag and drop of the familiar "facts" or "custom item"). You then build the block as you would build a scheme - effectively a fact or facts specific micro-scheme. When you exit the Edit Diagram Block dialogue you would be returned to the enhanced Edit Text Scheme dialogue and the new block would appear in the left hand pane under what ever Block Group your specified.

Logically however I think this function should also be accessible from the Fact Definition dialogue. 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). The Fact Definition dialogue on clicking "Diagram Blocks" might expand to show a couple of additional elements which would display the names of the Diagram Blocks that use the Fact and which gives a Preview of what a selected diagram block would look like. It too would have the context menu or icon options to Clone and go to Edit. For non default standard (i.e. user created) blocks, it should also be possible to directly edit without cloning?

Extension of Fact Definition Dialogue to preview Diagram Blocks - Comprehensive Relationships being previewed

Screenshot from 2022-10-12 22-53-27.png (93.83 KiB) Viewed 1380 times

The above detail could be displayed by the Fact Definition dialogue expanding as shown or could be via a pop-up dialogue - which might be easier in terms of screen space on laptops.

We don't need to design how CP would actually structure this standing (i.e. non genealogical) data, but my feeling is that if you tried to draw out a schema (I wish I still had the program that let me draw database schemas) you would find that the Diagram Blocks and Diagram Block Groups are more closely and complexly related to Facts than they are to Text Schemes - but with a dialogue available from both the Fact Definition dialogue and Edit Text Scheme dialogue, the difference is probably not important to users.

Adrian, have I understood your last post and more importantly have I to some extent answered it?

[davidf]

...
I understand your proposal for diagram blocks, but using Fact Type definitions only partially resolves the Available Items.
If you sort the Text Scheme list of Available Items by Type then Fact Type definitions might work for Attribute and Event, but what about Calculated, Data, Identifier, and the other Types?

I'm not sure what you are referring to when you talk about "Calculated, Data, Identifier, and the other Types?" It may be a V7 thing but in my Available Items list in the V6 Edit Text Scheme dialogue, I have Attributes and Events and a few items ate the top of the list - <Custom item>, <Font change ...>, <No Record Text>, <Picture Marker>, and <vertical Gap>.

Font change would be redundant as it would now be with the Diagram Block Style - with defaults set when the block is defined, or specific instances of the Block in a Scheme having its style edited via the Preview Pane. The others I might Group behind an "Advanced" Diagram Block Group accordion. Others might also be redundant if styling is either diagram specific or diagram block specific.

But are you referring to something else?

[tatewise]

I have just checked that the FH V6 Edit Text Scheme Available Item Type values are very similar to FH V7.
Click the Type column header and scroll down to see all the Type values that I mentioned.

I would suggest that these "Diagram Block Groups" are sorted so that the most common ones appear at the top of the list, followed by the more obscure ones. (This follows the way that the "Add Fact" icon works in the Facts Tab).

David, you are mistaken about the order of the Add Fact entries. They are primarily sorted by Normal Time Frame, then by whether they are Individual or Family facts and the Fact Set order, and finally alphabetically. Whether they are common or obscure (however that is defined) has nothing to do with it.

If I understand your proposal, the user only edits Available Diagram Blocks and never Selected Diagram Blocks.
So if for example the Census - Detailed block was changed it would impact every Text Scheme that had selected that block.

[davidf]

I have just checked that the FH V6 Edit Text Scheme Available Item Type values are very similar to FH V7.
Click the Type column header and scroll down to see all the Type values that I mentioned.

Ok, I see what you mean - it is the items that I referred to in my last reply to you.

[davidf]

David, you are mistaken about the order of the Add Fact entries. They are primarily sorted by Normal Time Frame, then by whether they are Individual or Family facts and the Fact Set order, and finally alphabetically. Whether they are common or obscure (however that is defined) has nothing to do with it.

The "common ones" are on the "fast-add menu":

Facts - Fast Add Menu - showing Common Facts with access to "More" (V6 - customised)

Screenshot from 2022-10-13 12-20-53.png (77.38 KiB) Viewed 1326 times

This has the benefit to newcomers of not swamping them with options. Items are deemed "common" either by CP "out of the box" or by the user checking/unchecking the "Fast-Add Menu" in the Fact Definition dialogue. (The above Fast-Add Menu has additional items that I have "checked".)

I am suggesting that something similar is done with an improved Edit Text Scheme dialogue - put the "common" Diagram Blocks "above the fold" (i.e. accessible without scrolling in the default dialogue size) with either a "More Block" which when clicked shows the other Diagram Blocks, or with the others following, possibly with a colour cue to indicate that the "list" has two sections - "common" and "less common".

Within that division I would not argue for changing the sort sequence you describe.

[davidf]

If I understand your proposal, the user only edits Available Diagram Blocks and never Selected Diagram Blocks.
So if for example the Census - Detailed block was changed it would impact every Text Scheme that had selected that block.

I would advocate that the Diagram Blocks supplied "out of the box" should not be editable - if you want something different you "clone and edit". A saved clone would then appear in the Available Blocks suitably named (possibly with a cue that it is a "custom Diagram Block" rather than a "standard Diagram Block").

I think that custom Diagram Blocks should be either editable (I may want a change to cascade through all uses of that block - that is one of my objectives!) or "cloned and edited" to create a further Diagram Block.

It may be advisable to be able to "check" some Diagram Blocks to be "hidden" (as can be done with existing Facts through the Fact Definition dialogue). I think that option should primarily be accessible through the Diagram Block Definition dialogue. As with facts in the Fact Types dialogue you may also have a "show hidden" check box (in the Edit Text Scheme dialogue).

I have suggested that a Selected Diagram Block in a specific text scheme should have its style specifically editable - using the WSIWYG right pane. I am not sure whether it complicates matters to also from that point allow edits of the data (non-style) elements for that specific use of a Diagram Block. If that is allowed I would suggest that access is not immediately obvious (put it in a context menu? - trying not to complicate it for newcomers, but provide richness of functionality to more advanced users). If that option is allowed I think on closing you should also have the option to save your changes to a new Diagram Block so that they are available elsewhere (and the Diagram Block is therefore exportable for others - which is another objective)

[tatewise]

I have just checked that the FH V6 Edit Text Scheme Available Item Type values are very similar to FH V7.
Click the Type column header and scroll down to see all the Type values that I mentioned.

Ok, I see what you mean - it is the items that I referred to in my last reply to you.

Where in your reply do you mention the Type values Calculated, Data, Identifier, or Pre-Formatted Data as shown below?
e.g. All the Notes and Name items. Where is the format for those items defined?

AvailableItemTypes.png (46.29 KiB) Viewed 1312 times

[davidf]

in my Available Items list in the V6 Edit Text Scheme dialogue, I have Attributes and Events and a few items at the top of the list - <Custom item>, <Font change ...>, <No Record Text>, <Picture Marker>, and <vertical Gap>.

I've just referred to them by the name in the first column - the "Type" sort had never registered with me as something I would use.