Card sorting is a common technique in information architecture for developing the organization of menu labels or categories on websites. It would thus seem to be a very suited methodology for developing all kinds of taxonomies, but in actual practice card sorting is not utilized for most taxonomy projects, at least not in my experience.
Card sorting gets its name from the paper-based approach of having numerous category or concept names written down each on a small index card, and then the cards can be sorted on a table into logical categories. Multiple stakeholders and/or test users are given the opportunity in turn to organize the cards as they deem appropriate, and the person administering the card sort, takes note of the choices and considers them for the actual organization structure. Today, card-sorting software, especially that which is web-based to allow remote access, has largely replaced the physical cards.
There are two variants to card-sorting exercises, the open card sort and the closed card sort. In an open card sort, participants sort the labeled cards in any groupings they see fit and then they assign their category groups with any group name they want. In a closed card sort, the participants are already presented with a set of named top category groups that they cannot change, and are asked to sort the labeled cards into the pre-assigned categories. Each type of card sort has distinct objectives and is suited for different stages of the project.
Open card sorting is a good way to get a new taxonomy from scratch off the ground when you have some concepts (extracted from the content) and don’t know how to organize them. However, this is increasingly no longer the scenario. It’s rare to start creating a taxonomy from scratch with no other reference for top categories. There are so many taxonomies in existence now for all subjects, that it’s easy to find a starting point as a model. Furthermore, the owner of a taxonomy may have already designated the top categories for business reasons.
The aim of closed card sorting is to determine in what broader category narrower categories belong, especially if there is uncertainty. But if a narrower category could rightfully belong under more than one category, rather than force a choice between one or the other based on a card sort, the subcategory could belong under both. This is what taxonomists call “polyhierarchy,” and it acceptable as long as the hierarchy is sound and valid in both locations. Thus, closed card sorting is only needed when you have decided you do not want polyhierarchy. Polyhierarchy is generally a good thing, because it provides more than one navigation path to the same results, and different people choose different paths. Sometimes, however, polyhierarchy is avoided near the top levels of a taxonomy in order to maintain a sense of tree structure.
Card sorting is most practical for just two levels of hierarchy: concepts and their immediate parent categories. It’s possible but unwieldy to suggest to users that they may create three levels, and some card sorting software does not even allow it. Often it is more reliable to just run a second series of card sort testing for another hierarchical level in the taxonomy. However, running multiple card sort exercises for different hierarchical branches of a taxonomy can be quite impractical, if not also costly and time-consuming.
Finally, card sorting works only for traditionally hierarchical taxonomies. It does not work for faceted taxonomies, where terms from different facets/attributes are selected in combination to limit or filter search results. Faceted taxonomies are becoming increasingly common.
Card sorting continues to be useful for information architecture, though. When designing the structure of a website and its main and submenus, it can be difficult to decide what the categories should be, because the content of a site can be unique or nonstandard. Additionally, polyhierarchy is not expected in submenus and could be confusing. Finally, website navigation is often not deeper than two or three levels, unlike many taxonomies that are often four or five levels deep and thus impractical to thoroughly design or validate with card sorting.
Friday, August 30, 2013
Wednesday, July 31, 2013
Tags and Categories
What does a taxonomy comprise and how does it work? Professional taxonomists may speak of “terms,” “nodes,” or “labels,” whereas most other people with a basic understanding of taxonomy might refer to “tags” or “categories.” A category is a well understood concept, and social media sites have made the notion of “tag” well known.
In addition to the different professional level of such jargon, there is also a distinction in meaning. Ironically, it’s the professional terminology that is vague and the layman terminology that is more specific. Taxonomy “terms,” “nodes,” or “labels,” are all pretty generic and can all have various applications for different kinds of taxonomies, both for broad categorization and for specific indexing. “Tags” and “categories,” on the other hand, each tend to have distinct meanings. It’s not so much what they are, or even how they are organized, but rather how they are used.
Tags are for tagging.
That seems obvious. As for what is meant by “tagging,” that implies you put a tag on something. In fact, you can put more than one tag on something, and that’s typically encouraged in tagging. “Something” is typically an electronic file of some form of content, a document, image, video, database record, blog post, etc. Tags tend to be a brief label indicating what something is about. Tags can be very specific or relatively broad. Information professionals might prefer to call them “index terms.” An organized, alphabetized list of tags could serve as an index.
Categories are for categorizing.
This can also be called grouping or classifying. It implies putting something into a category, often represented as a file folder, whether an actual electronic folder path, or just a depiction of a folder icon. While categories have different levels of specificity, the name category implies a collection of things, so there is an implicit understanding that categories don’t get too specific. An organized structure of categories typically constitutes a hierarchical taxonomy.
Can something go into more than one category? In physical folders no (unless you make photocopy of the document for each folder), but in the digital world, often the answer is yes, but not always (again requiring the copying of files). It depends on the system, and it may involve some workaround. Even when it is possible to put a content item into more than one category, unlike tags, it is still preferable to have most content items assigned to only one category and a smaller number of them that may belong in two categories. For example, there may be a breadcrumb trail for the hierarchy of categories, and the breadcrumb trail may only take a single path. The idea is that the categories retain distinct meaning and usage through mostly distinct content.
Tags and categories together
Because tags and categories are different, it is possible to have both at the same time, especially if the categories are deliberately kept broad and the tags are relatively specific. Content management systems and digital asset management systems increasingly offer features of both categories and tags for managing content. In these cases, the challenge is to decide to what degree of classification to use the categories and to what degree to use the tags. That's exactly what I have done as a taxonomist on two recent consulting projects.
For the amateur taxonomist and indexer, one of the most common exposures to tags and categories is through blogs. Blogging software may permit the blog author to assign a tag or category to a blog post. Whether the tags and categories are appropriately named and used is another issue, though. Blogger.com provides only one option, which it calls "Labels" and utilizes an icon for a tag in the blogging interface, but then displays them when published in the right margin under a heading called "Categories." No wonder my "categories" don't look good; I had created them as if they were tags. Furthermore, the very specific subject matter of "The Accidental Taxonomist" blog makes its posts more suited for tagging than for categorizing. WordPress, on the other hand, gives the blogger both tools: tags and categories. If “The Accidental Taxonomist” blog eventually moves, you’ll know why.
In addition to the different professional level of such jargon, there is also a distinction in meaning. Ironically, it’s the professional terminology that is vague and the layman terminology that is more specific. Taxonomy “terms,” “nodes,” or “labels,” are all pretty generic and can all have various applications for different kinds of taxonomies, both for broad categorization and for specific indexing. “Tags” and “categories,” on the other hand, each tend to have distinct meanings. It’s not so much what they are, or even how they are organized, but rather how they are used.
Tags are for tagging.
That seems obvious. As for what is meant by “tagging,” that implies you put a tag on something. In fact, you can put more than one tag on something, and that’s typically encouraged in tagging. “Something” is typically an electronic file of some form of content, a document, image, video, database record, blog post, etc. Tags tend to be a brief label indicating what something is about. Tags can be very specific or relatively broad. Information professionals might prefer to call them “index terms.” An organized, alphabetized list of tags could serve as an index.
Categories are for categorizing.
This can also be called grouping or classifying. It implies putting something into a category, often represented as a file folder, whether an actual electronic folder path, or just a depiction of a folder icon. While categories have different levels of specificity, the name category implies a collection of things, so there is an implicit understanding that categories don’t get too specific. An organized structure of categories typically constitutes a hierarchical taxonomy.
Can something go into more than one category? In physical folders no (unless you make photocopy of the document for each folder), but in the digital world, often the answer is yes, but not always (again requiring the copying of files). It depends on the system, and it may involve some workaround. Even when it is possible to put a content item into more than one category, unlike tags, it is still preferable to have most content items assigned to only one category and a smaller number of them that may belong in two categories. For example, there may be a breadcrumb trail for the hierarchy of categories, and the breadcrumb trail may only take a single path. The idea is that the categories retain distinct meaning and usage through mostly distinct content.
Tags and categories together
Because tags and categories are different, it is possible to have both at the same time, especially if the categories are deliberately kept broad and the tags are relatively specific. Content management systems and digital asset management systems increasingly offer features of both categories and tags for managing content. In these cases, the challenge is to decide to what degree of classification to use the categories and to what degree to use the tags. That's exactly what I have done as a taxonomist on two recent consulting projects.
For the amateur taxonomist and indexer, one of the most common exposures to tags and categories is through blogs. Blogging software may permit the blog author to assign a tag or category to a blog post. Whether the tags and categories are appropriately named and used is another issue, though. Blogger.com provides only one option, which it calls "Labels" and utilizes an icon for a tag in the blogging interface, but then displays them when published in the right margin under a heading called "Categories." No wonder my "categories" don't look good; I had created them as if they were tags. Furthermore, the very specific subject matter of "The Accidental Taxonomist" blog makes its posts more suited for tagging than for categorizing. WordPress, on the other hand, gives the blogger both tools: tags and categories. If “The Accidental Taxonomist” blog eventually moves, you’ll know why.
Thursday, June 6, 2013
How Many Facets
Faceted taxonomies (taxonomies with attributes, dimensions, filters, etc. to limit search results based on the combination of selected criteria) are becoming increasingly popular with the support of web database technology. Unlike traditional hierarchical taxonomies, designing a faceted taxonomy first requires a decision on how many facets to create. There are various factors to take into consideration.
What the content supports
What the end-user user interface supports
Sometimes a website or intranet is created in a web content management system that does not give as much flexibility in taxonomy display. For example, SharePoint requires a horizontal list of facets, if the facets are to be used to filter content displayed in “columns,” where facet names are the column headers. Furthermore, SharePoint will by default create columns for document format type, content type, author, date created, and date modified. While you can hide these columns, if you want to use some of these defaults, that will limit the number of other descriptive facets for columns to about three or four.
Facets that limit search results are typically displayed in the left-margin, so more facets can be created. However, the number of facets should be limited so that all of the facet labels (although not necessarily all of their contents/facet values/terms) display by default without scrolling. The first 4-6 terms or values within a facet should be displayed to give the user a good understanding of what is in there, with a link or button to “show more.” Scrolling can be used when a facet category is expanded. So, what needs to be considered is the vertical space if all facets display at least some values, and if that does not fit, whether some facets can be collapsed by default. The example below of the facets for limiting people search results on LinkedIn shows the default display of two facets with the first 6 terms, one facet with all 5 terms, and 12 facets collapsed (an unusually high number of facets).
What the tagging process supports
Organizations which tag/index content for subscription sale, on the other hand, where content indexing is core to their business, will invest in dedicated indexers who can be given thorough training in assigning terms from multiple facets and will also check their indexing for quality. Thus, for professional indexing, a greater number of facets can be supported.
In automated tagging, it’s not so much a matter of how many facets, but rather how distinct the facets are and how easy they are for automated tagging. There are different technologies out there, but, in general, named entities/proper nouns are easier to distinguish than topical subjects. So, facets for author, location, department, product name, etc., are easy to classify automatically. Language, and a document type that is based on file format are also straight-forward for auto-classification. Subject or Topic could be catch-all for high-ranked keywords. If you want to create facets for different kinds of topics, though, such as Purpose, Activity, Significance, Origin, etc., the distinctions will likely be too challenging for an auto-classification tool.
Monday, May 6, 2013
Topics and Document Types in Taxonomies
It’s quite common in a faceted taxonomy to have a Document/Content Type facet (I’ll call DocType here), whose terms define what a content item “is,” (a report, a blogpost, a form, a contract, a letter, a policy, etc.) and also a Topic or Subject facet, whose terms describe what a content item is “about” (legal compliance, training, new business, insurance, company information, etc.) While usually it’s pretty clear-cut what belongs in the DocType facet and what belongs in the Topic facet, occasionally there are some ambiguous concepts, so asking the questions “what is it?” versus “what is it about?” helps in making the distinction.
Often the taxonomist can resolve ambiguity by editing the term so that a one-word generic document type is appended to a descriptive word. For example “Marketing” by itself is a Topic, but “Marketing Material” is a DocType. This kind of decision is reached only after looking at the set of documents and determining whether there is a significant number of them that are really marketing materials versus a significant number of them that are really about marketing (and there could be both). You then have to decide how far to go with this. You could force otherwise topical concepts into DocTypes by adding the word “Document” to the end of many terms. For example, “Compliance” becomes “Compliance Document”, and Client Management” becomes “Client Management Document.” Depending on your overall content set and taxonomy design, this may or may not be acceptable practice.
Another complicating issue that may come up in designing such a faceted taxonomy is what to do if certain Topics only occur in certain types of documents. This is not unusual. While DocTypes such as Report, Evaluation, Meeting Minutes, Memo, Article, Review, etc., are rather generic and could all be associated with any number of the same shared set of Topics, other DocTypes that a customized for a specific content set are more limited in their application. For example, Topics for different types of approval to be used only with a DocType of “Approval Letter,” or Topics for types of product information to be used only with a DocType of “Product Information Sheet.”
There are two ways to handle this issue:
1. Create rules permitting certain Topics available as options only when certain DocTypes are assigned
This requires that DocType be assigned (tagged, indexed, matched, etc.) to a content item first, before the Topic is assigned. This can be seen as: the Topic is dependent on the DocType, or DocTypes terms drive the Topics, or the DocType takes precedence over the Topic. This is feasible with these facets, since a content item can be assigned only on DocType (in contrast with the possibility of getting assigned more than one Topic). What gets complicated, though, if there are additional rules between other facets, with the terms in one facet driving the availability of terms in other facets, such as File Type, Source, Department, etc.
2. Merge the DocType and Topic facet into a single facet
This may seem extreme, but it could be practical, especially if it’s easier for the end-user. It works if the there are not so many Topic terms, such as not many more than the total number of DocType terms, the majority of them are applicable to a single DocType term, and a user interface can be designed that supports an expandable/collapsible hierarchy, so a user clicks on a DocType and the applicable Topics underneath it display. Traditionally taxonomies are hierarchical after all. If a Topic term is valid for more than on DocType, then a valid polyhierarchy results. There could still be a distinct facet for File Type/Format (such as HTML, text, image, PDF, etc.), for which there would be no ambiguity, in contrast to the occasional ambiguity between DocTypes and Topics.
In either case—whether rules for the terms of one facet driving the availability of terms in another or whether a merged expandable hierarchical facet is created—collaboration is needed between the taxonomist and the technical experts who configure the implementation of taxonomy in the content/document management system.
Monday, April 22, 2013
Capitalization in Taxonomies
The question often comes up: what is the preferred style for the capitalization of taxonomy terms? Other than all proper nouns being capitalized, there is no strict rule for generic terms. In making the determination, it’s important to address the following questions. What kind of taxonomy is it? How will it be used? Who are the users, and what might they be accustomed to or expect?
The ANSI/NISO standard Z39.19-2005 Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies states: “predominantly lowercase terms should be used for terms in controlled vocabularies” and continues: “capitals should be used only for the initial letter of proper names, trade names and those components of taxonomic names, such as genus, which are conventionally capitalized.” But remember that ANSI/NISO Z39.19 comprises guidelines and not strict requirements, so the stylistic matter of case does not have to follow ANSI/NISO Z39.19, if a house style dictates otherwise.
Note that there are three options, not just two for non-proper nouns/names, as these explanations themselves illustrate:
1. all lower case (including the first letter of the first word)
2. First letter of first word upper case
3. Title Case (First Letter of the First and Main Words Capitalized)
While the distinctions between “controlled vocabularies,” “thesauri,”, and hierarchical or faceted “taxonomies” can be blurred, these different types do tend to have different practices for capitalization.
A “controlled vocabulary,” as the word “vocabulary” might suggest, is a list of terms (as single words or phrases), similar to what might be found in a glossary, with the possible added feature of synonyms/variants for each preferred term. Capitalization, therefore, could be expected to follow dictionary rules and thus not used except for proper names. A “synonym ring” type of controlled vocabulary, in which no terms are designated as “preferred” and none are even displayed to the user, has no need for any capitalization.
A “thesaurus” is a more complex type of controlled vocabulary with hierarchical and/or associative relationships relating various terms to each other. What are called thesauri tend to be more term-focused than hierarchically focused, and they tend to be large with many detailed terms. The terms can be quite specific, and proper nouns can be mixed in. Thesauri have traditionally been used by indexers to manually index multiple documents consistently over time. The resulting display of terms associated with content for the end-user to browse through is a type of index. Indexes (such as those at the backs of book) often follow the style of lower-case entries for non-proper names, too. If the terms are numerous and specific, they will appear to be and used as “index terms” rather than “categories.” Thus, if it’s called a thesaurus, it will more likely have terms in lower case. The choice of initial capitalization for a thesaurus, though, would not be incorrect, and is probably becoming more common, just as initial capitalization is becoming more common in main entries in back-of-the-book indexes.
A “taxonomy” implies a hierarchical classification or categorization of concepts. When we think of categories we think of labels or headings with subcategories. Headings in general tend to have initial capitalization or title capitalization. Thus, if it’s a strictly hierarchical taxonomy, where all terms are interconnected into a single hierarchy or a limited number of hierarchies, then it will more likely have initial capitalization or title capitalization. Such capitalization is particularly common on the relatively smaller/less detailed taxonomies that are proliferating on websites, intranets, and content management systems. It fits in with the web design style of capitalization on headings and categories.
In faceted taxonomies, which have become more popular in web/online taxonomies, proper names can be separated into their own facet(s), and confusion between proper names and generic terms is reduced. However, I would still recommend only the first letter of the first work capitalized, rather than title case, to minimize any confusion with proper names. The facet name itself, however, could be it title capitalization, since it represents a category heading and not a term for indexing. In fact, it might even be desirable to distinguish the facet labels from the values/terms within each facet by use of a different case style.
A mixed style of different capitalization at different levels is possible in hierarchical taxonomies, too. But I would recommend only the top terms, if any, have a different capitalization style. It would not be a good idea to have only the bottom level terms (“leaf nodes”) in a different case style, because they could change. If you decided that a leaf node should later have narrower terms added, you wouldn't want to have to worry about changing the case of the term. A good application of the mixed capitalization style is if the top level terms were not actually to be used in indexing/tagging but are really just categories/groupings of the actual index terms, which in-turn are arranged hierarchically underneath. (Other typographical methods of distinction could also be used for any non-indexible top-level categories.)
In sum, all-lower case is most appropriate for non-displayed controlled vocabularies, any controlled vocabularies or thesauri that integrate proper nouns into the same hierarchies as generic terms, and large thesauri used to support manual indexing. Initial capitalization is fine for end-user browsable hierarchical taxonomies on the web. Title capitalization is OK for facet labels or the top categories in a hierarchical taxonomy. Whichever style is chosen, however, should be applied consistently.
The ANSI/NISO standard Z39.19-2005 Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies states: “predominantly lowercase terms should be used for terms in controlled vocabularies” and continues: “capitals should be used only for the initial letter of proper names, trade names and those components of taxonomic names, such as genus, which are conventionally capitalized.” But remember that ANSI/NISO Z39.19 comprises guidelines and not strict requirements, so the stylistic matter of case does not have to follow ANSI/NISO Z39.19, if a house style dictates otherwise.
Note that there are three options, not just two for non-proper nouns/names, as these explanations themselves illustrate:
1. all lower case (including the first letter of the first word)
2. First letter of first word upper case
3. Title Case (First Letter of the First and Main Words Capitalized)
While the distinctions between “controlled vocabularies,” “thesauri,”, and hierarchical or faceted “taxonomies” can be blurred, these different types do tend to have different practices for capitalization.
A “controlled vocabulary,” as the word “vocabulary” might suggest, is a list of terms (as single words or phrases), similar to what might be found in a glossary, with the possible added feature of synonyms/variants for each preferred term. Capitalization, therefore, could be expected to follow dictionary rules and thus not used except for proper names. A “synonym ring” type of controlled vocabulary, in which no terms are designated as “preferred” and none are even displayed to the user, has no need for any capitalization.
A “thesaurus” is a more complex type of controlled vocabulary with hierarchical and/or associative relationships relating various terms to each other. What are called thesauri tend to be more term-focused than hierarchically focused, and they tend to be large with many detailed terms. The terms can be quite specific, and proper nouns can be mixed in. Thesauri have traditionally been used by indexers to manually index multiple documents consistently over time. The resulting display of terms associated with content for the end-user to browse through is a type of index. Indexes (such as those at the backs of book) often follow the style of lower-case entries for non-proper names, too. If the terms are numerous and specific, they will appear to be and used as “index terms” rather than “categories.” Thus, if it’s called a thesaurus, it will more likely have terms in lower case. The choice of initial capitalization for a thesaurus, though, would not be incorrect, and is probably becoming more common, just as initial capitalization is becoming more common in main entries in back-of-the-book indexes.
A “taxonomy” implies a hierarchical classification or categorization of concepts. When we think of categories we think of labels or headings with subcategories. Headings in general tend to have initial capitalization or title capitalization. Thus, if it’s a strictly hierarchical taxonomy, where all terms are interconnected into a single hierarchy or a limited number of hierarchies, then it will more likely have initial capitalization or title capitalization. Such capitalization is particularly common on the relatively smaller/less detailed taxonomies that are proliferating on websites, intranets, and content management systems. It fits in with the web design style of capitalization on headings and categories.
In faceted taxonomies, which have become more popular in web/online taxonomies, proper names can be separated into their own facet(s), and confusion between proper names and generic terms is reduced. However, I would still recommend only the first letter of the first work capitalized, rather than title case, to minimize any confusion with proper names. The facet name itself, however, could be it title capitalization, since it represents a category heading and not a term for indexing. In fact, it might even be desirable to distinguish the facet labels from the values/terms within each facet by use of a different case style.
A mixed style of different capitalization at different levels is possible in hierarchical taxonomies, too. But I would recommend only the top terms, if any, have a different capitalization style. It would not be a good idea to have only the bottom level terms (“leaf nodes”) in a different case style, because they could change. If you decided that a leaf node should later have narrower terms added, you wouldn't want to have to worry about changing the case of the term. A good application of the mixed capitalization style is if the top level terms were not actually to be used in indexing/tagging but are really just categories/groupings of the actual index terms, which in-turn are arranged hierarchically underneath. (Other typographical methods of distinction could also be used for any non-indexible top-level categories.)
In sum, all-lower case is most appropriate for non-displayed controlled vocabularies, any controlled vocabularies or thesauri that integrate proper nouns into the same hierarchies as generic terms, and large thesauri used to support manual indexing. Initial capitalization is fine for end-user browsable hierarchical taxonomies on the web. Title capitalization is OK for facet labels or the top categories in a hierarchical taxonomy. Whichever style is chosen, however, should be applied consistently.
Subscribe to:
Posts (Atom)