Taxonomies (and related improvements to tags)

[richardolsson]

Some organizations struggle with having too many tags in Zetkin, which make them difficult to use. And there are potential use cases for tags where they fall short because of the amount of tags that would be needed, e.g. a union tagging members with their employer/workplace.

I'm proposing a new feature that would solve this, by allowing tags to be categorized or grouped into "taxonomies". You could have a taxonomy (group of tags) for something like area of residence, and then a completely separate taxonomy for employer. Because they're separate taxonomies, UI could be designed to keep them apart.

Current tag usage

I've analyzed patterns among the tags currently use by Zetkin organizations. These are some common use cases for tags, some of which would be nicer to work with if they could be grouped in taxonomies:

• Join dates (by decade, by year, by quarter, by month)
• Source (website, recruiter)
• Demographics (age)
• Geography (city, zip code, area, neighbourhood)
• Member status (new member, member, paid per year, paid per month)
• Profession (health worker, teacher)
• Affiliations (e.g. union membership, youth league)
• Sub-organizations (branch, chapter)
• Activity level (active, passive, supporter, super activist)
• Roles (admin, organizer, board member, treasurer, instructor)
• Process milestones (voted in X, invited to X, called during X)
• Languages
• Skills and assets (musician, car, driver's license)
• Flags (priority, do not call, contact, moved away)

[richardolsson]

The idea is to use this feature for the upcoming Timelines feature that is currently being conceptualized as a way to use Zetkin for union case work, among other things.

For this to work, it needs to be possible to tag things besides just people. The idea with taxonomies is that it would allow us to open up tags to be used for (almost) anything in Zetkin. If the user wants a set of tags to only be used for people, they could create a taxonomy for those tags and call it something along the lines of "People tags".

Tagging campaigns, events, people, timelines, surveys, locations and other pieces of data using the same taxonomies would allow for some very interesting synergies and a "layer" of categorization on top of all of Zetkin.

[richardolsson]

The relevant user stories from our "Case work" research are these:

• When I receive a complaint or enquiry from someone, I want to be able to see whether they are an eligible member, so that I can take the correct action
• When I'm opening a case, I want to be able to categorize it, so that referred caseworkers know what type of case it is
• When our understanding of a case evolves, I want to be able to change the categorization of the case, so that it's up to date with the information we have
• When a case settles, I want to log that in the system so that we can separate it from win or lose
• When a case is neither win or lose, I want to be able to pick from a list of predefined outcomes, so that we categorize our cases consistently
• When I'm planning for resources, I want to know how many cases were referred from caseworkers to the legal team each month, so that I can tell what percentage of cases require legal work
• When I'm planning for resources, I want to know how many cases were actually opened directly by the legal team each month (ie not referred), so that I can tell what percentage of cases require legal work
• When I'm measuring performance, I want to see the total number of cases closed every month segmented by outcome, so that I can see what we're achieving for the member and whether our resources are put to good use
• When a new case comes in, I want to see past cases involving the same employer, so that I can assign the case to a caseworker with experience with that employer
• When a new case comes in, I want to see ongoing cases involving the same employer, so that I can assign the case to a caseworker that is already dealing with that employer
• When I'm managing my time, I want to be able to indicate how big a case is, so that I can signal to others what my workload is
• When I'm working a case, I want to see if there has been organizing efforts in the workplace that the case relates to, so that I can better understand the context of the claim
• When I find a legal angle in a case, I want to be able to see what other members or employees might be affected, so that we can make bigger cases to not just help individuals but also create a group claim
• When a case comes in, I want to find what other workers in that workplace are members, so that I can get more witness statements
• When we win a case, I want to log the amount won in the system, so that we can keep track of the financial impacts of our case work
• When we're doing strategic planning, I want to know the total number of open cases over time filtered by demographics, employer, sector or category, so that I can map casework trends
• When I’m looking for a new group to organize, I want to see if any workplaces stand out in the case work statistics, so that I can focus my efforts on worksites with known problems
• When I create a case, I want to pick the relevant employer and workplace from a list, so that I don't misspell or write it in an inconsistent manner
• When a case relates to the union's strategic goals, I want to be able to tag it so that we can find cases relevant to our goals
• When I’m organizing a workplace, I want to find historical cases that relate that workplace, so that I can better frame my organizing and learn from previous disputes

[richardolsson]

Another idea that I want to put down in writing before I forget about it is to allow tags, when applied to an object, to have a value. In essence, that makes tags synonymous with custom fields (and could potentially replace them).

For example, if you wanted to keep track of a person's neigbourhood/area, instead of having one tag per area you could have an "Area" value tag, and set the value of that tag to the actual area. It could be rendered in interfaces like a tag, but "Area: Downtown".

The value would need to have a type and some other configuration, and part of that configuration could be a list of permissible options, which would function almost as "sub-tags". It would open up for searches like:

• People tagged with the Area tag
• People tagged with the Area tag along with value "Downtown"
• People not tagged with the Area tag

Why is this better than custom fields? For Person data it's the same, but using tags we could apply the same logic to any object. There could be an "Amount won" value tag for case timelines, or a "Population" tag on a geographical area.

[richardolsson]

This is how Sentry renders what they call "tags", which is similar to what's described above as value tags.

[richardolsson]

I've found a good way to explain this variation of tags is an analogy to price tags in a physical store. There you have a tag printer that prints different types of tags, and then you hang those tags on the items in the store.

Some tags are "binary", like a "50% off" tag or "SALE" tag. You can hang those tags on an item to indicate a discount, and the item will either have a "50% off" tag or not have it. You can hang them on there exactly as they came out of the printer. This is how tags work in Zetkin today.

But then there are tags that need some sort of arbitrary label on them, e.g. price tags. It's nice to be able to just write the price on the tag when you hang it on an item, instead of having to print tags for every imaginable price. So instead, you print tags with a blank surface where you can write.

This is how the "value tags" that I'm proposing would work. Just as with a price tag that you can write a price on as you hang it on the item, a "value tag" in Zetkin would allow the user to not just "hang" the tag on something (e.g. a person, a campaign, a view or a timeline) but also give it some arbitrary value.

[GemCopeland]

Cool, I like it! It makes sense to me.

I just need to think more about how users would add the value as they add tags to a case/person/whatever. The simplest would be that adding a colon as you type would make it a value tag. So you can type amount: £10000 and it would know that's a value tag.

Would there be an issue if someone was using a normal tag for a while and then suddenly wanted to assign a value when tagging something? I can't think of a great example yet, but say you're using the tag active for a while and then you wanted to start using that to denote people that were active in a certain year active: 2021. That's a bad example but hopefully you get what I'm asking!

[richardolsson]

We already discussed this on Zoom, but replying here too for others to see.

The UX for assigning tags in general is an interesting one. The common solution of typing to search seems natural, but there are many variations, and the value tag idea does complicate it. It's definitely something we will need to think about!

On the topic of "converting" a tag between a binary tag and a value tag, I think that could be possible. But I do think it would need to happen for all instances of a tag at once (this is where the store analogy breaks down, but it would be like changing the tag printer and all of a sudden all the already printed tags change). So that means it should probably go in some central "tag configuration" area rather than at the time of assigning a tag.

[richardolsson]

One potential reason to keep custom fields and distinguish them from tags, would be to say that custom fields can be modified by the user connected to a person object (i.e. the person themselves) while tags cannot. So any field that you want the user to be able to modify (e.g. update their own e-mail address, etc) should be a custom field.

I think this distinction might be worth investigating further.