* On Hold until 13 Dec 2024: Diagram Text Schemes: Family of Variants

For Wish List Requests that need more work before they can be progressed to the Wish List, because after 3 months, discussions have not arrived at a clear specification of the requirement such that one or more Wish List items can be raised. Items On Hold that are not subsequently refined to a state suitable for the Wish List within a year by the OP or other interested parties will be closed. If the OP feels unable to progress the request, they should ask for volunteers among other interested users to assist.
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

On Hold until 13 Dec 2024: Diagram Text Schemes: Family of Variants

Post by dbnut »

This request concerns maintaining a family of related diagram text schemes, with common layout and style, but with different levels of detail (content).

It builds on ideas arising from Wish List Request "Edit Text Scheme: Block Operations".

Context:
  1. I try to maintain several text schemes for different purposes, including a verbose version for everyday use (gives me a comprehensive view in my habitual navigation via diagrams - zoomed out for a broader view when necessary). A minimal scheme works for full-tree views, and intermediate detail is possible with further scheme versions.
  2. Maintaining consistency between these is more than just "desirable", but a lot of work (making parallel changes to a set of 3 or 4 variants) that could be avoided in an ideal world.
  3. While text scheme files can be edited manually, this is not only clumsy (I think schemes need to be exported and re-imported?) but also a very dangerous process. The file structure is much more "decomposed" than the compact view displayed by the scheme editor proper.
  4. By analogy with the philosophy of distinguishing/separating style from content, would it be possible to maintain a single Text Scheme for "style" and find another way to select "content"?
  5. I do not mean to suggest that one single text scheme could be "adapted" for all purposes!
Obstacles:
  • The present Text Scheme editor works so well, there is a big disincentive to any major change.
  • The same applies to scheme file structure.
  • To extract the full value from content customisation, almost the entire set of properties in the various Diagram Options tabs would need to be associated to individual Text Schemes, rather than depending on a diagram-level setting (or the effectively global current default).
  • Of course, this is no small task.
Suggestion:
(the first two obstacles would be circumvented by this approach; the third avoided in a phased implementation that delays the last two suggested features)
  1. Provide for begin/end labels serving as Block delimiters where applicable.
  2. Add Conditional "Execution" for labelled blocks.
  3. Add a new Text Scheme property, (e.g. "Variant"), to serve as the flag for conditional "execution".
  4. Provide a method for changing the "Variant" value to any of those already defined in the scheme.
  5. Permit that property change from the Diagram Window (a context (right-click) menu from blank area of the diagram would be far the most convenient).
  6. Provide a limited set of sub-properties from amongst those elsewhere in the Diagram Options dialogue (even just the Dimensions tab property "Maximum box width" to start with).
  7. Extend the above to more Diagram Options properties.
Benefits:
  1. where related variants of a text scheme are created, a major improvement in maintaining consistency while avoiding repetitive edits and chances of error.
  2. the opportunity to rapidly modify a diagram view to suit the task in hand (e.g. changing between a global view and detail for individuals).
  3. extending the feature to have control over maximum box width would greatly improve the appearance of "smaller" formats and allow denser packing within the diagram.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

I have been trying to get my mind around how to make better use of Diagram Text Schemes - particularly since diagrams are my major working environment. Therefore I am sympathetic to this suggestion provided we do not make Text Schemes more complex by default.

I struggle with "management of text schemes". I originally had three main schemes
  • Minimal : Names BMD (dates and places) for seeing a lot of generations on one diagram
  • Full : almost everything imaginable to assist with actual "doing genealogy"
    • Probable source of names (e.g. Presbyterian naming conventions, c/d Surnames as forenames)
    • Baptism
    • census/residence/occupation
    • education/professional memberships
    • military service
    • Wills/Funeral/Burial/Probate
    • Relationship details: engagements made/broken, marriages/separations/divorces/widowing
    • Passport Applications/Emigration/Immigration/Voyages
    • Witness information in both principal and witness boxes (which I have not managed to do satisfactorily to date)
    • Sense checking data (e.g. Ages at marriage) and "completeness" data
  • Publication : Full but with some of the above omitted making for more manageable printed charts
