Tag Functionality Analysis
ProjectAMPLE
Laddice Learning'sLaddice Learning's
Laddice Learning's Principles of Laddic...Principles of Laddice
Principles of LaddiceThe 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
Implement Option #2, similar to Gmail
reply
The tags on the parent node (2161) are not showing up in blog view
reply
reply
Filter View Feature Ideas
On searching with text, populate distinct "tab" for Users, Text Search, Tags, and then clear the input. By doing this, we allow modular refinement, and open up a way to construct AND/OR etc with these blocks.
reply
AND/OR hierarchical querying with AST Blocks
reply
What follows is a combination of my response to the above, new ideas and further discussion on tags and folders with regards to user utility:
After thinking about it more, I am not a fan of binning tags with folders. The way I see it, the "bin" (tag) may not ever be assigned directly to any Node. So what? In some instances it will, and such a functionality block may be hindrance (conceptual categories) without benefit.
So a pure folder structure is what the conventional tag hierarchy offers, except in the latter, items can "exist" in multiple locations (have multiple tags). This you already know. But what I think you might be missing is that by having a folder of tags in which that folder cant be assigned to a Node, then we make the tag system not able to fully mirror folder structure and in some respects, weaker than folders, as opposed to stronger in all ways.
Files that exist in a folder inherit that folder name + lineage like tags. In that folder may also exist more folders, which can contain more files. Every folder may have files locally inside it. That last sentence is where the idea of tag folders breaks. For now, this is where I'll end my argument against them. I believe one of my ideas below will also make the current Laddice Tag system even more easy to use and powerful given that we dont take the path of tag folders (Functionality 1 & 2b)
Overall tags accomplish something similar folders + symbolic links (same item appearing in multiple places) but the items feel nonlocal and dont have a precise location. With symbolic links, an item will still have a singular physical original location, whereas with tags, its the nether realm. The nether realm being a different view (List.) For the computer illiterate (more like computer unsaavy), folders feel easier (Leanne exhibited this sentiment a few days back) because the items appear in the same view as the folders/tags (Flags??) making for a more seamless experience, at the cost of a poorer organization and categorzing capability, boolean filters etc.
_____________________________________
Heres a few ideas that I think will help us innovate on thus this issue of tags.
UI/UX
If ancestors of a tag arent currently shown (and they will be togglable,) on hovering wih cursor, a tooltip can be shown with it or the full path can be temporarily inserted.
The ancestry/path, can be shown but can be some percentage of the font size and if more than X levels deep, can have a line height of half the assigned tag.
"Short name" property can be utilized. A user can assign a variable short name to a tag, like we already do in pA folksonomy. This will eliminate a good portion of UI clutter while keeping full path visible. Ex: Action/Task/Open => */T/Open. In this case 7 out of 9 letters of the ancestors are pruned. The issue here is that symbols and letters are limited, and it requires the users brain to do some mapping. This comes easy pretty quickly though.
Functional
A user tags an item as Science. Later on, a she decides to further create subcategories to break down what has become too generic a tag. On creating Physics, and then assigning that tag to the Node, Science is removed.
In a similar vain to 1, this is more novel an idea, and merely makes it very easy to assign either existing or newly created subcategories to an item. On hovering over a tag (in, say, the list view, for more than X milliseconds) that has children, show the entire descendant list in a tooltip dropdown. This serves two purposes (or more).
Click button A next to a descendant tag to set or refine a filter.
Click button B to assign (and replace!) the subcategory tag to the node.
reply
UI/UX / 3
Could automatically assign a unique shortname by pulling the first letter or more if necessary
reply