* Ancestry, FTM, FH and workflow

[Nick-V]

Yes all true. We might leave it a day or two for any other options to crop up. Frankly, it might come down to option 0: what we have now (with minor adjustments perhaps). It might be the lesser of 4 evils as:

1. it looks best by far
2. with the default font (FTM only offers standard or large) it is correct nearly all the time and perhaps we could make it 100%
3. I hate MORE options but...we could give a choice 0 or 1 or 2 (not 3 for your reasons)

I like that 2 aligns data but the separate line and additional vertical space really does make it look poor...I'd rather have it good most of the time! Lets rest it in case we have a brainwave (although this is an age old issue).

[tatewise]

Agreed.
If you feel the urge to check all the 'pretty labels' they are in Plugin table dicGetTag around line 3600.
e.g. MARR = { Label="Marriage: \t"; F=0; E=1; }
where \t represents one tab character.

You may also like to review the other entries against each tag:
E=1; for Event tag that needs Address in its Description field.
I=0; for INDI level 1 tag (mostly Facts) with own local Note for subsidiary tags.
F=0; for FAM level 1 tag (mostly Facts) with own local Note for subsidiary tags.
I=1; for INDI level 1 tag to keep in record together with I=0 tags.
F=1; for FAM level 1 tag to keep in record together with F=0 tags.
N=1; for NOTE level 1 tag to keep in record.
S=1; for SOUR level 1 tag to keep in record.
P=1; for _PLAC level 1 tag to keep in synthetic Source record.
K=2; for INDI/FAM level 2 tag to keep in Name/Fact.
H=1; to hide level 1 tag from local Note if it is set to keep in record.

For hidden but kept OBJE & SOUR tags, their subsidiary tags are also hidden but kept.

All those with no such entry above, appear in local Note, but excluded from record.
(This even includes listed tags that occur at a deeper level, and custom tags such as Record Flags and UDF.)
One or two I am unsure about:
GIVN Given Name
SURN Surname
SPFX Surname Prefix
ALIA @I9@ where data value is a link rather than a name.

[Nick-V]

Quite a nice way of settings the rules! I don't quite know how best to respond but am willing to investigate.

I took the table and manipulated it into its components in Excel. I then compared descriptions with FH's descriptions:

1. Some are changed to make shorter - OK
2. Quite a few are changed for other reasons (Baptised=Baptism) - is this OK or not?
3. A very few we could get picky about like EMail versus Email and Record Ident versus Record ID, Standardised versus Standardized, etc.
4. One may be a typo - Bas Mitzfah versus Bat Mitzfah

I then looked at 1 versus 2 tabs, sorted them and pasted them into an FTM note (standard font). The alignment issues were obvious and I could recommend changes EXCEPT that we need to allow for (usually a predictable number of) indent spaces. Clearly I cannot feedback all the combinations but could certainly test some specifics. But this lead me to wonder if identifying levels with a single character might me better than variable spaces. Indeed the character could come after the pretty tag, perhaps enclosed in brackets etc etc. This would remove the variable element in tab handling and allow us to decide how many tags always work with that font. This I could confirm very simply, for example, Cremated should definitely have 1 not 2...

So, option 4, something like:

Code: Select all

Children [2]:>>99        <--- I like this one but recognise it means taking colon out of the table and appending in code
Children: [2]>>99
Children:>>[2] 99
Children:>>99 [2]

Of course we are assuming in all but the last that characters 1-6 (the potential levels) are all the same width (or close enough). I could then test all tabs with a both a thin 1 and a fat 8 and we could stick with a presentation that is pretty, compact and functional...?

[tatewise]

1. OK - also some use FH names, others use GEDCOM names, which are not always the same.
2. Several I changed from ...ion to ...ed to shorten them, but may have missed some, and Baptised just follows suit. FH is not entirely consistent: sometimes Birth soemtimes Born, etc. I am open to suggestions and corrections.
3. I don't like z in English words, FH often uses Record Id, I'm open to suggestions.
4. typo!