However
  • keeping "Full" and "Publication" in line requires conscious effort
  • some management is "fiddly"
  • I may want the level of detail to vary by person (This I manage with flags and conditional text lines, but it feels clunky)
Ideally I would like all the above to be one scheme (making correction/amendment/enhancement easier) with an easy way to switch features "in" or "out" at the diagram/chart level. This could involve switching blocks of lines "in" or "out" - but that does not address where for instance in the "Full version" I might want say place and address detail, but in the "Publication version" I might want only place detail. Likewise for compactness in the "Minimal" version I might want dates to be "year" only. Switching different versions of lines in or out reintroduces the problems of keeping changes in line!

My requirements may be too specific to enable them to be generalised into the main product without overcomplicating an area that many already find too complex - but perhaps others have similar issues or better solutions.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by AdrianBruce »

Also a diagrammer!

Somewhere in all the above, I think I agree on the need for tweaks - my own particular (remembered) bugbear is that I did (at one time) print diagrams with different font-sizes ranging from 8 point down to "Yes, I can read it - I'm near sighted..." That seemed to require me to have different text-schemes varying only by font size. Except before long the "varying only by font size" bit became "varying by font size and - oops - the bits that I've done on my normal scheme but not the small-print version".

Strikes me that some sort of styling, à la Word etc, could take the font size out of the text scheme, rather than have it hard-coded in there. NB - I have no idea how - or if - I handled box size differences.

The above is just one thought. I might add that when I upgraded to v7, I deleted virtually all my custom text schemes on the basis that I'd recreate them as required rather than attempt to bring them to a consistent state and convert.
Adrian
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

Are you familiar with Cascading Style Sheets as used in webpages? Something similar might do what we want.

Thus:
Master Style Sheet that applies across your FH application, unless specifically over-ruled by:
Project Style Sheet that applies across its project, unless specifically over-ruled by:
DIagram Style Sheet that applies across a diagram, unless specifically over ruled by:
Individual-in-Diagram Style Sheet.

The style sheets could specify how you want specific items styled:

Name(m) {color: blue; font-size: 16pt; font-weight: 200%;}
Census {colour: black; font-size: 12pt; font-weight: 100%;}
Census.notes {colour: black; font-size: 10pt; font-weight: 100%; indent: 0.5cm;}

This might sort out appearance; with care it might also help with content:

Census.notes {visibility: hidden;} applied in a Diagram Style Sheet would hide all census notes, whilst Census.notes {visibility: visible;} applied in an Individual-in-Diagram Style Sheet would return census notes to visible for the individual specified.

The normal CSS rules would take us a long way - with extensions to handle things like the :SHORT :MEDIUM :TIDY :FULL qualifiers on place (and similar for dates) might get me to where I want to be. Just switching the "Diagram Style Sheet" from minimal.css to full.css (where those sheets held various rules such as those above) would allow me to quickly switch between two appearances.

CSS can control much more than text - it can control boxes, backgrounds etc.

Part of the trick is to implement such a scheme so that it is understandable - but some of the existing WSIWYG CSS editors might give clues with links to the relevant style sheets via context menus?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by tatewise »

Now that is an interesting concept, which could be applied to all display aspects of FH and not just Diagrams.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

But would that be FH8 or FH9?

It's not just "display" but also print; the @media rule allows you to change the formatting of a screen displayed page so that when printed you can use more appropriate colours and omit or change backgrounds etc.

You can get very clever with CSS on webpages.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by AdrianBruce »

