Passbolt Tags Functionality

Design Discussions

Some of the most expected features of passbolt are categories (also called folders) and tags (also called labels). Since multiple approaches are possible for the design of these features, we wanted to take a step back, share some of our thoughts and discuss the options with you.

What problem does it solve?

Sharing passwords using groups is already possible in passbolt and can help organise the passwords. It is often not enough for small teams or users with a lot of passwords, who often need another way to organise their data.

How are tags different than categories?

The major difference between categories and tags is that, in most systems using folders, a given item only belongs to one folder. Inversely, when tagging, one item can be linked to many tags. Also while it is possible to have a hierarchical tag structure it is also less common.

Why start with tags instead of categories?

We believe this associative property of tags provides more flexibility than categories and since tags do not have a hierarchy, they are easier to implement.

How can/will people use tags?

Tags should be suitable to organize passwords by:

Projects: As any overpaid corporate management consultant would tell you, transversal organizational structures are the future. Project managers will love this.

Flags: similar to “favorites”, tags can be used to bring attention to a given item. This helps with the deduplication or the moderation of not suitable for work (NSFW) passwords.

Statuses: Tags can also be useful to identify which resource (the password or the system it is associated with) requires a given action. A workflow process, for example, can use tags to show what needs to be done:

Properties: for example a given system administrator manages multiple servers with different authentication mechanisms (SSH, 2FA, etc.) or the network section (DMZ, VPN, etc.) or any other fancy three letter acronym system. In short, tags would be a good way to confuse the mortals the sysadmin want to keep in the dark.

Tires on burning pile of garbage: let’s not fool ourselves, even with a concerted effort to create a shared taxonomy, tagging is going get messy. Similarly with a bottom down approach the taxonomy may end up being tedious and therefore only used by the person who designed it. We recommend you hold several, long-winded meetings over the course of months debating and discussing the taxonomy that works for your organisation.

Should the tags be kept personal or be shared?

Ultimately tags can been seen both as a shared or a personal organisation system. Some organisations will want to use tags to sort entries by projects. Some individuals will want to organize their passwords following their own personal classification.

The design needs to strike a balance between these two conflicting approaches.

Option 1. My tags are only set and seen by me:

The first approach is similar to tagging in most web clients. The biggest advantage is that all the tags are relevant to the user, since they are the one creating them. Conversely the user can set its own organisation system without having to inflict it on other people. This will surely reduce semantic bickering.

The main issue is that this system does not allow people to collaborate. Interestingly this also has an impact on the learning experience, since there is no way to see how other people are using tags.

Conclusion: Since collaboration is at the heart of passbolt this option alone is not sufficient.

Option 2. Tags are set by the password owner (or people who can edit):

Much like tagging articles in a CMS, or duckfaces on Instagram posts, tags could also be set by the content creator. Many opportunities arises when tags are shared since they can be used to collaborate. For example, they could be used to help somebody else isolate/identify a set of passwords, or they could be used to group resources by projects.

The main issue with this approach is that, even if you do not see the tags of the resources you do not have access to, not all the tags will be relevant to you. Tags can also have different meaning for different groups of people. For example, one group decides that the tag “to update” means that one needs to update the credential. Another group might decide this tag means an update for the underlying system is needed. If you are member of both groups then good luck getting your bonus. Similarly some content creators could be more heavy handed than others and their overtagging habit may increase the effort needed to use them.

Conclusion: this option allows to collaborate but is prone to create a lot of unmoderated content and therefore make the feature less interesting to use over time.

Option 3. The taxonomy is defined by the admin and tags are set by the owner (or people who can edit)

Similar to the solution chosen on Github’s issue board, and to deal with the drawbacks of option2, it is possible to create a pre-moderated tag list that the content creator needs to choose from. The biggest advantage of planning the taxonomy in advance is that it will provide the perfect opportunity for a meeting where self-appointed specialists can discuss what is best for the rest of the organisation. While this could be seen as another pointless bureaucratic overhead by some, this option will certainly help keep things tidy.

Option 4. A combination of some of these options, e.g both personal and shared tags.

The last option is similar to what you can find in google docs, where personal and “shared with me” folders coexist. Passbolt could offer a combination of personal and shared tags and allow people to switch between them. In practice that could mean that two lists of tags are proposed and editable.

While this approach is the most flexible, it is also raises different challenges to explain these complex concepts to the user in an intuitive way. It is also more complex to develop and test, which would delay the rollout of this feature. Finally, this option might be risky for users who accidently create shared tags that say things about their pointy haired boss.

Bonus questions

Should capitalization be allowed in the tags?

Do we want to consider ‘Alpha’ and ‘alpha’ as the same tag or are they different tags? Considering them as different tags is the most flexible but can lead to duplicates and errors while tagging.

Our prefered approach would be that all tags are set to lower case by default, ‘Alpha’ and ‘alpha’ are the same tag and displayed as ‘alpha’ at all times. User can enter either of them, but the input is transformed to lower case while saving server side. We will go with this option unless you absolutely beg us to change our minds.

How will it look?*

First iteration

With all these options on the table it may seem premature to try and figure out the design. However, there are a few elements that we are certain of. Notably in the first iteration of tags in passbolt, the product must support the following to be useful:

• People must be able to see tags in both the left and right sidebars. Click on a tag should filter the password using this tag. Similarly it should possible to get relevant search results using tags as input.
• The tag editor must be easy is to use and work well with the mouse and/or keyboard. Users should see a list of proposed tags when adding/editing tags to promote tag reuse. The tag editor should prevent people from entering the same tag twice.

Future plans

While the first iteration would not include it, a future version should be able to support performing multiple actions using tags. For example allow sharing all passwords that have a given tag. Users should also be allowed to rename a given tag (to avoid deleting / adding it back to all items). Associating a password with a tag should be possible using drag and drop.

We will also consider creating a tree-like hierarchy within the tags using “/” delimiter.

Update: Survey results

As for the open points listed above, we have setup a poll and a discussion space on the community forum. Around 20 people filled out the survey, here are the results:

What would be the best tagging system?

Should the tags be lower case?

Some of the feedback was very interesting and brought forward some new ideas:

We would like to see the tagging system open, flexible and general similar to Slack and Twitter, etc… anyone with edit access can add any tag, tags can be prefixed by special character like “#” or ‘@’ to indicate a group, user or system level tag.

We will now work on the functional and specifications before moving on to the implementation in v.2.0. As always feel free to reach out by email or on the forum if you have questions, concerns or new ideas.