I am happy with using digit instead of multi-space.
All except the last require the same encoding, but not due to the position of the colon.
They all need the digit inserting, but that is not difficult.
The labels would take the form Children {9}:\t\t and the 9 is replaced with the actual level digit.
I would prefer not to use [9] square brackets to avoid confusion with [RecId].
(9) or <9> or {9} are possible, but I'm open to suggestions.
9) Children:\t\t
9: Children:\t\t
Level digit on the left will align digit and labels better than on the right.
Also 1 is slimmer than 2 is slimmer than 3, so there is a small indenting effect too!

[Nick-V]

OK...so I'll run thru the current tag list and send some suggestions...I noticed FH is not consistent, don't have any real problems with any to be fair, also hate "z" used instead of "s" which is why I picked on it...prefer ID than Ident...will post a list shortly for you to pick and choose.

Still thinking about presentation alignment options and pleased to be reminded of the obvious one...level on the left. Can't find a clear winner yet but gut feel tells me we need to emphasise the tag and value - the level is almost irrelevant from the users' perspective so I am still thinking right of the tag and perhaps right of the data. I accept the need to avoid [].

Here is a rough example (the indents work well...sad to loose them...this is a silly matter and not easy, where are tab stops and tables????!?!?). Jury still out...

Record Id (0): [I1]
Gender (1): M
Parents (1): [F8] ...of Julius SMITH and Gertrud SMITH
Spouse (1): [F3] ...of Gerald SMITH and Gloria Miriam SMITH
Permanent Ref (1): 36533819
Changed (1):
Date (2): 4 APR 2015
Time (3): 16:52:41

Record Id: [I1] (0)
Gender: M (1)
Parents: [F8] ...of Julius SMITH and Gertrud SMITH (1)
Spouse: [F3] ...of Gerald SMITH and Gloria Miriam SMITH (1)
Permanent Ref: 36533819 (1)
Changed: (1) <- problem here
Date: 4 APR 2015 (2)
Time: 16:52:41 (3)

0) Record Id: [I1]
1) Gender: M
1) Parents: [F8] ...of Julius SMITH and Gertrud SMITH
1) Spouse: [F3] ...of Gerald SMITH and Gloria Miriam SMITH
1) Permanent Ref: 36533819
1) Changed:
2) Date: 4 APR 2015
3) Time: 16:52:41

How can I display the tabs in the forum...tried spaces, tried /code...!

[tatewise]

These Forum postings are also useless at displaying tabbed text reliably!

I think the level digit is more important than you suggest.
In particular NOTEs and SOURces can be attached at many different levels and their context may be significant.

[Nick-V]

Perhaps so, although if they appear directly after something there is often an implied connection...but frankly, after coming back to look at the examples a few times, I am leaning toward the third example anyway, level first...simply because the space between level and tab aligns...pushed to a decision I think that's my choice. And if you feel the ")" is acceptable...I think we have to go with that?

To test tabs against the descriptions table...which numeric should I choose...I suspect a medium fat (and commonly used) 3 is as good as any?

[tatewise]

What about another colon such as:
2: Children: 1
Otherwise
2 Children: 1 could be confusing, especially if the value is accidentally omitted
2 Children: which suggests 2 children

Many tags only occur at one level.
For example all the Events & Attributes only occur at level 1.
ADDRess and PLACe almost exclusively are at level 2.
The Address subsidiary tags such as ADR1 & ADR2 only at level 3.
So they should be checked with just that level digit.

On the other hand tags such as NOTE can occur at many levels, so should be checked with digits 1 to 9, but give precedence to lower numbers if tabs are inconsistent, because Notes mostly occur at level 1 & 2 and sometimes 3.

[Nick-V]

I remember you used "~" at some point too!

The best so far for me is:

2) Children:{tab tab}3

I'll test tabs as described, for now please use the ones you already have and I'll identify issues with any of those.

[Nick-V]

List of descriptions: I suspect your definitely want to fix "bas mitzfah", use "ID", get rid of Z in "Standardized" possibly EMail capital M etc..the others are not so important.

I can't present columns, these were pasted from excel (existing descr, fh descr or Y means "same", * means attention).

Code: Select all