davidf wrote: 20 Jan 2022 17:27 Are you familiar with Cascading Style Sheets as used in webpages? Something similar might do what we want. ...
Yes, that's a better description than my reaching for Styles in MS Word...
Adrian
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 20 Jan 2022 17:27 Are you familiar with Cascading Style Sheets as used in webpages? Something similar might do what we want.
[Just a few years ago I spent a week or so getting to know CSS. B***y hard work, but I learnt enough for this job:
Made a simple database prototype in Access to hold a Thai restaurant's menu (etc). Usual stuff like sections for starters, drinks, blah; sequence within section; how hot, veggie; price/availability for eat-in, take-away & window poster...
Simple program to output in the right sequence, adding markup as HTML. 3 versions of style sheet and that was that. Open x3 with a web browser and print (A3, A4, folded A4).
Thoroughly good entertainment. Couldn't remember how now, but proved what I'd always suspected - those web site designer hotshot kids don't deserve that much kudos.]

Since a brush with SGML and mugging up on it yonks ago, it is second nature to look for the content/style divide - but not always easy to get that just right.

IMO CSS would be amazing for diagrams, but only a tiny proportion of users will want to waste a life on that. A few standard templates would probably suffice, as now and - as has been noted - the results should be more scalable [how do you spell that?].

This approach would also defuse my frustration at the lack of tab settings (I use hanging indents a lot) and font changes within a line (sometimes would like bold or italic).

In the end, though, I'd settle for my original suggestions (plus tabs and maybe font changes). Life's too short for yet another diversion.

And I really believe any user who already modifies text schemes won't have trouble with such an "upgrade" - it won't even be visible except as an item camouflaged in Available. And it's not a trivial enhancement, true, but is a lot easier than many of the features added in V6/7, a helluva lot easier than CSS.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

AdrianBruce wrote: 20 Jan 2022 20:21 Yes, that's a better description than my reaching for Styles in MS Word...
Ouch.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 20 Jan 2022 15:14 ... This could involve switching blocks of lines "in" or "out" - but that does not address where for instance in the "Full version" I might want say place and address detail, but in the "Publication version" I might want only place detail. Likewise for compactness in the "Minimal" version I might want dates to be "year" only. Switching different versions of lines in or out reintroduces the problems of keeping changes in line!
find too complex - but perhaps others have similar issues or better solutions.
Am I dumb to think these are a piece of cake? Just repeat such blocks, modified for the different style/content, at the appropriate places. One or the other, or one of many, gets to be visible.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 20 Jan 2022 17:27 Name(m) {color: blue; font-size: 16pt; font-weight: 200%;}
Census {colour: black; font-size: 12pt; font-weight: 100%;}
Census.notes {colour: black; font-size: 10pt; font-weight: 100%; indent: 0.5cm;}
Please, take it away, I might change my mind.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 20 Jan 2022 18:54 It's not just "display" but also print; the @media rule allows you to change the formatting of a screen displayed page so that when printed you can use more appropriate colours and omit or change backgrounds etc.
You know too much for my liking :lol:.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

Yes CSS can be complex if you hand code it.

But we don't "hand code" GEDCOM; FH does that for us.

The take-aways from CSS could be:
  • The conceptual separation of "content" from "style"
  • The concept of cascading style sheets. FH would come with a "Master Style Sheet" (conceptually it already does); the user can (optionally) then edit that style for global changes, but can also (optionally) over-write it at different levels (Project, Diagram, Individual within a Diagram) - thereby gaining potentially massive flexibility.
  • The introduction should not "look like another technology" but just a cleaning up and enhancement of existing formatting options. The CSS code quoted above would not be visible to the user just as raw GEDCOM is not visible to users. The means to set or edit formatting can be accessed:
    • Master Style Sheet - from some Global Preferences (Tools, Preferences in V6) dialog. For new facts the Fact Creation dialog can propose default styles which would get added to the Master Style Sheet file.
    • Project Style Sheet - from some Project Preferences dialog (defaults drawn from the Master Style Sheet).
    • Diagram Style Sheet - from the existing Diagram Right Click context menu - or the existing (V6) Diagram Options menu (defaults drawn from the Project Style Sheet).
    • Individual-within-Diagram - from the Select Individual, Right Click Context menu - or from an toolbar item on the Individual Properties Box (defaults drawn from the Diagram Style Sheet).,
      and even possibly(!)
    • Fact-within-Individual-within-Diagram - from the Fact Tab on the Individual Properties Box - an additional icon (below the fact pane) to enable the style of a specific fact to be changed (so we could highlight any particularly significant fact - e.g. Voyage from US on Lusitania in May 1915)*
  • Trying to avoid duplication and to allow reuse of "styles" - so create a style for one diagram and be able to use it for another.
  • The user interface for implementing something like this is key. It may be that we have something very similar to the existing text scheme dialogue, but style items like "font change lines" are removed. The "Edit Text Scheme Item" (as it is called in V6) would have items like font and colour choice added alongside the indent details. Default Values would come from the Master Style Sheet - unless over-written by the Project Style Sheet etc.
  • * I have to admit that I don't know how a style sheet can reliably reference a specific fact because unlike records there is no "System ID" in the GEDCOM on which to reference the fact. Perhaps something similar to the way we can reference a specific census with census[1881]?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by tatewise »

@davidf, regarding your last point about referencing a specific fact, it depends on what you mean by specific fact.
English is very poor at describing such entities. There are various interpretations with Data Reference solutions:
  • One single unique specific fact for an Individual with a specific Record Id and a specific instance of the fact:
    INDI[RecordId].ABCD[Instance] where ABCD is the Fact tag or Name.
  • Any specific type of fact regardless of the Individual or instance:
    INDI.ABCD where ABCD is the Fact tag or Name.
  • Any specific type of fact filtered by its Date, Place, Address, Flag, etc:
    INDI.ABCD.DATE:YEAR = 1881
    INDI.ABCD._FLGS = Preferred
  • Various combinations of the above using Data References and Expressions.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 21 Jan 2022 11:24 ... The take-aways from CSS could be:...
David, so far out of your league, I have no way of replying usefully to all that. :)

