4 ms·

Most tagging systems that I have seen are free form. Anyone can just tag something with tags like 'James', '2002', or 'Bank Statement'. This makes it difficult

Most tagging systems that I have seen are free form. Anyone can just tag something with tags like 'James', '2002', or 'Bank Statement'. This makes it difficult to distinguish between them and easily find things like misspellings. All tags must be of the same data type (string). A generic term like 'Tank' might refer to a water storage device, a military vehicle, or someone's nickname. With Didgets, I decided to go with a contextual approach to tagging. Just like columns in a relational table, a tag must be defined before you can use it and all like tags are managed together. A tag can have a data type so 'Year' can be an Integer, for example. The system comes with a set of pre-defined tags, but users can easily add whatever tags they might need. That way a tag has the form 'Author = James' or 'Device = Camera'. I went further and decided each tag definition would have two levels. '.person.FirstName = James' might be a tag on a picture of someone named James. This makes it easier to search for tags by group (e.g. find all documents that have '.person.*' tags attached). By managing the tag values together, the UI can quickly show a list of values that have been used previously (and order them by use count). When attaching names to photos, it can show you a list of the most used names and let you pick one or ignore the list and add a new one. This system is far from perfect. Users can still misspell tags or categorize them incorrectly. But this can happen with folder names in existing file systems as well. Just to be clear, tags in Didgets do not have to be the primary organizing mechanism. It has 'Set Didgets' that contain the IDs of all members and can be arranged in a hierarchy just like folders. When importing files, the UI creates these sets (unless the user specifically turns it off) and preserves the hierarchy of the source file system.

asoneth 5y ago
Those are improvements over free-form tags and I especially like the namespaces for attribute/field names, that's clever. The enterprise software my company makes has decent support for defining and applying structured tags like business terms and attribute values to the data objects our customers manage, and our users do make use of those when filtering and searching. But (in my experience) many people still seem to gravitate towards storing and navigating objects hierarchically. I can think of a few possible reasons: First, some people intuitively think of a data element as having a location in an information space. That is, they seem to intuitively remember "where" something is by piggy-backing on spatial memory in a way that tags don't seem to trigger. Second, navigating a hierarchy involves a sequence of constrained choices, like a wizard. Having a sequence of decisions can be especially helpful for novices. It also generally takes a predictable number of steps to locate an item which can be preferable to something that is faster on average but has slow edge cases. Third, at each level of the hierarchy you can often display all of the options meaning we can rely on recognition over recall[1]. (You could constrain yourself to hierarchical tags and use hierarchy-like positional language such as "object is in baz" at which point I'd consider it a hierarchy.) Of course relying on tags has plenty of upsides -- typically faster, better mental model for overlapping sets -- and large-scale data storage systems need both. But at the end of the day they don't seem to be a replacement for hierarchical systems for most people. [1] https://www.nngroup.com/articles/recognition-and-recall/ https://www.nngroup.com/articles/recognition-and-recall/

asoneth 5y ago

Those are improvements over free-form tags and I especially like the namespaces for attribute/field names, that's clever. The enterprise software my company makes has decent support for defining and applying structured tags like business terms and attribute values to the data objects our customers manage, and our users do make use of those when filtering and searching. But (in my experience) many people still seem to gravitate towards storing and navigating objects hierarchically. I can think of a few possible reasons: First, some people intuitively think of a data element as having a location in an information space. That is, they seem to intuitively remember "where" something is by piggy-backing on spatial memory in a way that tags don't seem to trigger. Second, navigating a hierarchy involves a sequence of constrained choices, like a wizard. Having a sequence of decisions can be especially helpful for novices. It also generally takes a predictable number of steps to locate an item which can be preferable to something that is faster on average but has slow edge cases. Third, at each level of the hierarchy you can often display all of the options meaning we can rely on recognition over recall[1]. (You could constrain yourself to hierarchical tags and use hierarchy-like positional language such as "object is in baz" at which point I'd consider it a hierarchy.) Of course relying on tags has plenty of upsides -- typically faster, better mental model for overlapping sets -- and large-scale data storage systems need both. But at the end of the day they don't seem to be a replacement for hierarchical systems for most people. [1] https://www.nngroup.com/articles/recognition-and-recall/ https://www.nngroup.com/articles/recognition-and-recall/