:		
:		
1stCommunion:	First communion	
Address:		
Adoption:	Y	
Aged:		
Agency:		
Alias:		
Ancestor File:		
Ancestor:		
Annulment:	Y	
Assessment:		
Associate:		
Attribute:		
Author:		
Baptised:	Baptism	
Bar Mitzvah:		
Bas Mitzvah:	Bat Mitzvah	*
Birth:	Y	
Blessing:	Y	
Burial:	Y	
Caste:	Group/Caste Membership	
Cause:		
Census:	Y	
Changed:		
Child:		
Children:	Child Count	
Christened:	Christening	
Christening:	Christening (adult)	
City:		
Confirmed:	Confirmation	
Country:		
Cremated:	Cremation	
Custom Ident:	Custom ID?	*
Data:		
Date:		
Death:	Y	
Descendant:		
Described:	Physical Description	
Div.Filed:	Divorce Filed	
Divorced:	Divorce	
Educated:	Education	
Email:	EMail?	*
Emigrated:	Emigration	
Engaged:	Engagement	
Event:		
Flags:		
Format:		
Gender:		
Given Name:		
Graduated:	Graduation	
Half Pedigree:		
Husband:		
Id Number:	National ID	
Identified:		
Immigrated:	Immigration	
Latitude:		
LDS Baptised:		
LDS Ch.Sealing:		
LDS Confirmed:		
LDS Endowment:		
LDS Sp.Sealing:		
Line 1:	Address 1?	*
Line 2:	Address 2?	*
Longitude:		
Mapping:		
Marr.Banns:	Marriage Banns	
Marr.Contract:	Marriage Contract	
Marr.Licence:	Marriage Licence	
Marr.Settled:	Marriage Settlement	
Marr.Status:		
Marriage:	Y	
Marriages:	Marriage Count	
Media Object:		
Media Type:		
Name Prefix:		
Name Suffix:		
Name Used:		
Name:		
Nationality:	National or Tribal Origin	
Naturalised:	Naturalisation	
Nickname:		
Note:		
Occupation:	Y	
Ordination:	Y	
Page:		
Parents:		
Pedigree:		
Permanent Ref:		
Phone:		
Place:		
Postcode:		
Probate:	Y	
Property:	Possessions	
Publication:		
Record Id:		
Record Ident:	Record ID?	*
Relation:		
Religion:	Y	
Repository:		
Residence:	Residence	
Restriction:		
Retired:	Retirement	
Role:		
Sentence:		
Short Title:		
Soc.Sec.No:	U.S. Social Security Number	
Source Data:		
Source Type:		
Spouse:		
Standardized:	Standardised?	*
State:		
Status:		
Submitter:		
Surn.Prefix:		
Surname:		
Temple:		
Text:		
Time:		
Title:	Y	
To/From:	Travel	
Type:		
Web Addr:		
Wife:		
Will:	Y	
Witness Name:		
Witness:

[Nick-V]

Using existing descriptions I separated those with 1 tab from those with 2 and did two tests to find errors. The test format was:

"3)" & space & description & ":" & tab/tab & value

All those currently with 1 tab worked fine. However please note 3) LDS Endowment: was just one space away from overflowing.

Of those currently with 2 tabs, I believe the following should only have 1:

3) Agency: a
3) Baptised: a
3) Blessing: a
3) Census: a
3) Changed: a
3) Cremated: a
3) Div.Filed: a
3) Divorced: a
3) Engaged: a
3) Gender: a
3) Mapping: a
3) Probate: a
3) Retired: a
3) Spouse: a

[tatewise]

I too have been experimenting with the new format.

Don't worry about any LDS Ordinance labels such as LDS Endowment: or LDS Ch.Sealing: overflowing, because they can never be suffixed with a Description as they are neither Event nor Attribute and cannot have an ADDRess field nor an Attribute Value.

However, long labels for many other tags may be a problem.

