Tags, events, sources, names and grouping
1) I have notice that when attaching a source that creates a new entry in Events, a tag to that source is not propagated into the tags section. As a result every event created from a new source requires a manual intervention to create the source tag. The tag reference should be automatically created as part of attach process in the same manner it is under Vitals.
2) When manually creating an event from unused content in an existing attached source, the option to tag to a source is not available. This requires the event to be created first, then a second manual action to establish the tag. An example of this situation is often seen in census sources where the occupation must be manually created and then tagged to the census. The side pane used to create and display a source tag should be part of the new event creation window similar to the window offered when manually adding a christening.
3) There are occasions when sources have been attached but the pertinent content was not transferred. For example, failing to transfer residence information on a census. In these cases using Review Source then opening Details displays all items as if they were complete when in reality the residence was not transferred. Transferable items that have no corresponding match should not display as completed. This should be indicated in the source listing similar to the incomplete attachment indication. Ideally there should be an method that allows their addition without going through the process of detaching the source first.
4) Names in christening, baptisms, marriages, and census sources often represent a single family unit. It is not uncommon to find family members on these sources split across unrelated trees. When attachments are not connected to immediate family members there need to be a warning similar to that used for incomplete attachments.
5) It is my belief that Alternate Name items should only be used when the Vitals Name is not the same. For example birth name different due to an adoption. Allowing alternate names that match the full (or a subset) Vitals Name adds needless clutter and wastes screen space. These duplicate names likely impacts real time performance and storage requirements. Names that match with the Vitals name should be purged and any attempt to add a duplication should be a null process.
6) Vital Name and alternate name should be grouped together. Add a new check box within the name list to indicate a person's preferred given name. Add a checkbox on the surname to indicate when a wife's maiden name is the same as her married name.
7) Birth, Christening, Baptisms and Religious affiliations should be grouped together.
Thank you for your consideration on these suggestions
Comments
-
I agree with several of your points, but strongly disagree with others. Part of the problem on the latter, I think, is that you are making assumptions that are contradictory to my experience.
For your first point, Source Linker's inability to tag Other Information used to be a historical artifact: the tool predated non-Vitals tagging. I haven't a clue why the still-in-process software update hasn't added this important function. I agree that it is a serious flaw: it means that properly adding, say, a census to even a small family takes too many steps to count, and I'm left with the nagging feeling that I very likely missed a detail somewhere.
I likewise do not understand the reasoning behind the way adding Other Information is disconnected from tagging it. Surely the "add" popup can simply be a blank version of the "edit" one?
I vehemently and strongly disagree with your third point. I have no intention of ever transferring that redundant baptism (because, despite what Source Linker misleadingly shows me, it's already there, where it belongs, under Christening). The same thing applies to every single one of those birth/marriage/death registrations that SL insists on offering, instead of letting me edit the vital or add the relationship event. Please don't allow the tool to nag me about something that's already borderline infuriating.
I don't understand your fourth point. It's one of the positives of Source Linker that it can attach a member of an index grouping even if it's not an immediate family member -- or heck, even if it's not a family member, period -- and I don't know what you want it to alert me to about such connections.
I believe that your fifth point is already in place. I just tested this in Beta: adding an alternate name that's identical to an existing one is a "null action" -- you click Save and the popup goes away, but nothing changes on the profile. Nor can you save an edit that creates such an equivalence: a black message pops in from the top right, saying "! Save failed. This data already exists."
Oh, wait, I see what you mean: the comparison between names only applies to the Other Information section. I can freely create an Alternate Name that's identical to the name in Vitals. But that's hardly "clutter": it's a maximum of exactly one entry on the list, and I can understand why some people use it -- you can categorize Alternate Names ("birth name", "married name", etc.), which you cannot do in the Vitals section. (I suppose this is because the assumption is that what's there is a birth name. Except when it isn't.)
Still on point 5: I think if you think through your parenthetical "or a subset", you'll see that it's unworkable. If the Vitals name is "John Michael Smith", but he also went by "Michael Smith", we need to be able to enter that as an alternate; that's what that section is for.
People have made the suggestion to stop separating the Vitals name from the other names, and to allow a per-user preferred name. I don't disagree that these changes could help resolve some contention, but I don't feel strongly about it. Other user-interface and workflow problems (such as your points one and two) are a lot higher up on my list.
The other part of your point 6, about checkboxes and married names, shows that you are making assumptions about naming that are unwarranted in my experience. There doesn't (or shouldn't) need to be a checkbox to indicate that spouses happened to have matching family names; that should be immediately apparent from a simple glance at the Family Members section. The fact that English speakers re-assign a woman's family if she gets married doesn't mean that the rest of the world does any such thing. The solution to the utter chaos created by the English system is not to apply its problems universally, but to stick to pre-marriage names whenever possible, with just a well-labeled entry under Alternate Names for the post-marriage name.
I'm not sure what "Birth" is doing in the group in your last point; there's nothing religious about being born.
For christening and baptism, I would go further: one or the other of these perfect synonyms should simply be eliminated from the site. Pick a word and stick with it. (Unfortunately, the LDS religion is too Anglo-centric to admit this utter and complete lack of distinction.)
For the last part of the last point, I'm not sure how FS could group religious affiliation with anything: where would it go? How would the data need to be arranged?
And finally, a suggestion: make your first point in the New Source Linker Feedback group. Perhaps we can convince the engineers to remedy this gap in their tool.
2 -
With the changes to this Suggest An Idea section in the next couple of days, I've gotten the impression FamilySearch really doesn't want us posting here since they are closing discussions here as quickly as possible. I suspect they can't complete the update if there are any open topics. But since they have not said that straight out and since this is still open, I'm taking the chance to slip in a couple of comments.
1) This has been requested a lot. What we've been told, is that the original tagging routine used for Vital data cannot tag a date field that does not exist. When they expanded tagging to the Other Information section, which took several years to accomplish, they couldn't do away with that limitation which led to the current situation that we have to create a data field under Other Information then go back and tag it. We can only hope they are still working on this feature and in the future find a way to allow simultaneous creation and tagging.
2) Same situation.
3) Please, no. Many sources contain information that is redundant, repetitive, or trivial. I'm spending a lot of time cleaning up the detail page because too many people pull everything possible from the left side of the source linker to the right. One example of this is when there are two christening sources that someone attaches and so two custom events for baptisms are created even though the information is already correctly recorded under Christening. So I come to the page and have to delete the two events under Other Information. Even worse is when they pull over the mother's residence at birth of a child when there are three sources for each of ten children. That gives 30 residence events for someone who was living at the same place the entire time. I don't want to have to go and "Dismiss" all those source displayed as "information not transferred" because I do not want that information transferred over after I finish consolidating those 30 residences into one.
4) This is just a matter of finding those extended family members in Family Tree and attaching them. The current warning about the source not being fully attached is sufficient.
5) Sounds reasonable to not allow the addition of an identical copy of a current alternate name.
6) I would also like to see all names grouped together.
7) Things are fine the way they are. Christening is an event that occurs shortly after birth and is associated with the person being named. It is appropriately in Vitals as a substitute or supporting information for Birth. Baptisms should stay in Other Information as a person can be baptized multiple times in life. The religious affiliation should just go as a descriptor for the Other Information Baptism event.
2