* Website Tree Diagrams with Hyperlinks

[ACProctor]

One of my instructional videos shows an end-to-end "generate tree, create free website, upload tree and images" and then demonstrating it, all in about 10min ... unscripted.

I use neocities.org because as well as being free, it accepts the output from SVG-FTG with no errors or omissions. Many hosting companies force you to use their own design tools, and have little provision (unless you pay through the nose) for pages generated by specialised software such as SVG-FTG.

Tony

[ACProctor]

My understanding, once generated SVG-FTG does not need anything more that a web page host, to hold the files, the magic is done by the javascript and SVG file display. You simply generate everything on the PC and then upload all the generated files to your web page host.

Thanks Jane. That is correct. The generated output uses standard web-client technologies (HTML, etc), requires no web server (I can even launch the pages into my browser from my local computer), and SVG-FTG plays no further part unless you want to modify something (SVG-FTG is a design tool).

Tony

[tatewise]

It's pretty easy to find on Facebook, Mike.

Yes, but the Dropbox page does not obviously identify whether it is V6.0 or V6.1 and the associated blog focuses on V6.0 with a link to V6.1 that requires a return to V6.0 to find the 'Where is SVG-FTG?' Dropbox link that suggests it is V6.0.
I still maintain that somebody discovering SVG-FTG for the first time will struggle to find the V6.1 download.

I have now installed SVG-FTG V6.1 and the folder problem with opening the Tree.txt file is fixed.
However, I am still on a steep learning curve.

I've invoked SVG-FTG from a plugin script to automatically translate a Tree.txt file into a Tree.html file using:
isOK, intErr, strErr = fhShellExecute( "C:\\Program Files (x86)\\SVG\\SVG.exe", strPath.."Tree.txt -L -P")

At present that leaves the SVG-FTG program window open and requires the user to click Exit.
That prevents the plugin from invoking SVG-FTG repeatedly on a series of family tree files.
So there needs to be an extra command-line option such as -E to cause SVG-FTG to automatically Exit.
It would also be necessary for the SVG-FTG program window to be hidden, otherwise, as the plugin invokes SVG-FTG repeatedly the window would flash on and off repeatedly.
Alternatively, the command-line could allow a list of Tree.txt files to translate into multiple Tree.html files.

On inspecting the HTML produced, there are several CSS style scripts that would be identical in every HTML family tree.
Ideally, the CSS scripts need to be created once as separate files that are called from each HTML file.

More importantly, are the horizontal/vertical tree layouts auto-produced by SVG-FTG acceptable to everyone?
BTW: The two posted yesterday have been slightly 'manually tweaked' so are better than what SVG-FTG auto-produces.
They are very different from the GEDmill and WordPress tree layouts posted earlier.

[ColeValleyGirl]

Mike, will it be possible to have Gedmill as an option alongside SVG-FTG; and to allow to exploit the options within SVG-FGT to customise their output. So the SVG-FGT output doesn't have to be acceptable to everyone.

[ACProctor]

I think you're expecting a different release scheme to the one employed here, Mike. There is only one place to get SVG-FTG and it will always be the latest version. Each version undergoes extensive testing before release, including by "beta" volunteers, but I do not have the bandwidth to support concurrent versions, parallel updates, patches, or whatever. Hence, the issue of finding V6.1 rather than V6.0 does not exist.

I suppose, in retrospect, it should have had a dedicated website, but the interest has been weak until V6.0 came out. I can still do this but it took months to get Cyndislist updated the last time.

The option to close SVG-FTG is easily added but hiding the main form is more difficult. I would need to think on that one.

P.S. Thanks for finding the glitches. These will all be addressed in V6.2.

Tony

[ACProctor]

My own wish-list also involves a command-line option to load a GEDCOM file. Would that help if I implemented it? It might be easier than you having to generate the 'tree definition file' syntax. Does the plug-in interface provide this alternative or just API to access persons and families?

Tony

[tatewise]

Yes, Helen, it is almost certainly possible to have GEDmill, SVG-FTG, and other tree generators as alternative options.
At least, that is what I was intending ... eventually