Old Label: -> New Label: . . . comments
1stCommunion: -> 1st Communion: . . . First Communion: will be too long
Author: . . . only needed 1 tab within FH Note?
Baptised: -> Baptism:
Bas Mitzvah: -> Bat Mitzvah:
Caste: -> Group/Caste:
Children: -> Child Count:
Christened: -> Christening:
Christening: -> Christen Adult: . . . but is it too long?
Confirmed: -> Confirmation:
Cremated: -> Cremation:
Custom Ident: -> Custom Id: . . . don't like ID and FH uses Id
Described: -> Description: . . . Physical Description: will be too long
Div.Filed: -> Divorce Filed:
Divorced: -> Divorce:
Educated: -> Education:
Email: . . . not changed as FH uses Email, but could use E-mail
Emigrated: -> Emigration:
Engaged: -> Engagement:
Graduated: -> Graduation:
Id Number: -> National Id:
Immigrated: -> Immigration:
LDS Baptised: -> LDS Baptism:
Line 1: -> 1st Line: . . . FH & Gedcom use First Indexing Line and it always follows Address:
Line 2: -> 2nd Line: . . . FH & Gedcom use Second Indexing Line and it always follows Address:
Marr.Etc: . . . not changed because Marriage will be too long
Marriages: -> Marriage Count:
Naturalised: -> Naturalisation:
Phone: -> Phone No:
Property: -> Possessions: . . . although Gedcom uses both in different places!
Record Ident: -> Automated Id: . . . don't like ID and FH uses Automated Record Id
Retired: -> Retirement:
Standardized: -> Standardised:
Status: . . . only needed 1 tab within FH Note?
Web Addr: -> Web Site: . . . to match FH

[Nick-V]

Mike

Didn't want to confuse things...just noting the FH description but quite happy with your shorter "ed" version...if you confirm your preferred final choices I'll run them thru FTM again with suffixes and tabs and data and let you which require 1 or 2 tabs with the standard font.

[tatewise]

Yes, try those New Label: versions.

I originally chose the shorter ...ed versions over the ...tion versions to cater for a variable spaces indent, but now that has been replaced by almost fixed text, and if the longer versions can be accomodated, then they are more consistent with FH, and usually Gedcom too.

Note that I found Author: and Status: only needed 1 tab when displayed in FH.

[Nick-V]

OK will check those new ones...

In FTM I still find Author and Status require 2 tabs as defined correctly in your table...if you are getting different results to me the issue might be the use of different font in FH versus FTM.

AUTH = { Label="Author:\t\t";
STAT = { Label="Status:\t\t";

[Nick-V]

I put all of those in FTM with one tab:

Code: Select all

3) 1st Communion:	a
3) Author:	a
3) Baptism:	a
3) Bat Mitzvah:	a
3) Group/Caste:	a
3) Child Count:	a
3) Christening:	a
3) Christen Adult:	a
3) Confirmation:	a
3) Cremation:	a
3) Custom Id:	a
3) Description:	a
3) Divorce Filed:	a
3) Divorce:	a
3) Education:	a
3) Email:	a
3) Emigration:	a
3) Engagement:	a
3) Graduation:	a
3) National Id:	a
3) Immigration:	a
3) LDS Baptism:	a
3) 1st Line:	a
3) 2nd Line:	a
3) Marr.Etc:	a
3) Marriage Count:	a
3) Naturalisation:	a
3) Phone No:	a
3) Possessions:	a
3) Automated Id:	a
3) Retirement:	a
3) Standardised:	a
3) Status:	a
3) Web Site:	a

The ones requiring 2 tabs are:
3) Author: a
3) Email: a
3) Status: a

[tatewise]

