I think this wish is a good idea, but even if the RM team agreed I certainly wouldn't want to see it before RM9 at the earliest. RM8 really needs to get out the door before any other good ideas are brought forth.
I wish for a new main view called the Event View. The look and feel would be modeled on the existing People View. The data being displayed would mostly consist of the contents of RM's EventTable which holds all the facts for all users. Hence, a complete and unfiltered Event View would contain many more rows than the existing People View. However, the Event View would not be presented quite like a simple SQLite query of the EventTable. Rather, the data would be presented in a bit more user friendly fashion than an SQLite query, behind the scenes joining with any other tables as required. For example, "role facts" should be included which requires joining with the RoleTable and the WitnessTable.
Double clicking any row in Event View would place you in the Edit Person screen for the person owning the fact and editing the selected fact. For family facts such as marriage, there are two possible individuals to select. I would hate always to be asked (too clicky) but I would also hate also not to be able get into either spouse. Therefore, each family fact should appear twice in the Event View, once for each spouse.
The columns available to Event View should be as follows. It should be possible to enable or disable the display of each column. It should be possible to sort on any or all columns - not just one column like People View. Not all the columns would be displayed by default, again using People View as a model.
- Name of event - birth, marriage, census, etc.
- Type of event - individual or family
- Person ID of owning person (like in People View)
- Reference Number of owning person
- FamilySearch ID of owning person
- Person Name of owning person (like in People View)
- Sort date
- Number of media files for the event
- Number of citations for the event
- Number of citations for the event that don't have media files
- Primary flag
- Private flag
- Proof flag
- Status flag
- Actual fact vs. role fact indicator
- For actual facts, shared or unshared status
- Date last edited
- Sentence template type (default or customized)
- Sentence template (raw, unfilled in)
- Sentence (sentence template after being filled in).
- Description (first 100 characters)
- Note (first 100 characters)
- GEDCOM export flag (really, a Fact Type flag, but useful here anyway)
- Publish online/create HTML flag (really, a Fact Type flag, but useful here anyway)
- Group sheets flag (really, a Fact Type flag, but useful here anyway)
- Narrative reports flag (really, a Fact Type flag, but useful here anyway)
- Individual summary flag (really, a Fact Type flag, but useful here anyway)
- Lists flag (really, a Fact Type flag, but useful here anyway)
In addition to being able to hide or show each column and to sort on multiple columns, the Event View should have powerful filtering capabilities appropriate to each column and that are specified separately for each column. For example, the date fields might be "between 1900 and 1910", place fields might be "contains Tennessee OR contains Texas", etc. Also, it should be possible to filter by group. Events/facts in RM do not have groups, but the owning people do, so the group filter should be on the owning people. Finally, RM should do a good job of remembering the sorting and filtering capability for the Event View.
It is tempting to ask to be able to type directly into the cells of this proposed Event View without double clicking to get into Edit Person. It could sure be nice and it could sure speed up a number of data entry issues. But I'm not sure how safe it would be.
In submitting this wish, I have also been thinking about RM's NameTable. This is the table in RM that holds the names of each individual and which also holds all alternate names. The names appear in RM's Edit Person screen almost as if they were events or facts. But I don't know if it would be a good idea to present the name data in the proposed Event View. There are enough differences in RM's NameTable and RM's EventTable to make a common view containing both to be somewhat awkward. Therefore, I think it would be better to have a Name View for the NameTable, following the same model I have just described with an Event View for the EventTable. And I'm especially assuming that RM's Name processing in RM8 will be enriched so that RM will have a Primary Name that will have all the same capabilities as does RM's current Alternate Names.