Hopefully, it should be possible to allow users to customise the SVG-FTG auto-created trees somehow.
However, it is too early to be certain, and from what I've seen that would involve users customising a lot of trees, because the Auto Layout feature currently does not produce tidy traditional family trees such as GEDmill and FH Diagrams, and also often has crossing lines, hidden lines, and hidden marriage blobs.

Tony, the FH plugins have an API into all the FH project data, can read & write almost any files, and invoke any programs.
Being able to load a GEDCOM file would be useful for creating a tree for an entire Project, but even with the pan & zoom features offered by SVG, most Projects would be far too large and complex for that to be useful.
What we are focusing on is 3-generation family trees to supplement the Family Group Sheet or Individual Person textual reports produced by the FH publish website wizard. It is fairly easy for the plugin to create the Tree.txt file format apart from the (row,col) numbers that position the boxes tidily. The plugin can allocate each generation to successive rows, and each member of the same generation to successive columns in chronological order. What is more difficult is avoiding crossing lines for marriages, and centralising parent boxes above their children.

[ColeValleyGirl]

Tony, the Gedcom command-line option would be useful, if not in the context Mike is thinking about. I'm not convinced "that most Projects would be far too large and complex for that to be useful."

[tatewise]

FYI: Attached is the SVG-FTG Auto Layout HTML file for the Family Historian Sample Project of 104 people & 42 families.
However, SVG says it loaded 111 persons, which is a bit odd, and the correct number of families.

The file has been compressed into a ZIP folder because HTML files are sensibly not allowed as attachments.

IMO: Projects with thousands of people would be unwieldy and difficult to tidy the layout manually.

[ACProctor]

The problem, otherwise, Helen, is that the SVG-FTG notes stored for each person and family are derived from collected GEDCOM event data, and includes mark-up to support applications such as the Timeline Reports. It would be asking too much to duplicate that effort in the plug-in.

It can, of course, put whatever notes it chooses for each person/family, but it would limit the choice of applications that a user may want to add.

Tony

[ColeValleyGirl]

IMO: Projects with thousands of people would be unwieldy and difficult to tidy the layout manually.

I agree -- but I suspect that many people (like me) have much smaller projects for specific purposes. I have a project for my investigations into my sister's father (identifying who he might be). I don't want to put it online, but I would like to take a website to her on a laptop and let her click around. It has 170 people in it... and autogenerate produces a quite useable tree.

[ColeValleyGirl]

It would be asking too much to duplicate that effort in the plug-in.
Tony

I'm not sure what this is referring to?

[ACProctor]

Mike, the disparity in the number of persons is due to SVG-FTG ensuring that every family (defined as a married couple and/or biological parents in the docs) has a pair of spouses. It will have created unnamed persons where necessary. The green "family circles" depend on this.

Regarding size, this is about the limit of what I generate for my family to see because it just gets crazy, otherwise ... especially if you include spouse ancestors and in-laws. It reaches a stage where you cannot separate lines cleanly. This is the reason why V6.0 added Viewpoints: subsets of the total tree where clicking on a person gives you the option of navigating to them in other viewpoints.

Tony

[ACProctor]

It would be asking too much to duplicate that effort in the plug-in.
Tony

I'm not sure what this is referring to?

I was referring to the effort required to collect up all the event data and apply the proprietary event mark-up that SVG-FTG employs in its notes. That was quite a lot of effort for me, especially as I made it reversible (e.g. event mark-up going back to separate events when exporting as GEDCOM).

Tony

[tatewise]

The point that may have become obscured in the discussion is the difference between the way the SVG-FTG product is designed to be used and the way we are hoping to use it in conjunction with FH published website pages.

1) SVG-FTG is designed to produce a freestanding webpage with full navigation aids and clickable box icons that can do things such as popup notes about the person, &/or display an enlarged image, all derived from a GEDCOM file and its Media files. It is these popup notes that Tony is referring to ~ open the HTML file I attached and click on any box.

I have not investigated Viewpoints yet ~ still climbing the learning curve.