Great stuff, and I'm 100% in favour of adopting some kind of CSS-based approach to presentation throughout FH.
Yes, as long as it's under the hood.

For all we know, Calico may already intend to go down that road, even be experimenting now.
Maybe they're looking at SVG.
Maybe...

For my part, as said before, I'd still be really happy to have this "blocks enhancement" to schemes.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

tatewise wrote: 21 Jan 2022 12:01 @davidf, regarding your last point about referencing a specific fact, it depends on what you mean by specific fact.
English is very poor at describing such entities. There are various interpretations with Data Reference solutions:
  • One single unique specific fact for an Individual with a specific Record Id and a specific instance of the fact:
    INDI[RecordId].ABCD[Instance] where ABCD is the Fact tag or Name.
  • Any specific type of fact regardless of the Individual or instance:
    INDI.ABCD where ABCD is the Fact tag or Name.
  • Any specific type of fact filtered by its Date, Place, Address, Flag, etc:
    INDI.ABCD.DATE:YEAR = 1881
    INDI.ABCD._FLGS = Preferred
  • Various combinations of the above using Data References and Expressions.
Yes, but!

Unlike record IDs which are pretty constant (changing a record ID is not something users normally do because it messes with references), facts cannot acquire similar unique and constant IDs.

You might enter say an event in 1916 and refer to it as ABCD[1], but what happens if a user innocently adds a similar event in 1914 or even March 1916? The "instance" is not stored in the GEDCOM but is more an instruction to FH to scan the GEDCOM and extract the specific instance.

I think our database experts would be vary wary of trying to reference a fact in such a way.

To unambiguously reference say a specific voyage in 1916 on the Lusitania, you would have to create a unique one-off (for the individual concerned) custom fact?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 21 Jan 2022 13:00 Yes, but!
I'm fascinated by this discussion (though most of it goes over my head).

From my point of view, the subject matter has much broader potential and consequences, deserving more focused debate.
Would you be agreeable to moving this to another topic?
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by tatewise »

