This page is for the discussion of a proposed enhancement of GRAMPS by adding tags.
The following screenshots illustrate the functionality now available in trunk.
Analogy with mails
For people using gmail, tags will not be something new. Instead of classifying mails into folders like in Outlook (Windows) or Evolution (Linux), mails are classified by assigning tags to them. So instead of having a disjoint N:1 classification (a mail can be in one and only one folder, and a folder can contain many emails), in gmail there is a N:M classification (a mail can have several tags, and a tag can be applied to several mails)
Likewise, when you have a big tree, you might want to make subsets of the tree, and these subsets might be overlapping. For example, the subsets of your father's family and your mother's family, some subset of your family that emigrated to the USA, or the famous people in the tree.
The idea is to assign a different tag to each subset: FATHER, MOTHER, USA and FAMOUS for example.
Difference from Markers
Markers are like the folders for mails. A person can be given at most one marker. Tags are thus like multiple-valued markers.
Difference from Filters
Tags and filters both create subsets of the tree. However they have practical differences.
Specifying your father's family using filters is an easy thing; there are already filters based on some logics that do it. On the other hand, specifying the people that emigrated to the USA is harder, while for the famous people in your family it is simply impossible as there is no logical rule. Tags are much more practical here.
However filters have the advantage of being "dynamical". If you add an ancestor of your father in the database, it will be automatically added to the filter. On the other hand, tags are "statical". When adding a famous person in the tree, you have to explicitely tag it as FAMOUS.
Private is a binary attribute of the objects. It can actually be thought of as a tag.
What can be tagged
The most immediate object that comes to mind are the individuals, and that is also the most useful. However, other objects could be tagged:
- Places: For example "places to visit",
- Source: For example "sources in german",
- Notes: For example "notes in progess", or "notes in german",
- Media: For example "Picture belonging to Uncle Alfred".
Tags have been added to People, Families, Notes and Media.
Here are a few ideas of operations that can be done with tags
The most obvious use (and only finality that I have thought of) is that of filtering.
Tagging a selection of objects
Due to the "static" nature of tags, it might be useful to add a tag to a selection of objects. For example one should be able to select a number of person in the Person View, and add them a new tag or an existing one.
It would be useful to have a "Tags" column in the views of objects that can be tagged. The content would be a comma-separated list of the tags of the objects.
Update: The tagging functionality has now been implemented in trunk and the prototype is no longer available. It was intended to demonstrate the functionality of an interface and to investigate some design ideas.
It has the following functionality:
- Edit->Tag menu allows the user to add a tag to a selection of people.
- A toolbar button also allows user to add a tag to a selection of people.
- A Tag selection has been added to the person sidebar filter.
- A Tags column has been added to the person views.
It has the following limitations:
- The prototype allows tagging of people only.
- Row highlighting has not been implemented.
The prototype stores tags as custom attributes with no value. Tags can be added and removed from people by using the standard functionality of the person editor.
Tags should be stored in a new field on the primary objects. This field should contain a list of strings. The API will need methods to get and set this list field.
Storing tags as attributes, as in the prototype, has the following problems:
- Only People, Families, Events and Media have attributes, so not all object types can be tagged.
- Using attributes for two purposes may be confusing for users.
- Attributes will appear on reports and web pages - we don't want Tags to appear on these.
- Custom attributes with no value will be regarded as tags.
- The performance of the tags column may be slow using attributes.
- The size of the attribute type list will grow when tags are used.
There also needs to be a new database lookup table to store the tags together with their colors. Because the tags are dependent on the database, this needs to be within the database rather than in an xml or ini file.
The tags and their definitions need to be included in the Gramps XML schema.
The functionality should be the same as that demonstrated by the prototype with the following additions:
- A tag maintenance dialog to organize tag names and colors. This could be similar to the "Organize Bookmarks" dialog.
- Storing tags in a new field will require new functionality to be added to the editors.
- When an object has more than one tag, the color of the row in the view will be determined by tag priority.
- Tag priority will be defined by the order of the tags in the Tag Organizer. The higher the tag is in the list the higher its priority.
- Should the new tags replace existing marker functionality? Answer: Yes, markers have been removed in trunk.
- A tag will be lost if an object is tagged when its editor is open and then "OK" is clicked in the editor. Do we need to think about this?