2) For FH website pages we need less dynamic small family trees. Popup notes are not needed because the FH report pages provide all the facts. Enlarged images are not needed because the FH report page images have the Lytebox popout. What we do need is to click a box and open that person's FH report page. May be that is the Viewpoint feature.

[ColeValleyGirl]

Tony, I agree that the Mike's plugin shouldn't have to collect much data for the 'less dynamic family trees'. I'm thinking of uses outside that context, however -- using the product the way it is designed to be used. (I still would like to use it in the context Mike is referring to, and might fork his plugin when it's ready to add bells and whistles that others may not want.)

[ACProctor]

Popup notes are not needed because the FH report pages provide all the facts. Enlarged images are not needed because the FH report page images have the Lytebox popout. What we do need is to click a box and open that person's FH report page. May be that is the Viewpoint feature.

Good point, Mike. Proving a clickable URL per box is trivially easy so I shouldn't worry about that -- that's the sort of stuff SVG-FTG does almost out of the box. Viewpoints are quite different and allow navigation between different SVG trees.

One small question about the clicking: if you clicked on two boxes, would you expect their FH reports to open in different tabs or in the same tab (i.e. the second one displacing the first one)?

Tony

[ACProctor]

Slightly different subject folks, if you do want to do something with SVG-FTG (I understand if not) then I will produce a beta with some enhancements (and fixes) in. I was going to release V6.2 for Christmas but I'm happy to hold that back and add these things to it.

The main end-user features of V6.2 were tabbed content in the notes (there is a small library to support HTML tabs), and support for hiding the details of living and/or private persons. I doubt they'll be important for the plug-in.

There is a separate Dropbox folder where I distribute the beta kits. It's identical to the standard folder but just not advertised outside of the beta groups.

Tony

[ColeValleyGirl]

support for hiding the details of living and/or private persons. I doubt they'll be important for the plug-in.

Hiding those details might be quite important, Tony.

[tatewise]

Tony, regarding clickable box links, currently in FH webpages, any link in one report page that invokes a different report page, uses the same tab as per the Internet recommendation. The GEDmill tree boxes embedded in each report page have clickable links that adopt the same tab strategy and I expect SVG tree boxes to be the same. So you can never click on two boxes.

However, if you are talking about a larger free-standing SVG tree, then clicking a box could open a report page in a new tab by using the target="_blank" attribute. Then clicking another box would be reasonably expected to open yet another new tab. However, the alternative is to follow the FH model and all clicks replace the current tab. That is what FH does for the Index page that lists every Individual. Click any Individual name and the tab is replaced by their report page. BUT at the top of every FH webpage there is a shortcut menubar link back to the Index page and other key pages. SO in the SVG case there could be a shortcut menubar link back to the master tree page from every report page. Does that make sense?

Some of the ideas being discussed here may warrant a beta trial version although I cannot realistically see myself getting deeply involved in integrating SVG into FH webpages until after Christmas.

[ACProctor]

Thanks Mike.

Regarding the action of links, I ask because there are really 3 possibilities:

* Open in same tab (i.e. "_self"). Despite recommendations, this is only useful when navigating some hierarchy of pages. For more complex applications, where you want to keep your frame of reference, then it's rather dumb.

* Open is a new tab (i.e. "_blank"). This is used by SVG-FTG for most of of its situations since the end-user wants to see something alongside their original frame.

* Open in dedicated tab. SVG-FTG uses this for viewpoints (where you never want the same named viewpoint opened in multiple tabs) and its image album (where a dedicate "display tab" handles the filmstrip imaging and responds to search queries).

However, it's not rocket science for me to provide whatever option you prefer in your case.

Tony

[tatewise]

Yes, I concur with your descriptions. For me, the best solution is to make it an option in SVG.
If we only pick one of those three modes then some users of the plugin will inevitably want a different one.
So it would be best to give them the choice.

My Improve Website or CD DVD HTML plugin lets users effectively choose between _self and _blank for most links.

As I said, the way FH circumvents the frame of reference dilemma is to put a menubar on every web page with a shortcut link back to the Index reference page.

