Sources in order by date automatically-- fix
LegacyUser
✭✭✭✭
Janet V said: Could you automatically make sources appear in order according to their dates?
(But manually moving them around now is much easier then it was years ago.....thanks)
(But manually moving them around now is much easier then it was years ago.....thanks)
Tagged:
0
Comments
-
-
gasmodels said: Sometimes the sources do not have a date associated. If you will click on the source title and then edit you can add a date to them and then they will be in the correct chronological order.0
-
David Robertson said: A chronological order of sources would be a great improvement.0
-
Jeff Wiseman said: David, the feature is already there. See my reply above.0
-
David Robertson said: Thank you for educating me about sorting sources. I have tried it out and find it very easy.0
-
Jeff Wiseman said: Yes, it's NOT very obvious, is it!
Just a head's up on this though. For many source lists that are are relatively short (say only 20 or 30 entries) this can work very well for people. But when you get up to 60, 70, and more, some visual searchs that you are attempting will likely become a bit more difficult with you having to jump from page to page. At that point (i.e., once you start to experience it), you may want to explore grouping your sources categorically using the custom sort.
One other issue is that it is sometimes hard to put a meaningful date on a source. For example, the FS software will take delayed birth records from probate and assign them the date of birth. But the delayed birth record was actually created 20-30 years LATER than the birth. Also, when a history book contains multiple events, which event do you use? One of the event dates, or maybe the Publishing date of the book itself? When you start wrestling with these things, you might start to see the advantage of categorical groupings of sources.
Unfortunately, everybody has their own idea of how to group them until someone else shows them a better way. And the sort order is open to anybody's adjustments whereas the chronological tends always to be basically the same (until people start modifying the "Event Date" assigned to each source). So the chronological sort will tend to be more stable.
I presented a few ideas and examples on this in the following topic if you are interested:
https://getsatisfaction.com/familysea...0 -
Paul said: Jeff makes some good points. I, for one, do not order the sources sections chronologically. Take a fairly common situation of an individual having lots of children, whose christenings have been indexed multiple times. I do not understand how anyone would want to place the primary individual's death way down the list (possibly on a second page), giving precedence to these other events - important as children's births / christenings are.
I see much more sense in putting vitals (CMB / BMD) sources directly relating to the individual at the top, then I put census sources, others of "lesser" importance (directory entries, etc.) and finally records where an individual in not the primary person mentioned (e.g. appears in a record as father of the child, bride, etc.).
I have no objection at all to other users arranging things chronologically, or by other methods, which is why the current situation (choice of custom / chronological) seems just fine to me.0 -
Tom Huber said: If there is one criticism that I have with the current sort options (chronological or custom) it is that once I set it, it applies to every person I view. When I set it to the opposite setting, that then applies to every person I view.
It would be nice if the system could set the option by the person being viewed, rather than what I wanted to see in one set of sources.
Even better is if the system would remember the setting by user and by a person's sources. That would likely require a setting tied to the user and person and be somewhat complex to set up from a programmers point of view. Yes, it could be done, but if it is on the priority list, I would not hold my breath for it to reach the top of the list and be implemented.0 -
Jeff Wiseman said:
I do not understand how anyone would want to place the primary individual's death way down the list (possibly on a second page)
Possibly on a second page? We're talking about 4th, 5th, or even 6th page typically (especially with all the clutter and fluff that's been added to the list).
Normally when you are searching through a source list, it is either for a place to put a new source, or you are looking to verify information. Either sort type works for the first case, but in the second case, you technically don't have a date to start with and are looking for a particular type of source. For example, many times to confirm parentage or burial location, you want to see the death certificate (if it exists in the list). Unfortunately it will be scrambled in with all the children marriage and death records in the list.
Or if you want to check out to confirm the true relationship type between a person and one of his children (i.e., biological, adopted, etc.), you want to see all of the sources showing that person related to that child gathered together and not scrambled in with the birth, death, and marriage records for all of his ten children along with the deaths of himself and his wife scrambled in.
At least when you are playing "Where's Waldo?", everything is on one page. When searching source lists, I'm frequently looking at half a dozen pages, most containing empty space, fillers, or information that have nothing to do with why I am searching the list in the first place (no thanks to the additional 2 to 4 lines of wasted space do to the last set of "improvements" made to the source list)
If you were to list out all of the specific Use Cases where a person needs to actually search a source list, nearly ALL of them would require a primary key that is NOT a known date.
Unfortunately, automatic categorical sorting of sources is not provided by FS. However, chronological sorting IS, so that is it's main benefit at the moment.0 -
Jeff Wiseman said: Yes, I suspect that since the sort currently can be changed instantly with a single click, I doubt that anything more elaborate will be done on this point.
Although, in my opinion, the ability to support an automatic type category sorting mechanism would be far more useful than any of the additional account specific features that you have mentioned. However, since it would have to be far more sophisticated in its design, it is even LESS likely to ever show up.0 -
Paul said: I am surprised that since the ability to sort chronologically has been added, the requests for FamilySearch to introduce "dividers" to separate different types of sources has almost dried-up. I even read one comment that this was now no longer necessary, and the user even suggested he was now removing his custom-made dividers / separators from his sources sections. I couldn't work out his reasoning!0
-
Jeff Wiseman said: One possibility is that now with the source event date added, all of those dividers drop to the bottom of the list in chronological sort. Since they are all bunched together, the fact that they don't look like sources (because they are NOT), people will delete them from the list since they are meaningless in a chronological sort.
Another possibility is that since a lot of people like the simplicity of the chronological order and its automatic nature, the custom order for each list becomes more stable (i.e., fewer people trying to sort them into date order in conflict with people sorting them categorically). Since categorical ordering is easy to sort through without the dividers when others aren't constantly changing them, the dividers (again which are only a hack posing as sources) aren't as necessary.
There is a naturally "ideal" structure for categorical grouping based on the normal Use Cases requiring searching source lists. As more and more people get experience with this and handling long lists, they are discovering that they are custom sorting things in the same fashion.
There is structure to all things in the Universe. Form follows function. The longer people spend dealing with source lists of any size, the more their preferred structure of those lists will look the same.
I suspect that people who disagree with that common structure are people who either have not had to fight with long lists for any length of time, or never use the source list for more than one or two Use Cases. It they were required to deal with a lot of long source lists and were required to use the "naturally structured" solution to this sorting issue, they would very quickly see the advantages.0 -
Marilyn Gladys Breinholt Thomsen said: Thanks for letting us know this resource exist. It has been very helpful to removing sources attached to the wrong person.
Adding a date to a document is an interesting source. For example my grandmother had a source Overland Trails that was about which company she traveled with, but the information was from her obituary. Which date, the 1862 for the travel overland, the obituary date of 1899? I chose the 1899 date until I have added the obituary as a separate source and the company travel list as her overland travel.
Another date rule I have created for myself is that putting the date a record was created sorts sources into the genealogical level of credibility. For example parents mentioned in death certificates appear after the parent's death. Son's of Utah Pioneer Biographies I sort according to the date of publication, so that the original documents appear at the top. Especially useful for mothers mentioned in a biographical sketch. Putting a more complete title of a source also helps recognize that a Utah Burial record may not pertain to the death of the person, but to their child's death.0 -
Tom Huber said: Some good ideas there. Thank you for sharing them.0
-
Jeff Wiseman said:
recognize that a Utah Burial record may not pertain to the death of the person, but to their child's death
This is just another example of when categorical sorting works better. In chronological sorting, the "Source Event Date" (which is what FS refers to as the sorting key) would be the date of the child's BURIAL (not the death although that is the date that FS automatically puts in the Source Event Date). This puts the source down into the mish-mash of all the siblings birth, marriage, and death records. This can also include the parents death records. This part of the source list can go on for pages and pages.
In categorically sorted records the source is put with the main vital sources for the child, but in the parent's record, it doesn't apply to any of the parent's main vitals. Since the source is only evidence of the RELATIONSHIP with the child, it would be put in the collection of child relationship sources.
This can be seen in the discussion I referred to above.
https://getsatisfaction.com/familysea...
However, since chronological sorting is automatic supported by FS and categorical is NOT, the chronological is quite a bit easier for many folks to use for source lists that aren't real long.0 -
Adrian Bruce said: "putting the date a record was created sorts sources into the genealogical level of credibility" - yes, that is actually a rather good point.0
-
Jeff Wiseman said: Adrian,
That really IS an interesting observation. But what do you do with a Citation to an Index file that was created 60-70 years after the indexed source was? It keys on the actual event of interest. So the fact that the index file on a 1900 census was created in 2005 and its Citation was created in 2016 doesn't change the fact that they are all talking about the 1900 event. The fact that the latter sources were actually created over a century later is significant from a Genealogical standpoint, but is not visible if everything in the source chain is marked with the same Event Date. So without the creation date of all the sources involved, It's hard to evaluate it's Genealogical creditability
Also, FS has named this sorting key the "Event date" of the source. Is that the event of the source's creation, or the key event being referenced? And what about sources that provide information on multiple events? Which event date do you use for the source that may have been created decades after those events?
FS created this source "Event Date" solely to use as a key for chronological sorting--mainly because automatically extracting the information from the source is problematic and can't be made precise in all situations. For example, Find a Grave indexes should be keyed on the burial date. But the burial date isn't even in the source to be indexed (which is why I suspect that FS fudges all the burial dates in the index data). You have to go to a totally different source (such as a death certificate) to find out when the actual burial event took place, and then take THAT back to the Find a Grave citation and use it as the Citation's "Event Date".
There is a lot ambiguity (based on over simplified assumptions) built into the sort key for chronological sorting such that some values are neither right or wrong. I'm really uncomfortable with that, but the automatic mechanism with all its warts is quite acceptable to many folks here so we definitely need to keep it :-)0
This discussion has been closed.