I have a census entry for an individual. The Census entry has a local Note attached to it with some additional information about his employer (I don't want to use Associated Person in this case). The Note is linked to a Source Record, but I cannot link the Source Record to a Repository at this level of the hierarchy.
FH should support linking of Sources to Repositories at all levels where the Source is permitted.
ID:3378
* Allow Source to link to Repository at all levels o
-
GladToBeGrey
- Famous
- Posts: 115
- Joined: 26 Oct 2004 09:16
- Family Historian: V7
- Location: Dorset, UK
-
nsw
Allow Source to link to Repository at all levels o
If you've linked to a new source or an existing source you can add a repository in the Records Window by right-clicking on the source name and add a link to a repository.
If you instead used a source note then these don't link to respositories. Actually the GEDCOM documentation seems to suggest these local sources are designed for systems that don't support proper sources. As Family Historian supports sources I don't see a reason to use a source note. I guess FH supports them because it needs to be able to handle files from other systems that have used this structure.
If you instead used a source note then these don't link to respositories. Actually the GEDCOM documentation seems to suggest these local sources are designed for systems that don't support proper sources. As Family Historian supports sources I don't see a reason to use a source note. I guess FH supports them because it needs to be able to handle files from other systems that have used this structure.
-
GladToBeGrey
- Famous
- Posts: 115
- Joined: 26 Oct 2004 09:16
- Family Historian: V7
- Location: Dorset, UK
Allow Source to link to Repository at all levels o
Nick, not sure I understand exactly what you mean by 'source note' - I cannot find any reference to this entity in FH Help? Neither can I find reference to 'source note' in my copy of the 5.5 standard?
The Local Note I described is attached to the Source record itself, rather than to the link to the Source record; both are supported. Is one of these what you mean by 'source note'?
To continue ... in turn, that Local Note has a link to a Source Record, to source the information contained in the Note. I was able to right-click and add the link to the new Source record quite happily. What I was then trying (and would like to be able) to do was right-click on the Source record just created and link the Source to the Repository at that point, but FH doesn't give me the option in the context menu.
Coming back to it this morning, I realise that I have to go into the Sources window, locate the newly-created Source record, and there I can add the link to the Repository. But it all means you have to leave the main context in which you're working, and requires additional unnecessary mouse-clicks etc.
I guess now we'll have to wait for V4's new interface and see if that has improved things.
If not, I'll be back ...
The Local Note I described is attached to the Source record itself, rather than to the link to the Source record; both are supported. Is one of these what you mean by 'source note'?
To continue ... in turn, that Local Note has a link to a Source Record, to source the information contained in the Note. I was able to right-click and add the link to the new Source record quite happily. What I was then trying (and would like to be able) to do was right-click on the Source record just created and link the Source to the Repository at that point, but FH doesn't give me the option in the context menu.
Coming back to it this morning, I realise that I have to go into the Sources window, locate the newly-created Source record, and there I can add the link to the Repository. But it all means you have to leave the main context in which you're working, and requires additional unnecessary mouse-clicks etc.
I guess now we'll have to wait for V4's new interface and see if that has improved things.
If not, I'll be back ...
-
jmurphy
- Megastar
- Posts: 712
- Joined: 05 Jun 2007 23:33
- Family Historian: V6.2
- Location: California, USA
- Contact:
Allow Source to link to Repository at all levels o
I opened one of my databases and looked at an individual in the Records window. I right-clicked on one of the entries for Occupation and after choosing 'Add Source' from the menu, there are three choices:
Add Link to New Source Record
Add Link to Existing Source Record
Add Source Note to this Record
I'm not very clever about making screenshots, but that's one of the sub-menus where the 'Source Note' shows up.
Jan
Add Link to New Source Record
Add Link to Existing Source Record
Add Source Note to this Record
I'm not very clever about making screenshots, but that's one of the sub-menus where the 'Source Note' shows up.
Jan
-
Jane
- Site Admin
- Posts: 8442
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Allow Source to link to Repository at all levels o
You can add a Repository to a source attached to a Note Record and a Local Note on the records window, and as long as I open the Source (eg click the square box so it has an X) I can add a repository.
-
GladToBeGrey
- Famous
- Posts: 115
- Joined: 26 Oct 2004 09:16
- Family Historian: V7
- Location: Dorset, UK
Allow Source to link to Repository at all levels o
You have not appear to have replicated my problem correctly. Your Note is attached to the Individual. Mine, as explained, was a Note attached to a Source attached to a census attached to the Individual.
-
GladToBeGrey
- Famous
- Posts: 115
- Joined: 26 Oct 2004 09:16
- Family Historian: V7
- Location: Dorset, UK
Allow Source to link to Repository at all levels o
Updated screen-shot - the earlier one posted did not have the Source expanded, though it makes no difference ...
-
Jane
- Site Admin
- Posts: 8442
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Allow Source to link to Repository at all levels o
I think you are right clicking in the wrong place, right click on the name of the source as in my example. The 'source' column is to add citation entries, the repository is for the source record.
Allow Source to link to Repository at all levels o
And this is why I hate the UI of FH. [mad] Nowhere does it give any clue that different actions take place depending on where you right click on a menu, except in this little bit in the help...
'To add a new field to a record (or to add a sub-field to a field) using low-level editing, right-click on the record or field name (the text in the left column) to bring up a context menu with 'Add' commands for each of the fields or sub-fields which you can validly add.
.
.
.
Where a record contains links to other records, the name of the linked record is shown in the right column with a little white check box {bmc Sundry - attach btn.bmp} to the left of the record icon. Click on this check box if you want to see details of the linked record.'
Also the menu changes depending on whether the check box is ticked or not, which is also confusing to users.
'To add a new field to a record (or to add a sub-field to a field) using low-level editing, right-click on the record or field name (the text in the left column) to bring up a context menu with 'Add' commands for each of the fields or sub-fields which you can validly add.
.
.
.
Where a record contains links to other records, the name of the linked record is shown in the right column with a little white check box {bmc Sundry - attach btn.bmp} to the left of the record icon. Click on this check box if you want to see details of the linked record.'
Also the menu changes depending on whether the check box is ticked or not, which is also confusing to users.
-
jmurphy
- Megastar
- Posts: 712
- Joined: 05 Jun 2007 23:33
- Family Historian: V6.2
- Location: California, USA
- Contact:
Allow Source to link to Repository at all levels o
Jon, I'm afraid I'm not following you when you say:
'different actions take place depending on where you right click on a menu'
Did you mean right-click on a line-item of a individual's record?
And having seen that one can check (or tick, as you say) or uncheck a check-box next to the source, I expect the actions available to be different in the two different states, otherwise why are there two states, checked vs. unchecked?
I agree with many of the comments you have made in the past about the non-standardization of the UI, but in this case, I'm not sure I understand how you would want the program to act instead.
Forgive my obtuseness, but I am a humble end-user. I appreciate good design when I have it, but for the most part, unless the 'most annoying feature' of a program is so annoying that I cannot use the program, I simply learn what I need to learn to make things work and then get on with it.
In my case, FH's Auto Source Citation is so superior to all the other programs I tested, I'm willing to forgive some of FH's imperfections.
Jan
'different actions take place depending on where you right click on a menu'
Did you mean right-click on a line-item of a individual's record?
And having seen that one can check (or tick, as you say) or uncheck a check-box next to the source, I expect the actions available to be different in the two different states, otherwise why are there two states, checked vs. unchecked?
I agree with many of the comments you have made in the past about the non-standardization of the UI, but in this case, I'm not sure I understand how you would want the program to act instead.
Forgive my obtuseness, but I am a humble end-user. I appreciate good design when I have it, but for the most part, unless the 'most annoying feature' of a program is so annoying that I cannot use the program, I simply learn what I need to learn to make things work and then get on with it.
In my case, FH's Auto Source Citation is so superior to all the other programs I tested, I'm willing to forgive some of FH's imperfections.
Jan
Allow Source to link to Repository at all levels o
'Forgive my obtuseness, but I am a humble end-user. I appreciate good design when I have it, but for the most part, unless the 'most annoying feature' of a program is so annoying that I cannot use the program, I simply learn what I need to learn to make things work and then get on with it. '
Jan, I agree with you that unless the annoying thing(s) is a deal breaker, I would put up with it. But it has meant a long learning process when what I really want to do is concentrate on genealogy not on learning to use the program. After a time you get used to the way it works, even though it still irritates. There are features in FH that mean I still use it rather than switch to other packages. I like FH's diagrams, it's flags and named lists, it's record level editing, and it's lack of rigidity in allowing many different ways of sourcing.
'Did you mean right-click on a line-item of a individual's record?'
Yes to a certain extent.
In a bit more depth.
When you right click anywhere on a line you should expect the menu that appears to be consistent. I don't quite mean that the same menu appears where ever you click. What I mean is that if you right click on the left column, you always get the same type of menu no matter which field you click on. In this case it should allow adding sub-fields. If you right click on the right hand column (in the expanded part of the record section) you should always get the same type of menu, but it can be different from the left hand column,but still consistent in that the menu is the same for all right column entries, namely the edit menu.
Examples
1) On the record line itself, you can r-click on the name and the context menu allows record level options. You can also r-click on the data in the other columns, but the menu that appears is the window options one - so all this about r-clicking on a blank area of the window isn't quite true. A l-click should work along the whole line, not just the first column, similarly for a r-click. By not allowing a click anywhere on the line it makes it awkward for users to add fields to records with short names since they only have a small amount of screen space to click on.
2) If the record is expanded, r-clicking on 'Name' (or other simple fields without a check-box) allows sub-fields to be added. R-clicking on the actual name brings up the window options menu whilst l-clicking allows editing of the name. However if you l-click, then r-click you get the edit menu (cut/copy/paste). R-clicking on the name the first time should bring up the edit menu. Consistency means that a r-click on the name always brings up the edit menu. For other fields such as events and attributes where the data is made up from multiple sub-fields, a r-click on the appropriate part should allow editing of that part only. So date and place will be two parts that appear for events and attributes like they do at the moment. Other sub-fields would require the field to be expanded
3) Link type fields should act the same as other fields in that the menu you get when you r-click on the field name allows adding of sub-fields. However since they are differentiated by the check-box which is seemingly mainly used for expanded/collapsing the linked record the menu that appears when r-clicking on the name of the record '...of X and Y' or '...with Z' can not have the cut/copy/paste menu, but it can still have the editing type options such as 'Copy as text' and 'Properties'.
Basically what I'm saying is that currently if you r-click on a field name in the left column you get all the add... field options, except that on field name 'Parents family' and others you don't unless you expand the linked record and then r-click on the right column. Yes it's a link so different to a simple field but to the user its still a field name and unless they know Gedcom they won't immediately understand the difference. Granted, after a time, you'll get used to it as you do with any other software package, but the point is to make it easy to use the software quickly. If it takes users a long time to get to grips in using a piece of software, unless they have put a lot of money/effort into getting the software, they'll give up.
A slight diversion. Events and attributes aren't consistent with Name and Sex etc. They are combined into one sentence, e.g. 'Born 11 December 1899 in London'. I believe to be consistent that the date and place should be in the right hand side like actual names with the event type on the left. E.g. [pre]'Birth' '11 December 1899' 'London'[/pre], i.e. two parts, date & place.
Another diversion. L-clicking a note field does not highlight the whole field. L-clicking a single line text field DOES highlight the whole field. A user would need to know the Gedcom spec pretty well to work out why one field is highlighted and another isn't. To any other user it looks random as to what happens and that is bad news in a UI. What should happen is that the cursor should be placed at the start of any field of text, the text should never be highlighted. Highlighting on selection makes it easy for users to lose data since a single missed key stroke will wipe out the field and unless you are quick and do a Ctrl-Z its lost. V4 with it's undo/redo will stop the data loss, but I would be surprised if most users are going to totally wipe a field and re-enter it if it's already got data in it - more than likely they will only be editing it so they have an extra key to press to clear the selection before they edit.
And a final diversion, the bits where I said that the user needs to know Gedcom highlights that case that FH is confused about it's target market. Advanced techy users can understand the Gedcom stuff, whilst ordinary naive users don't care a single iota about Gedcom except that it can store their data and don't want to be exposed to it's techy innards.
Sorry about nicking your post GtbG.
Jan, I agree with you that unless the annoying thing(s) is a deal breaker, I would put up with it. But it has meant a long learning process when what I really want to do is concentrate on genealogy not on learning to use the program. After a time you get used to the way it works, even though it still irritates. There are features in FH that mean I still use it rather than switch to other packages. I like FH's diagrams, it's flags and named lists, it's record level editing, and it's lack of rigidity in allowing many different ways of sourcing.
'Did you mean right-click on a line-item of a individual's record?'
Yes to a certain extent.
In a bit more depth.
When you right click anywhere on a line you should expect the menu that appears to be consistent. I don't quite mean that the same menu appears where ever you click. What I mean is that if you right click on the left column, you always get the same type of menu no matter which field you click on. In this case it should allow adding sub-fields. If you right click on the right hand column (in the expanded part of the record section) you should always get the same type of menu, but it can be different from the left hand column,but still consistent in that the menu is the same for all right column entries, namely the edit menu.Examples
1) On the record line itself, you can r-click on the name and the context menu allows record level options. You can also r-click on the data in the other columns, but the menu that appears is the window options one - so all this about r-clicking on a blank area of the window isn't quite true. A l-click should work along the whole line, not just the first column, similarly for a r-click. By not allowing a click anywhere on the line it makes it awkward for users to add fields to records with short names since they only have a small amount of screen space to click on.
2) If the record is expanded, r-clicking on 'Name' (or other simple fields without a check-box) allows sub-fields to be added. R-clicking on the actual name brings up the window options menu whilst l-clicking allows editing of the name. However if you l-click, then r-click you get the edit menu (cut/copy/paste). R-clicking on the name the first time should bring up the edit menu. Consistency means that a r-click on the name always brings up the edit menu. For other fields such as events and attributes where the data is made up from multiple sub-fields, a r-click on the appropriate part should allow editing of that part only. So date and place will be two parts that appear for events and attributes like they do at the moment. Other sub-fields would require the field to be expanded
3) Link type fields should act the same as other fields in that the menu you get when you r-click on the field name allows adding of sub-fields. However since they are differentiated by the check-box which is seemingly mainly used for expanded/collapsing the linked record the menu that appears when r-clicking on the name of the record '...of X and Y' or '...with Z' can not have the cut/copy/paste menu, but it can still have the editing type options such as 'Copy as text' and 'Properties'.
Basically what I'm saying is that currently if you r-click on a field name in the left column you get all the add... field options, except that on field name 'Parents family' and others you don't unless you expand the linked record and then r-click on the right column. Yes it's a link so different to a simple field but to the user its still a field name and unless they know Gedcom they won't immediately understand the difference. Granted, after a time, you'll get used to it as you do with any other software package, but the point is to make it easy to use the software quickly. If it takes users a long time to get to grips in using a piece of software, unless they have put a lot of money/effort into getting the software, they'll give up.
A slight diversion. Events and attributes aren't consistent with Name and Sex etc. They are combined into one sentence, e.g. 'Born 11 December 1899 in London'. I believe to be consistent that the date and place should be in the right hand side like actual names with the event type on the left. E.g. [pre]'Birth' '11 December 1899' 'London'[/pre], i.e. two parts, date & place.
Another diversion. L-clicking a note field does not highlight the whole field. L-clicking a single line text field DOES highlight the whole field. A user would need to know the Gedcom spec pretty well to work out why one field is highlighted and another isn't. To any other user it looks random as to what happens and that is bad news in a UI. What should happen is that the cursor should be placed at the start of any field of text, the text should never be highlighted. Highlighting on selection makes it easy for users to lose data since a single missed key stroke will wipe out the field and unless you are quick and do a Ctrl-Z its lost. V4 with it's undo/redo will stop the data loss, but I would be surprised if most users are going to totally wipe a field and re-enter it if it's already got data in it - more than likely they will only be editing it so they have an extra key to press to clear the selection before they edit.
And a final diversion, the bits where I said that the user needs to know Gedcom highlights that case that FH is confused about it's target market. Advanced techy users can understand the Gedcom stuff, whilst ordinary naive users don't care a single iota about Gedcom except that it can store their data and don't want to be exposed to it's techy innards.
Sorry about nicking your post GtbG.
-
GladToBeGrey
- Famous
- Posts: 115
- Joined: 26 Oct 2004 09:16
- Family Historian: V7
- Location: Dorset, UK
Allow Source to link to Repository at all levels o
Jon. No apology needed.
Jane. Yes, that works.
Jane. Yes, that works.
-
jmurphy
- Megastar
- Posts: 712
- Joined: 05 Jun 2007 23:33
- Family Historian: V6.2
- Location: California, USA
- Contact:
Allow Source to link to Repository at all levels o
Jon -- thanks very much for your thorough and thoughtful reply. I was called in to work unexpectedly this weekend, and have not had time to give your remarks the attention they deserve, but look forward to doing so soon.
Cheers,
Jan
Cheers,
Jan