The discussion need go no further than to say that if unique fact id is deemed necessary by CP, then a Fact Id tag could be designed (such as _FACTID) in the same way that _SENT, _SDATE, _SHAR, _SHAN & _FLGS have been created.
Actually, the FH v7 Fact Flags _FLGS support <New Flag> custom values that could be used as unique Fact Id in the same way that Custom Id can be used as unique Record Id that are immune to changes to the GEDCOM Record Id.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

dbnut wrote: 21 Jan 2022 13:50
davidf wrote: 21 Jan 2022 13:00 Yes, but!
I'm fascinated by this discussion (though most of it goes over my head).

From my point of view, the subject matter has much broader potential and consequences, deserving more focused debate.
Would you be agreeable to moving this to another topic?
I'm agnostic - but the moderators may not be!

I think we have correctly corralled this discussion in the right forum (New Wish List Requests) which is used for
  1. testing whether an idea can already be achieved by other means
  2. trashing out the details of an idea - which can also open it up to wider considerations
  3. testing whether there is general support for (or against) an idea before CP start to be lobbied for a feature
The moderators (and you) may feel that I have excessively broadened the scope of the discussion (under [2] above) in to a wider discussion of potential improvements to the presentation of data - particularly in respect of diagrams.

I'm not on V7, (but I get the impression that it is not significantly different to V6 in relation to diagrams and text schemes) and I am wondering if it is time for a possible zero-code type rethink of diagrams (rethink not necessarily recode).

There seem to be a number of concerns (from a very small minority of users - but that is always the case) that this whole area is capable of improvement. I may well have strayed too far into the "how" rather than the "what" (the "how" in closed source software is very much the responsibility of the developer), but by considering "potential hows" you can start see "potential and consequences".

If anything I would merge your latest wish list entry (Diagram Window: Box Views "Exploded") into this item - as it to seems to be dealing with "how the user can better manage the presentation and control of data in diagrams".
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 21 Jan 2022 15:19 I think we have correctly corralled this discussion in the right forum (New Wish List Requests) which is used for ...

The moderators (and you) may feel that I have excessively broadened the scope of the discussion (under [2] above) in to a wider discussion of potential improvements to the presentation of data - particularly in respect of diagrams. ...

I may well have strayed too far into the "how" rather than the "what" ...

If anything I would merge your latest wish list entry (Diagram Window: Box Views "Exploded") into this item - as it to seems to be dealing with "how the user can better manage the presentation and control of data in diagrams".
[Edit: New final line]

1. OK

2. Hope not, it has put my suggestions into a usefully broader context.

3. I think we benefited from that (which some will be aware of), helping to anchor at detail level before trying to distil the essence of "what".

4. Given all the above, I'd prefer a better-structured, somewhat broader proposal. It would embrace your "what" and could be fleshed out with a few examples from my own contribution.

I don't feel anywhere near competent to manage that myself (but happy to edit the "best bits", if any, from mine for inclusion).

What do you think now? And have you got time?

Spring-clean, new proposal, leaving the digressions and some detail aside. Easier to review.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

dbnut wrote: 21 Jan 2022 18:53 I don't feel anywhere near competent to manage that myself (but happy to edit the "best bits", if any, from mine for inclusion).

What do you think now? And have you got time?

Spring-clean, new proposal, leaving the digressions and some detail aside. Easier to review.
I don't think any "special competence" is required to develop wish list items because essentially we should be trying to shake out "requirements". Across a number of topics you have expressed some requirements and I have possibly extended those requirements (but also I think misunderstood some of your requirements).

I'm not sure a highly structured formal
  • "User Requirements",
  • "Functional Requirements",
  • "System Requirements"
process is appropriate as that requires knowledge of a process and significant time commitment. (My time availability will be impacted by my position on an NHS waiting list!)

What follows I have now lifted to a new post Improvements to Diagrams - seeking top level wishes/requirements as the discussion has widened / is widening to beyond the original post title.