I suspect the solution for all 6 character labels is to use colon space tab, e.g.
AUTH = { Label="Author: \t";

Applies to:
Agency: \t
Author: \t
Burial: \t
Census: \t
Format: \t
Gender: \t
Spouse: \t
Status: \t
Temple: \t

[Nick-V]

I'm not sure why we should consider spaces if 1 or 2 tabs works but I tested anyway.

All work except "3) Burial: a" which requires 3 spaces.

[tatewise]

The advantage to me of space+tab instead of 2 tabs is the Notes tabulate neatly in FH, which makes reviewing the Plugin export easier for me.

If they also tabulate neatly in FTM, then I've killed 2 tabs with one space+tab.

I suspected the shortness of Burial: would need 2 tabs, and that is OK

[Nick-V]

Understood, thanks.

[tatewise]

V1.7.B has been posted in KB and implements the new 'name tag' style.

It applies this style to ALL records (except Media records) including all synthetic Source records.

I know I said it was not necessary for some synthetic Sources but it turned out to be quite easy and for the sake of consistency seemed worthwhile. So there are a few more 'name tags' to check for HEAD, SUBM & SUBN in the dicNameTag table at about lines 3500 - 3600.

Meanwhile, I will take a look at using 'name tag' style for Media records too, then I suspect it will be a good idea to let the dust settle for a while.

[Nick-V]

Thanks Mike...

OK...the format decision was a good one...everything looks tidy and as clear as can be. The formatting works well on the INDI, FAM and SOUR notes, I can see OBJE notes are without.

I've tested alignment:

1. Christening appears to have a space between the tag and colon - it simply needs removing then works fine
2. LDS Endowment is 1 space from overflow - perhaps a shorter description would be less risky and present better
3. All single and double tab entries (including their spaces) align perfectly

I looked at CONT and CONC handling...it is now improved and more natural...CONCs disappear and the inevitable tab (and lack of hanging tab) for each CONT might be regarded acceptably as a (somewhat old fashioned and large) paragraph indent. It is probably the best presentation we can hope for and quite reasonable.

One lesser matter I've just thought about, if possible it would be even tidier if SOUR notes for ROOT and HEAD were stored in the DO NOT DELETE record reducing from 3 to 1 these preservation records.

I believe you have developed somewhat blindly not using FTM and Ancestry...it's worked well but perhaps you have missed out on seeing the great results of your work and having an opportunity to suggest improvements. If you wish I would be delighted to use your own GEDCOM and images to 1) upload to your Ancestry site if you use it 2) import to FTM then export again so you can see what returning data looks like.

[tatewise]

I have post V1.7.C dated 03 May 2015 in the KB.

1. Christening space removed.
2. As I said before, don't worry about LDS Ordinance labels such as LDS Endowment: or LDS Ch.Sealing: overflowing, because they can never have a Description as they are neither Event nor Attribute so can't have an ADDRess field nor an Attribute Value.
3. Excellent.
4. Yes, I was viewing the tab as a large paragraph indent.
5. HEAD already holds _ROOT since it's as much part of the Header record as Named Lists. The DO NOT ALTER Source now holds the largest Id for original record types. Saving one Source is not worth it, and would be inconsistent with all the other synthetic Sources.
6. V1.7.C now uses Name Tags in OBJE Media records, but only for original full frame records, whereas synthetic part frame records have nothing except perhaps a Note caption.
7. However, I have found it necessary to include Source Data: (SOUR) and Media Object: (OBJE) lines in all records as place-holders for the actual tags and any subsidiary tags.

Thank you for the offer, that may be useful in due course, when it comes to the import Plugin, but I need a rest from this for a while before contemplating that step.

It has been a useful exercise, because the testing has exposed a number of flaws in the original Plugin albeit for some of the more esoteric Gedcom structures, not just for FTM but also several other products, and the Media export options are vastly improved.

[Nick-V]

OK thanks...I'll take a look at the latest version, especially OBJE tags.

I eventually managed to review the thousands of hints generated...very useful (more facts and people and neatly linked proof) although painful at times (the more hints you review the more suddenly arise, and data needs checking using exception reports etc. due to some odd things that happen). As I tidy up the data a little more work arises but the back of it (and mine) is broken.

I'm going to update the KB section about using Ancestry with some tips. I'll then start noting in the KB import section the priority issues I note with the trip back to FH and may prototype these to prove/test a few things...and get my data back again for web presentation and using the flexible features of FH for checking...

...you've worked long and hard on this...I recognise the effort and commitment it takes...thanks.

[tatewise]

Hi Nick. How is your review of v1.7.C going?
If it all goes well I would like to publish the Plugin in the Plugin Store for the benefit of everyone.