I’m going to write this up as a free standing utility program that performs only one function. But of course I would prefer that it be included in a bundled and comprehensive utility program. The proposal is for a Named Group and Color Coding Manager for RM5. This intent is to supplement the Named Group and Color Coding capabilities that are already in RM5. For example,
- It is possible to create a Named Group from a collection of individuals that are color coded. But it is not possible to create a color coding scheme from Named Groups.
- The criteria used to create a Named Group or to color code a collection of individuals does not apply to any persons or facts or changes made to the database after the criteria are applied.
- It is not possible to save the criteria that were used to establish a color coding or to save the criteria used to create a Named Group and later to reapply those criteria.
- It is not possible to document the purpose of a Named Group or of a color coding with a comment that is associated with the Named Group or color coding.
- It is not possible to establish a default color coding scheme for a database, to temporarily change some of the color coding in the database, and then automatically to reset the color coding back to the default.
- There are not timestamps maintained about a Named Group or a color coding to indicate when they were established or when they were last reapplied.
- It is not possible for the criteria used to define a Named Group or a color coding to include complete Boolean logic (AND, OR, NOT, and parentheses).
- It is not possible for the criteria used to define a Named Group or a color coding to apply two or more tests to the same fact. For example, the test “census date equal 1850” and the test “census place contains Tennessee” are not guaranteed to be applied to the same census fact.
- There are a number of criteria that would be useful to include in the definition of a Named Group or in the creation of a color coding that are not supported by RM5. Examples are that it is not possible from within RM5 to search for number of parents or number of children, and there are a number of source and citation fields that cannot be searched.
The intent will be to address all these issues.
Here follows a mockup of a proposed “main screen” for the utility program. The mockup assumes that an RM5 database has been opened and that the database already includes a number of named groups.
Note that one of the groups was created from within RM5 itself. Such groups will not include additional metadata needed by the proposed Group Manager.
The proposed Group Manager will need two additional tables in the RM5 database. A table called the GroupDefTable would contain the following data elements.
- GroupDefID – a numeric primary key that has no other purpose than to be a unique primary key.
- OwnerID – a unique foreign key that can be joined to RM5’s own GroupTable and LabelTable.
- CreationDate – the date the Named Group was created.
- EditedDate – the date the Named Group was lasted edited.
- Comment – Descriptive text for the group (the area in yellow).
- Color – the color code to be applied to all the members of the group (if any). This data element is on the Edit Group screen below.
- ColorDefaultFlag – a flag to indicate whether this group and its color is a part of the default color scheme for this database. This data element is on the Edit Group screen below.
In order to edit the group criteria for an existing group, the user would double click one of the groups in the list, or would single click or scroll to one of the groups in the list and click the Edit Group button at the top of the screen.
In order to delete the group criteria for an existing group and to delete the group, the user would single click or scroll to one of the groups in the list and click the Delete Group button at the top of the screen.
In order to create a new group, the user would click the New Group button at the top of the screen, and the screen would look something like the following.
After entering the data for the new group, click Edit Group to bring up the Edit Group screen where the group criteria are entered.
This screen and the underlying GroupCriteriaTable are not fully formed in my mind just yet. Because this note is becoming so long, I’ll return to it later and fill in more details of how this screen would work for entering the group criteria and how the underlying table will work. I’ll also follow up with some more details of how the group definition process would interact with color coding.
Discussions & comments from Wikispaces site
22 January 2012 13:47:42
What a great surprise this morning, Jerry! Your proposal and detailed outline sound very thorough and useful. I think Named Groups is long overdue for enhancement and your tool will be most welcome by many. I look forward to your further description and progress and would be happy to assist in any way I can.
Are you developing in Visual C++?
24 October 2012 12:42:33
i also think this looks like an excellent idea. i would definately use this. does it have an ETA?
23 January 2012 23:02:21
I wonder if you have given thought to building and maintaining a list of individual Mark/Unmark settings in addition to the algebraic rules. Your Group Editor might be an adequate user interface with one row taken for each person. Alternatively, I could envision a Mark > Persons or Unmark > Persons opening up another dialog window with the list of persons in the database (as in RM Explorer) with checkboxes – maybe a common list with two mutually exclusive checkboxes each, one for Mark, one for Unmark (or maybe the proper term is Exclude). At its simplest, the dialog interface could just be a list of RINs that the user copies from RM.
I showed a very crude Mark/Unmark of individuals in
This may warrant another table with three fields, GroupID, PersonID and Mark or perhaps a 4th, Unmark. Three would be adequate but the 4th might be easier to work with.
24 January 2012 05:22:16
Yes, I envisioned a mark/unmark capability on an person by person basis. I don’t think an additional table would be required. But whether an additional table would be required or not, the trickier part would be the user interface. As you suggest, the two basic options for the user interface would be to have row after row of “mark/unmark individual nnnnn” (i.e., by RIN number), or to have a RM Explorer style of marking capability
I’m trying to stay away from what I think is RM’s excessive clickiness. So for example, to enter comments about a group, a note window would not open up. Rather, the user would type directly into what I’m describing as the “yellow area”. I would like to do the same for mark/unmark on a person by person basis, but it may be necessary to do it RM Explorer style.