However it is possibly a good idea to try and kick around the various user requirements (the "what"). We both admit that we use diagrams as our major working environment - but may well do so differently. For instance you are using a supplied text scheme, whilst I use a highly customised text scheme.

Can we scope out areas of requirements? And once we have scoped out the areas (and mutually understood them!) discuss in detail the requirements - I suspect there will be a lot of overlap. Once we understand the overlaps and inter-relationships we might be able to split our requirements into discrete requirements that can be separately written up?

My initial thoughts on scope:
  1. Displaying trees - possibly more complex that just ancestor or descendent diagrams
    1. Multiple (existing) trees in one diagram - does the current context menu "Insert into Diagram" option meet needs?
    2. Adding a new tree into a diagram - does the current menu "Add, into a diagram" option meet needs?
    3. Hard linking an individual who appears in two trees in the same diagram (to effectively join two trees) - Is the manual stacking of such individuals adequate and if they they were hard stacked how would we want redrawing of the diagram to work (like an All Relatives Diagram - which I find awkward)?
    4. Some sort of hover/click for more detail - for instance hovering over a spouse might bring up a summary tree of the spouse - parents and siblings
  2. Navigating (large) trees
    1. Someone elsewhere has mentioned the facility in the Ancestry online trees.
    2. Making trees more navigable - for instance a tree with less information gets more people on screen - but is clicking to bring up the property box an adequate way to see more detail?
    3. Accessing different levels of detail (e.g. summary for navigating and detail for researching)
  3. Text Schemes
    1. Managing some sort of hierarchy of Text Scheme Content and Styling
    2. Managing Text Scheme Content - across a number of Schemes
    3. Managing Text Scheme Styles - across a number of Schemes
    4. Different content and Styling for a specific individual compared to other individuals in the same diagram
    5. Different content and Styling for a specific fact for a specific individual compared to other individuals in the same diagram
    6. Improvements in the Item Editor - e.g. Advanced Syntax checker (beyond the V6 validate)
    7. Additional styling features (e.g. horizontal lines between say BMD info and Census info)
    8. Adding an icon on a fact line within a box (possibly to indicate certainty or main source?)
  4. Various tree "enhancements"
    1. Showing more than one picture per individual
    2. Control over intergenerational lines to indicate types of relationship (as with inter-spousal/inter-partner lines)
    3. DNA issues - e.g. lines which highlight common Y chromosome or common mtDNA (not my area!)
    4. Printing banner trees more reliably
  5. Other?
Last edited by davidf on 23 Jan 2022 09:41, edited 2 times in total.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
dbnut
Famous
Posts: 137
Joined: 05 Sep 2013 20:12
Family Historian: V7
Location: Isle of Wight, UK

Re: Diagram Text Schemes: Family of Variants

Post by dbnut »

davidf wrote: 22 Jan 2022 11:24 My initial thoughts on scope:...
Wish I could bookmark a post, instead of just a topic!
You've put a lot of effort into listing those areas for attention.
They must call for at least a dozen, possibly 20 or more, Wish List Requests.
I haven't got time at the moment to give much thought to this particular area.
Or make useful contributions to your list, I'm afraid.
Hope to come back to it later.
Paul White
"Family Historian is not just for Christmas, but for Life"
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by tatewise »

"Wish I could bookmark a post, instead of just a topic!"
Is that because you want to avoid scrolling through to the end?
I set my profile to display posts descending so the latest is at the top.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Diagram Text Schemes: Family of Variants

Post by davidf »

dbnut wrote: 22 Jan 2022 17:10 Wish I could bookmark a post, instead of just a topic!
You can!
You can copy the link location by right clicking on the title of the post and then paste it into the bookmark creation dialog - or (at least in Firefox), click and drag the post title into the Bookmark area!

(See also the links in your email notifications; "If you want to view the quoted post, click the following link:")

David
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Diagram Text Schemes: Family of Variants

Post by tatewise »

I suspect Paul was talking about Bookmarking in the FH Forum, not via his browser, which as you say is possible.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
Post Reply