Jerry Bryan

I wish for RM's restore function to be able to restore to the same folder with a different database name - a nondestructive restore to the same folder. The current design requires a restore to a different folder if the restore is to be nondestructive. Restoring to a different folder can be a very error prone process. And even if you manage to restore successfully to a different folder, having two databases by the same name in different folders can be very confusing and error prone - causing lost data.

Jerry

When Searching, Marking, or Unmarking in RM, you can specify Source (family), Source (general), or Any fact source. You can search or mark or unmark on all three types of sources at the same time by using the Boolean OR connector. However, if you do so, it becomes awkward or impossible (I'm not sure which) to add additional search/mark/unmark criteria with a Boolean AND connector. Therefore, I wish for a fourth source criterion for search/mark/unmark called "Any source" which would encompass the other three existing source criteria. The existing three source criteria would remain available for use. The new "Any source" criterion could then be used with other criteria using the Boolean AND or Boolean OR connector. (only after RM8 is out the door).

Jerry

I really wish for lots more data elements to be able to be displayed as columns in People View, but for today I will focus only on color coding. I've been doing a project using color coding where it would have been extremely helpful if color coding could be a column in People View. In particular, I would like to have been able to click at the top of the column and sort by color. This should actually be a fairly simple addition to RM because color coding is a single column in RM's PeopleTable, and there is exactly one row in the PeopleTable for each individual in your database. Alternate Names and that sort of thing do not become involved.

As far as what the column should look like, perhaps each cell could just contain a large dot (or small ball) of the appropriate color. Or perhaps each cell could contain text with the name of the color and with the text being rendered in the appropriate color. The only exception is that I think cells for people with no color coding should be left blank rather than being black.

As far as sort order for the colors, I don't care except that the sort order should enable people with no color coding to sort to the top of the list or to the bottom of the list. If the colors were sorted according to the numeric coding that RM uses, the people with no color coding would sort according to my proposed criteria. If you are curious about what this sort order would mean, it would mean the same order that the colors are listed in the drop down list of colors when you are color coding.

As always with new wishes such as this, I would not wish for something like this to appear in version 8.0. Including it in 8.1 or 8.2 or 8.x or even 9.x would be fine. I would just hope that it might appear some day. As I said, this one should be really easy to implement.

Jerry

I have a pretty good handle on how FamilySearch Family Tree wants place names entered, but I'm not as sure how FamilySearch Family Tree wants the names of people entered. So far, I haven't really found a good source that describes it adequately.

For example, my paternal line great grandfather was William Harley Bryan and he was known as Harley. I list his name in RM as William Harley (Harley) Bryan where the given name field is "William Harley (Harley)" without the quotes. My experience is that RM's nickname field often does not transfer very well to other software. And in addition to that, I often tend to think of so-called nicknames as "known as" names instead of true nicknames such as "Butch" or "Red" or "Tootsie" (well, those can be actual names sometimes - I had an uncle whose real name was Bobby and he had a brother whose real name was Billy). Therefore, I include "known as" names in parentheses as a part of the given name field in RM. I think it's really important to indicate the name by which a person was really known if that information is available. Harley's name really was Harley and it wasn't a nickname. He just went by his middle name, and I don't want that information about his name to be lost in the mists of time by nickname fields being lost. I'm a middle name person myself and I have lots and lots of middle name people in my database. We middle name people really want other people to know the name by which we are called and to use that name when addressing us. And I for, for one, want this data recorded and preserved in genealogical records. My convention of putting a person's "known as" name in parentheses seems to work pretty well for reports and I like it much better than quotes.

In any case, I just noticed that somebody changed my great grandfather's name in FS/FT to William Harley Bryan without the (Harley) with a note that the change was to correct a punctuation error. From my point of view, it's not a punctuation error and it's important information, so I just now changed it back. But what would be the politically correct way in FS/FT to indicate that he was known as Harley? I really want the information to be pretty visible and not buried deeply in some note somewhere. At the same time, I discovered that Harley's brother Mitt Bryan was listed as Charles Milton Bryan in FS/FT so I changed his name to Charles Milton (Mitt) Bryan, and Harley's sister Vestie was listed as Lena Bryan in FS/FT so I changed her name to Lena Vesta (Vestie) Bryan. That's the way I already had them listed in my RM database, and not having Aunt Vestie's middle name listed in FS/FT at all was a pretty egregious error. It seems unlikely that my changes in FS/FT are going to survive if they are all going to be viewed as punctuation errors. So how do I enter people's names into FS/FT as they were really known without my data being viewed as a punctuation error?

Jerry

In the shared fact dialog to add a role to one person, you are given an opportunity to choose a role from a list of the available roles. When you add a role to multiple people, you are not given an opportunity to choose a role from a list of the available roles. RM simply chooses the first role in the list for you.

Not being able to choose a role from the list of available roles when adding multiple people seems like a bug that needs to be fixed. It does not seem like adding the ability to choose a role from the list of available roles when adding multiple people should really be viewed as a requested feature enhancement. But I would rather see this addressed in RM8 rather than RM7.

RM in general is very weak in supporting any kind of bulk data entry operations. By design, it doesn't support bulk delete of people. Two of the places it does support bulk data entry to a limited extent are MultiCite and adding a role to multiple people. I would have to think about how MultiCite could be enhanced, but it's easy to see several useful ways adding a role to multiple people could be enhanced. Such enhancements could include fixing the problem of not being able to pick a role, adding the ability to share the Principle role, and adding the ability to share a role as if it were a true fact. Combining the last two would give RM for the first time the ability to copy a fact to other individuals in the database. I think RM users would quickly find all sorts of amazing and wonderful ways to use such enhancements.

Jerry

P.S. Even if the ability to copy facts to other individuals were added, RM still needs to the ability to export roles as facts - in GEDCOM, to FamilySearch, and via TreeShare to ancestry.com.