Tag Functionality Analysis

Mar 02 2016
Edited: Oct 22 2018
Laddice Insights0. Product Principles

The purpose of this document is to analyze tagging so we better understand the fundamental uses of tags and tag hierarchies, the implications of introducing various functionality, and how to better craft a user interface for these functions. The following are various questions/issues posed to externalize and clarify my thoughts (|A)

  • Why use tags?

    • Allows item to be found in multiple categories

      • When we are not sure where it belongs and want to be able to find in multiple ways

  • Other ways to use tags:

    • Allows for tagging multiple attributes

      • So we can search a tag by a collection of attributes

      • This is similar to filtering a spreadsheet by a number of attributes specified in different columns (&K)

        • Consider managing attributes with Spreadsheet View? (*M)

  • Why hierarchical tags?

    • Simply allows user to organize their tags into folders so they are easier to find and implement later

      • This is the primary function

      • This is the "bag of tags" mentality (&K)

        • In this case, the user may simply want a tag to exist in multiple places so that it can be found in different ways

  • Other benefits of hierarchical tags:

    • Clearly define categories of attributes and what options exist under each attribute

      • Ex: Task

        • Open Task

        • Closed Task

        • Cancelled Task

    • Define categories and sub categories so that items can be found based on broad or narrow tag filters

      • Ex: Science

        • Physics

        • Chemistry

  • Challenges introduced by hierarchical tagging:

    • Tags exist inside of other tags which can be confusing...when do you tag something with an attribute vs the name of the attribute?

      • Alternatively, we can have tags exist in folders (non tags) (&K)

        • Back to "bag of tags" approach

    • Naming becomes an issue

      • When a tag is inside of another tag, it's context is implied by the parent tag name

        • Users will likely not want to be repetitive

          • Ex: Task

            • Open Task --> Open

            • Closed Task --> Closed

              • Now you have two tags called "Open" and "Closed" which don't mean much when considered outside of the context of their parent tag "Task"

              • Tags don't appear 0n the node in the context of their parent structure so this is confusing (&K)

              • And what happens if these tags get moved?

  • Solutions to our challenges:

    • Option #1: Folders for tags instead of tags in tags

      • Pros

        • Eliminate the possibility of tagging something with an attribute name

    • Option #2: Standardized hierarchical tags with certain blocked functions

      • Duplicate names are possible

      • If user tries to place a tag in another tag that already has a tag with the same tag name, block move and alert user

      • In other words, uniqueness is dependent on unique hierarchy and not unique tag name