[ACProctor]

There was an earlier comment, Mike, that CSS may be an issue. I should have said then that the standard CSS is designed to be customised using the XML file that sits next to the EXE file, or rather extra XML files (the standard one should not be touched) whose names match a given wildcard. This allows interactive applications to be reconfigured for each person to respond to different types of click, or on specific buttons located in the boxes, as well as reconfiguring CSS or other options. Or even to add custom applications.

One of the minor V6.2 changes was an improvement to the way CSS can be changed, thus making it easier.

There was a real issue that I thought of last night: if you're planning to include thumbnail images then there's a hole in the SVG specification that SVG-FTG has had to work around. When an image is scaled to fit the height or width of the allocated area then there will probably be invisible margins on the other edges -- unless the aspect ratio is identical to the area, which it almost never is. If you click on those invisible margins then it looks like you're clicking on the surrounding box but it registers as a click on the image. Actually, Firefox was doing things in a way that made sense -- registering this as a click on the surrounding element -- but they may have to change it to conform to the spec. The only way around this means you have to know the aspect ratio of each image, and SVG-FTG does all this behind the scenes.

Now this may not be a problem if clicking on either your images or surrounding boxes must do the same thing (i.e. follow a URL), but other interactive applications may need to distinguish later.

Tony

[tatewise]

My earlier comment was about style and script and defs chunks of script that appear to be (almost) identical in every Tree.html file that is created using the same SVG settings. In the context I am discussing, there will be dozens of FH web pages, each containing a family tree created by SVG using the same settings. The only differences will be the box & line arrangement and the text & image content. The style of them all will be identical. In such cases, it is often more efficient to put the common chunks of script into a shared file and import it using statements such as:
link rel="stylesheet" type="text/css" href="svg-style.css"
script src='svg-java.js'

Over the weekend, to provide a vehicle for experiments, I've written a plugin to insert SVG family trees into FH web pages.
It should run in any FH v7 Project and only affects the Public folder by creating an SVG subfolder for the working files.
The plugin lets you choose Horizontal or Vertical orientation for the SVG family trees.
It allows any FH Family record to be chosen one at a time to provide details for the SVG family tree.
The user must Exit the SVG-FTG dialogue manually for each tree, before reviewing the resulting web page.
( This is where the -E auto-exit and hide dialogue command-line option is essential in the end-user plugin. )
Do NOT experiment with any other SVG-FTG manual command options at this stage.
Although each SVG family tree is different, to keep it simple, the image in each box and FH web page are always the same.

Also, I've chosen to use a simple nuclear family tree design for the SVG tree boxes.
That comprises the four grandparents, the two parents, and their children, derived from the chosen Family record.
The siblings and other spouses of the two parents are deliberately excluded to avoid SVG Auto Layout complexities.
That may make exploring a family with multiple grandparents (i.e. birth, adoptive, foster), multiple spouses, and multiple siblings something of a challenge for the end-user, unless each box offers multiple links to the various relatives.

Another reason for the simple nuclear family tree design is that I found the SVG-FTG command line option -L 'perform an auto-layout operation' did NOT produce the same layout as using the Design > View > Auto Layout manual option. Tony, is that what you would expect?

Try the attached Improve Website by using SVG-FTG plugin Version 0.1 Date 06 Dec 2021.
Remember, it is only an experimental prototype, but for those who may be unfamiliar with FH web pages and how we intend to embed the SVG trees, it should be quite illuminating.

WebpageSVG.png (70.56 KiB) Viewed 2719 times

[ACProctor]

style and script and defs chunks of script that appear to be (almost) identical in every Tree.html file that is created using the same SVG settings

As I said, the standard CSS can be overridden through configuration of the installed files, Mike. The standard CSS will be identical, but it may not be the effective CSS.

As for Defs, they will be subject to different options and so cannot be guaranteed to be the same. Data is inserted into the Header*.* files to generate these Defs.

As for script, all the common support script IS in files. The code for the click handlers is generated dynamically and there is no single version.

Tony