We have had both tags and color coding of cards on Task Boards and Scrum Boards for a very long time, but, unfortunately, these operated independently of each other.
There’s no good reason for them to have been separate aspects of working with cards other than simple history: we added color coding many months after we added tags.
Originally we expected color coding to be used in a limited way only: to highlight a few cards on a crowded board that needed special attention.
We had a limited set of 7 light pastels that were chosen to be “color-safe”, i.e. appropriate for use by color-blind people.
Over time, however, we found that people were using color coding a lot more than we had anticipated, and that in fact they were using colors as an alternative to regular tags.
And that was true for the Kerika team as well: we have a “bug” tag that we use to track all work related to defects, but some of us also like to use the red color to highlight cards related to bugs.
And while we could readily agree on the symbolic meaning of a few colors, e.g. Red as indicating something critical or broken, we couldn’t agree on the names or meanings of all the colors.
So, this obviously wasn’t a sustainable path for us: if colors and labels were simply alternative ways of managing your view of a large board, and for collating work across multiple boards, then clearly colors and tags needed to come together as a single concept.
And that’s what we have done with our latest release: colors and tags are now the same thing — all colors have names, all tags can have colors.
Here’s what your Kerika boards will look like, with the new way of showing tags:
A couple of points to note:
All your old tags are preserved with this change, so you don’t have to go back and fiddle with any of your old boards.
We will show more than one tag on a card at a time; this will make it easier to visually scan a large board.
The dialog for managing your board’s tags has also been updated, to reflect the new merger of tags and colors:
When you add a new tag, you have to use a different label from the ones you are currently using: as before, duplicate tags are not allowed.
And the same goes for colors: when you add a new tag, you can’t use a color that is already associated with a label, which means tags have unique colors.
One unique benefit we have added, along with this merger of tags and colors, is the ability to merge tags together.
Let’s say you had been using a tag called “bug” (if you are working on a software project). Some of your colleagues have been using a different tag called “defect”.
You decide that these two tags really reflect the same underlying concept — they are both being used to highlight problems with your software project — so it makes sense to merge these two tags together.
There used to be no easy way of doing this in the past, but now there is:
You can merge tags by renaming one of them, e.g. renaming “bug” to “defect” will cause the system the ask if you want to merge “bug” and “defect” together to be same tag.
You can also merge tags by recoloring on of them, e.g. by changing the color of the “bug” tag to be the same color as the “defect” tag will cause the system to ask if you want to merge these two tags.
We were doing some fairly complicated bookkeeping when people added tags to their Scrum Boards, and we decided it was getting messy both for the system and probably the users as well.
So, we are simplifying tags for Scrum Boards:
Every Scrum Board is connected to a shared Backlog. (And, if there was no backlog to connect to, Kerika will automatically start a new backlog for you.)
Cards on the Backlog may use a certain taxonomy for their tags, while each Scrum Board could add to this taxonomy, e.g. by adding a new tag that makes sense for a particular Scrum cycle (Sprint).
Now, whenever you add a new tag to a Scrum Board, this will automatically get added to the Backlog’s taxonomy as well, and to all the Scrum Boards that share that Backlog.
The effect of all this is to ensure consistency of your tags taxonomy across all Scrum Boards that share the same Backlog: this will make it easier to pull cards from that Backlog into any Scrum Board and know that you will automatically get all the right tags set up for you by the system.
The Tags filter button, which appears on the top-right corner of your Task Boards and Scrum Boards, lets you filter your view of a crowded board by showing just those cards that match a particular tag that you are using (or a particular color coding):
It used to be that when you were filtering your view of the board, you couldn’t add any new cards.
The reason made sense from a technical, geeky perspective, but it proved confusing and frustrating for our users, so we have added more flexibility by letting you add new cards even while you are using filtering.
The new cards will appear as you add them to the board, and stay there until you refresh your view of the board. At that point, whether the new cards continue to appear or not will depend upon whether they meet your tags filtering criteria or not.
That sounds complicated, we know, so let’s take a look at the original logic behind not letting users add cards while using tags filtering…
In the example screen shown above, the board has a bunch of tags defined, like admin, box, bug, canvas, and cleanup.
Suppose we were using filtering, to only show those cards that are tagged bug and box. With this filtering in effect, you are going to see only a small subset of all the cards that exist on the board — only those cards that have either bug or box as a tag. (Or both.)
So, what should happen if you add a new card to the board, which isn’t tagged bug or box?
From a strictly logical perspective, this new card shouldn’t be displayed, because it doesn’t match the filter criteria you are currently using — it should be displayed only if the new card had bug or box as one of its tags.
We originally dealt with this problem by saying that you couldn’t add new cards while using tags filtering, because the new cards would disappear immediately after you had added them, which we felt would make for a very confusing user experience.
(People would likely think they failed in their attempt to add a new card, and keep trying. Eventually they might turn off tags filtering, and then find they had added many copies of the same new card.)
So, that was one solution to the problem, but it still presented a user experience challenge because many folks would forget that they had turned on tags filtering, especially if they were bouncing around between multiple boards. (Yes, Barb, we are looking at you!)
If a user returned to a board and didn’t realize that they had tags filtering turned on, they would get confused as to why they were unable to add new cards.
We thought of a couple of different solutions to this problem, including the use of callouts (those balloon-like bubbles that appear to give you hints about how a page works) but we aren’t generally a fan of callouts — too many apps misuse them to excess these days.
So we have come up with what we think is a better solution: if you are using tags filtering, go ahead and add new cards. They will show up, but if you refresh your page, your tags filtering will be re-applied, and the new cards will be displayed only if they match the tags you want to show.