I just published a book about metadata, called Metadata Basics for Web Content. The book refers to many standards, and provides samples of code illustrating metadata (or structured data, if you prefer) using these standards. To locate good code examples, I relied on international organizations such as the W3C, industry working groups such as schema.org, and prominent companies such as Google.
All these sources are important ones for publishers to consult. But if you pay very close attention, you may notice that the various sources aren’t always completely aligned with one another. This is a bit disconcerting. Publishers, after all, are expected to comply with standards. Various standards reference and build on each other. But certain details are different as you move between different actors in the standards arena. How can that be, that standards aren’t completely aligned? To answer that question one must consider the governance, mission, and adoption goals of various parties involved with standards.
Publishers should recognize that no one party is in charge of metadata standards. Many parties are involved. Decisions and practices evolve organically through a combination of planning and adaptation. Different parties offer different choices.
The W3C is the largest standards body addressing web content. It has a fairly open structure. If there is sufficient interest in a topic, where enough people volunteer to work on standards issue, then a group can be started, which can begin a process of drafting notes, recommendations, and eventually standards. The W3C doesn’t always initiate standards. Sometimes they embrace standards that have been developed by other groups. And sometimes the W3C has different groups addressing broadly similar issues, but in different ways. While W3C recommendations and standards carry tremendous weight, they do not always represent a single consensus about priorities. Generally, they skew toward accommodating a diverse range of needs, rather than enforcing a narrow set of practices. As a nonprofit body, the W3C isn’t marketing anything, or promoting adoption of one standard over another.
Many industry groups develop standards as well. An important one in the area of web content metadata is called schema.org. This group started out as a partnership between search engine companies, namely Google, Bing, Yahoo and Yandex. These companies developed a core set of standards for describing common web content with metadata. Now that the core standard has been developed, schema.org has subsequently transformed to become a W3C community group. Google remains the single most important driver of schema.org’s development. But as a community, the standard has accepted contributions from many parties, and the scope of the standard is expanding.
In addition to international bodies and industry groups, certain companies, on account of their size and influence, influence standards practices through the implementation choices they make. They may set trends of what are deemed “best practices” or they may recommend to others how to do things. Google again is a leading example of a single firm having a big influence on standards. As a private company, it recommends guidelines to its customers, the publishers who want their content to display in Google’s search results. These guidelines seem like standards, though they are specific to one company.
Let’s consider how different levels of standards interact with each other.
Metadata needs to be encoded using a syntax. One widely used syntax is called RDFa, which is a W3C standard.
Metadata also needs schema to indicate entities and properties within the content. Schema.org metadata can be encoded using RDFa syntax. So we have one standard relying on another. But schema.org only uses part of the RDFa specification. There are some features in RDFa that aren’t needed when implementing schema.org. Other metadata schemas also use the RDFa syntax, and some of these take advantage of the additional features. The group designing schema.org decided to pare down what was needed to implement schema.org in RDFa. They chose to keep things as simple as they could to help promote adoption of their schema.
As mentioned earlier, Google is a key player as both a developer of schema.org, and as a consumer of schema.org metadata. Google evangelizes the use of schema.org metadata, and they offer guidelines and tools to help webmasters learn what they need to do. Publishers often take this advice as gospel. They presume they need to comply with Google’s standards, at least as they understand them. What they may not realize is that Google’s tools and guidelines are often advice rather than rigid rules. When developing its advice and tools, Google has chosen to focus on high priority content that many organizations produce, and provide guidelines to help webmasters ensure that they don’t make mistakes when creating metadata for such content. Google’s guidelines only cover a subset of the range of content addressed by schema.org. In effect, Google has chosen to simplify schema.org further to encourage wider adoption of it.
Google’s guidelines provide assurance that if complied with, the metadata will work with Google. However, it does not follow that if the publisher deviates from Google’s guidelines that their metadata is wrong. Many publishers use Google’s structured data testing tool (SDTT) to validate their metadata. It’s a useful tool, but it validates only some dimensions of schema.org metadata, not all dimensions.
We can see the limitations of Google’s structured data testing tool by looking at how it assesses the schema.org website. We can find pages where the schema.org website, which Google is involved with developing, fails Google’s own SDTT. How can that be? The schema.org website and Google’s SDTT serve different purposes, and even different audiences. The SDTT is trying to encourage certain practices, and in a almost gamified manner, gives a thumbs up if the metadata code conforms to the advice. Schema.org continually develops to cover a range of needs. Some of these needs will be more specialized, and publishers may decide to implement metadata in a standards-compliant manner that doesn’t pass inspection by Google’s SDTT. I would not assume, however, that Google’s search algorithms are incapable of interpreting standards-compliant metadata that fails Google’s SDTT. I’d guess that Google’s search algorithms are probably more sophisticated than the code used in the SDTT. Sometimes the SDTT is playing catch-up with new developments in schema.org.
Google is trying to do two things at once: expand the coverage of schema.org to make it even more useful in a wider range of domains and scenarios, and popularize schema.org by presenting a simple set of guidelines for publishers to follow. It’s a difficult situation to balance, how to manage and evolve standards over time, while promoting easy-to-follow guidelines that publishers consider reliable. I would not expect Google to encourage publishers to adopt complicated metadata implementations that some would struggle to code correctly. If less sophisticated publishers fail, they might fault Google for encouraging them to try something that exceeded their understanding or abilities.
Sometimes publishers gripe that they’ve created logically-valid schema.org metadata that nonetheless fails Google’s SDTT. But publishers seem more upset when they’ve created metadata that passes the SDTT, yet they fail to see how it shines in Google’s search results. Where’s my rich snippet I was expecting? they complain. For many publishers, seeing the rich snippet payoff is the reward for using schema.org structured data, and for using the SDTT. The SDTT is not just a technical tool: it is a marketing and public relations tool for Google.
So does metadata compliance mean that one follows the pages of details in W3C standards, or that one gets a snippet to show in Google’s search results? Standards compliance can involve many layers. There is no one standard to follow: there can be various permutations of a standard that are sanctioned or encouraged by different parties. Publishers need to rely on the standards guidance that best supports the goals they are trying to achieve with their metadata.
People face tough choices in their lives everyday — choices without one clear winner. Perhaps available choices have different advantages, or all choices involve some kind of compromise. Content should illuminate what’s at stake when making these choices. In many situations, content fails to do this. It hides what’s at stake, doing so in the name of simplicity.
When Simplicity is a Ruse
Many of us, myself included, don’t like fiddling with complicated financial decisions. We wish there was a page we could go to and tap a button that says “Don’t bother me with this again — just take care of it” and we’d never have to think about it again. Instead, if we find such a page with such a button, we later find out that we’ve made a decision that is nearly impossible to undo. That same website offers another page with an endless loop of popups asking us: Are we sure we want to cancel, given that there is a $1000 penalty? It might as well ask us if we want to suffer lots now, or suffer a good bit indefinitely.
Financial news channels like CNBC and Bloomberg advertise smartphone apps seeking to manage your money. Some apps promise to find you the best credit card, while others promise easy and cheap mortgages. Tech investors fund countless startups who claim their app offers a new level of simplicity for financial management. These apps have slick UIs, and appeal to prospective customers who imagine themselves as take-charge and in-control. With just a couple of taps on the app, you can execute your decision without the annoying fuss that other firms make you go through. Target users know what they need: an app that lets them make big decisions wherever they are, even while running a half marathon during their lunch hour. Other ads show day traders thumbing their apps, making big buys while walking toward their private jet. Miraculously, the chaotic world of finance becomes a zen-like zone of clarity. Everything is now simple.
These two-tap solutions suggest they offer everything the user needs to know, even if sometimes that’s not true. The apps imply financial decisions can be boiled down to a couple of numbers, and content never has to get in the way of taking action. The best deal never involves a teaser rate that will change, or draconian terms and conditions invoked if you change your mind later. Making a rapid decision never requires one to think about the customer service experience after the fact. Users are asked to trust that all these issues have already been accounted for, and that the app has only chosen options that are free-of-problems, and are the absolutely best ones available anywhere.
Many businesses repeat the mantra of simplicity in connection with their customer proposition. Instead of being a genuine belief, the mantra is often just empty words. Simplicity, a rock-solid idea, can be cynically manipulated to trick customers into believing the convenience they experience is in their best interest.
Simplicity became a marketing buzz word at the same time as user experience (UX) became a commodity. They became features to brag about, rather than experiences to faithfully deliver. Simplicity is a good thing, but that statement needs to be qualified. True simplicity is paradoxically difficult to offer.
Easy Now or Easy Later?
When people working in UX or behavioral economics talk-up the ideal of simplicity, they often are actually championing the notion of convenience. Convenience implies something is easy-to-do, while simplicity implies additionally that something is easy-to-understand. When a company boasts of offering an app that lets you make choices on your smartphone, saying what you need is in the palm of your hand, they are appealing to convenience more than to simplicity. Understanding involves more than taking action in a moment-in-time. It involves seeing how the future of that action will unfold.
For much of the history of the web, people worried about drowning in information, a phenomenon called TMI (too much information). Yet a recent Pew survey of American web users revealed that “worries about information overload are not widespread” now. That sounds like a good thing, and in many ways it is. People shouldn’t feel overwhelmed by information. Smartphones have helped people keep up with information, and their small screens have brought discipline to previously long and complicated content.
But part of that progress has occurred at the cost of removing information that is valuable. The same Pew survey revealed that Americans think that “schools, banks and government agencies expect too much from people”. These sectors are routinely considered difficult to deal with, due to how much information they expect their clients to provide them. To understand why banks and government agencies can’t be as simple to deal with as Amazon, we must consider how such institutions differ from a ecommerce retailer.
Compared with financial, educational and government institutions, retailers can automate their processes to a greater extent. Retailers control most choices about supplying, pricing, presenting and delivering goods to customers. When retailers automate these processes, they remove related complexity from customers. They handle much complexity on the backend, so that users don’t need to experience complexity on the frond end. Simplicity is easiest to achieve when offering straightforward transactions, such as booking a concert ticket, because little information is required from the customer, and the customer needs to understand little in return.
An insurance company, on the other hand, needs the customer to make various decisions that involve multiple steps. Insurance companies can’t presume what the customer wants. Customers need to be actively involved. It is more difficult to automate customer choices, because the customer needs to understand what choices they are making.
Decisions that have Consequences
Trivial decisions are easy to outsource to other parties, but important ones require active participation. People are short on time, and often low on energy. People understandably want choices to be easy. But they are not well-served when content implies decisions are straightforward, when in reality they involve many considerations.
Many customer decisions are iterative, multi-faceted, or nonlinear. Customer priorities and circumstances are difficult to reduce to a few common variables. Imagine being given two or three choices for a hair style when booking a hair cut online, with no further input allowed. While seemingly convenient, such a process won’t ensure a happy outcome. Even though haircuts are generally low-value purchases, they have big emotional consequences for the buyer.
Any transaction that potentially involves “buyer’s remorse” after purchase, where making changes is difficult to do, requires some active involvement from the buyer to indicate what they want. These decisions include:
high-value, feature-rich, or maintenance-demanding products that will be owned a long time such as cars
emotionally symbolic purchases such as family vacations
personalized, long-term service relationships such as insurance and education.
By their nature, decisions that can involve buyers remorse are tough choices. We’d never experience regrets if the right choice was obvious before we made it.
Tough choices typically have many inputs, often happening over a period of time. Certain tasks resist automation, such as deciding on and making medical appointments, or doing taxes. Many decisions are one-off ones, or are infrequent, so that circumstances will have likely changed since the prior time the decision was considered. People can’t just set preferences that will be triggered each time the decision needs to be made.
Some tough choices involve comparing two or more items that have many dimensions to them. Other tough choices involve a single decision to do something that involves some risk. Perhaps the perceived cost of the decision is high, or the effort involved to commit to the decision deflates one’s motivation.
Too Much Information, or Too Little?
Publishers resort to generic ideas to determine how much detail to provide customers. People routinely complain about having to read long documents. Research shows that people feel overwhelmed when offered too many choices,. As a famous, widely-cited experiment demonstrated, when people were asked to choose which breakfast jam to buy, offering too many choices resulted in lower sales. Common sense and experimental research both seem to suggest that publishers should limit the amount of information presented to audiences. Don’t risk making the experience a chore to do — give people what they say they want, which is not having to read much. The case for information- and choice-rationing sounds straightforward. Sadly, we can’t afford to hide an important qualification: what’s simple now isn’t necessarily what’s simple later.
Streamlining information and limiting options is a great tactic for simple decisions like buying jam. But it can be a bad tactic for helping people make tough choices.
Too much information is a symptom, not the core problem. The core problem is that making an informed choice is difficult, due to the nature of the decision. Some businesses eagerly take that chore away from customers, by limiting their choice. They may justify limiting choice by arguing that something that looks complicated does not look trustworthy. Complicated content obscures what’s best for the customer. According to this logic, if the proposition looks simple, then it will be trusted. These businesses consider trust as a matter of optics, rather than of substance. People don’t need to be informed, they just need to feel something is simple.
When publishers remove information that’s critical for customers to know, they are offering fake simplicity. They are restricting vital information, and in so doing, influencing the decisions customers make. Fake simplicity hides information and choices that have consequences for the audience. Fake simplicity hides potential problems from users. Real simplicity addresses potential problems. Informing users about issues and tradeoffs doesn’t make the content complicated — it makes the content useful.
Let’s look at a familiar example of real simplicity applied to an iterative decision. The solution reveals information that could be problematic for users. That solution is the traffic information available on Google Maps. The user can just look at the map, and see how heavy traffic is. It couldn’t be simpler from the user perspective. Behind the curtain, the app draws on complex processes to deliver this information. Google pools data from all its smartphone locations to produce a composite picture of how quickly traffic is moving. It is complex from Google’s perspective, but simple from the user perspective. And it provides the user with vital information they care about in an easy-to-understand manner. No one complains Google Maps has too much information. Its transparency is what makes it useful when making driving decisions. Even though in many cases there is one best option when choosing a driving route, the dynamic variability of traffic means that alternatives and adjustments always need to be considered.
Many apps appear to be convenient because they remove things you should be aware of. Smartphone content in particular frequently hides critical information for the sake of superficial simplicity. Content may:
Hide explanatory information informing decisions
Hide choices or options.
Publishers may hide information or options using UI tricks such as saying “more” or “what’s this?” to de-prioritize important information. They may leave out information people would want to know about, because the information is not legally required to be disclosed — at least at that stage. Often, the gotchas are loaded at the final stage of consideration, in the form of an T&C agreement check box. Sometimes firms offer false choices, believing that having only one attractive option is the best way to get people to make a decision on a complex issue. Or the user interfaces restrict choices that users might want. For example, many people are happy to use Instagram to take photos, until they realize that Instagram doesn’t offer the choice of downloading the photo for use outside of the Instagram ecosystem.
Supporting Genuine Choice
User interfaces are easy to simplify. Human emotions aren’t. When people aren’t sure what choice to make for a decision that has consequences, they want both to understand, and to trust the information available. Trust derives from integrity, and telling the truth.
When the choice is tough, content that suggests all options will make you happy, or there is only one best choice, doesn’t inspire trust. True, customers don’t want too many choices. Normally, more than four choices at once is too much. But people want genuine choice, and know how choices differ and they will be affected by each. They know that all options don’t result in equal levels of long-term happiness.
Choice is an emotional issue. It involves personal expression. One of the purest examples where people want to express choices is an online petition. They participate in a petition not to complete a transaction where they get something in return immediately, but to make their views known. People want choices offered to reflect their real preferences. “Simplicity has it’s limits. Make the process too simple and you run the risk of encouraging ill-targeted, unfocused petitions” notes David Karpf, a George Washington University professor who has studied petition websites such as MoveOn.org and Change.org. These sites don’t try to make choice a single action, but break choices into a few simple steps.
“The feeling of choice…promotes wellbeing. Our wellbeing depends on the ability to exercise choice…” notes Michael Bhaskar in his new book, Curation. People want choice that is meaningful to them personally. They are skeptical when sellers present false choices such as having a “best value” package prominently displayed in the center of options that aren’t good deals. They flinch at choices where it is hard to discern the differences among them, or evaluate which is best for a given situation.
Promoting Real Simplicity
If hiding or rationing information doesn’t help customers make tough choices, what does? There can be too much information — if it isn’t relevant. Real simplicity highlights the parameters that are most important when making a decision. It shows what to consider, and provides the means to choose. Real simplicity doesn’t try to make the choice for the user. It helps the user know what’s important about the choice to consider. It knows what issues have had consequences for people in the past, and reveals these to people now making such decisions.
Real simplicity doesn’t derive from word choices or screen layouts. It embodies decisions about the kinds of information to feature, deciding what choice parameters to prioritize because they ultimately matter most. Moreover, real simplicity offers a framework for understanding and comparing these parameters. Readers have a context to see how different parameters influence their overall choice.
Don’t limit choices unless that is part of your up-front proposition
Don’t condense several decisions into a single package of choices that are hard to discern
Don’t offer choices few people will want to make, to make one seem better
Don’t bury explanations of important criteria
Provide several meaningful choices that will appeal to different kinds of people
Emphasize what is most different about each choice compared with others
Break discrete issues into separate decisions, instead of bundling unrelated issues into difficult-to-grasp decisions requiring a leap-of-faith
Emphasize trade-offs involved with different choices when they exist
Offer ways for people to compare different aspects of a decision across different options, so they can focus on issues of greatest importance to themselves personally
Some of these guidelines trespass on decisions relating to product offers and pricing. Content can’t be separated from these issues. Product managers should understand that attempts to drive customer behavior toward specific outcomes that are optimal for the business are not necessarily how customers consider their choice. We see this issue now in the cable TV industry, where cable operators want to force customers to accept bundles that aren’t valued by the customer. Unless there is alignment between how customers consider and value choices, and how firms offer choices to their customers, the firm’s reputation will suffer, and customer retention be vulnerable to market challengers who offer choices more aligned with customer needs.
Tough Choices are Individual
Tough choices aren’t categorical, divided into good choices and bad choices that apply to everyone. Tough choices involve right choices and wrong choices as they apply to individuals. Take the example of vacations: going to Aspen is not a “good” choice. Aspen will appeal to skiers who can afford it, but won’t to people on a budget or who don’t care for mountains. The individual’s situation and context shapes what’s ultimately best. Even mundane decisions, such as purchasing a new home water heater, involve significant individual variation in circumstances and preferences.
Some of the information needed to support tough choices needs to be disclosed prominently on forms and in tables. Features, specifications, applications, add-ons, exclusions, replacement and servicing costs, renewal pricing, incentives, projected maintenance, refunds and cancellation fees. Everyone can benefit from knowing such details. People can notice these parameters and assess how they may be affected by them personally. Yet content can do more than simply add transparency.
Tough choices, at heart, involve human stories. Why did someone make the choice they did? Different people will make different choices. Each person will have their own reason for their choice. These considerations can be highlighted in stories.
Stories are a powerful form of content, and are well suited to helping people make tough choices. Stories can show why others made the decisions they did, and how that decision worked out for them:
What was their situation at the time of their decision?
What did they consider important, and how did they evaluate the choices available?
How happy have they been with the choice they made?
What do they wish they had done differently?
A great story might be one where a person gets advice from a friend about a decision. The friend is happy with the choice they made, so the person decides to make the same choice. Later, the person realizes they aren’t really happy with the decision they followed. He realizes that his situation is different from his friend in an important respect, and he would have been better off making a different decision. Some of the most powerful stories happen when people learn from mistakes.
Stories aren’t always simple — especially if we equate simplicity with minimalism. They can involve many words, and twists and turns. But stories can make complex situations understandable and memorable. They can help individuals identify what’s personally important about a situation.
Content used in tables requires planning. Some authors consider tables fussy and unnecessary, and assume readers find them confusing. Dislike of tables often reflects mistaken ideas about what content in a table is meant to convey. Many people treat tables as blank cells to fill-in as they please. Such free-form tables are the root source of many problems in large scale content publishing operations. Tables are most effective when their structure is designed to support the meaning of the content they display.
Contrary to popular perception, tables are not really a single content type. Various types of tables exist, each with distinct content structures. Unfortunately, the tools authors use to make tables, whether spreadsheets such as Excel or plain old HTML markup, encourage them to think of tables as a blank canvas on which anything can be added. Just choose the number of columns and rows you want, and a table results. Tables shouldn’t be considered merely as a display format. Tables should, where possible, convey the underlying structure of the content. Structure provides editorial guidance to readers so they can understand the content more clearly, and helps manage how the content within the table is delivered and reused in different contexts.
Over the past five to ten years, data scientists have focused research on how to extract the information embedded in millions of HTML tables published on the web. Researchers consider the data in HTML tables as “semi-structured”. These tables frequently follow predictable patterns, but are subject to great inconsistency as well. Even when the table follows a pattern, the structure is normally implicit rather than explicit.
Published tables of content should indicate an explicit structure that is clear to readers and to machines alike. To reach that goal, we need to understand the implicit structure of tables published on the web today. Many tables follow design patterns that reflect consistent content structures. These patterns can provide a the basis to design templates for tables that will be used consistently.
To perceive the implicit structure of content, think about the content as composed of three parts:
A subject or topic (which we will refer to as “S”)
A property or attribute of the subject (referred to as “P”)
An object or value of the property of the subject (“O”)
For example, we can identify the structure of the following statement: “Mary (S) knows (P) Jane (O).” The property announces some information about the subject that is revealed by the object of this statement.
Tables allow many statements to be expressed in a compact space. The S-P-O technique can be applied to tabular information. Sometimes the information in tables is more complex than the basic S-P-O structure, and some tables (such as a Sudoku puzzle) lack this structure entirely. Nonetheless, the S-P-O structure can help identify the underlying structure of content in many common types of tables.
Let’s consider the content structure commonly found in tables. No standard taxonomy of table formats seems to exist, so I will offer my own terms to refer to these structures. Five common kinds of tables are:
Mutual comparison tables
Alternative list tables
These five kinds of tables are not the only kinds possible, and some authors or data experts will object that these examples limit options for arranging information. Yet it is important to simplify and standardize how information is displayed in tables when publishing at enterprise scale. Knowing widely used and effective patterns for tables provides a basis to develop standardized templates to display tabular information.
Mutual Comparison Tables
The mutual comparison is a very common table type. It lists a number of items (subjects) that all belong to a common category, and then indicates different properties and values for these items. Let’s look at some examples, starting with a table of most active stocks. Each company is a subject, and different properties of the company are identified in the column headings. The values (or objects) of these properties appear within each row. All the companies belong to a common category: most active stocks. It is common for the table heading of a mutual comparison table to refer in some way to the kind of subject listed, and one or more of the key properties associated with that subject. The table makes two kinds of statements. First, that the most active stocks include certain companies such as BAC and AMD. Next, a second kind of statement is made where a company, say BAC, has a price that has a dollar value. Each company in the table has multiple statements, presented in each column.
Let’s consider another mutual comparison table from the website FiveThirtyEight, showing sports teams rankings. While by convention the subjects in the table typically appear in the left column, in this table the subjects (the teams) appear in the third column. The properties of the teams appear on either side of the team’s name. The table heading only implicitly indicates what the different subjects in the table share in common: that they all belong to the NFL.
The archetypal content structure for a mutual comparison table is illustrated below. The arrows show the relationships between different elements in the table. The overarching subject, the category that the table discusses, is indicated by a S’. The individual subjects have one or more properties, each property generally having a single value (but not necessarily so). What the value means depends on the property that describes it, which in turn depends on the subject the property refers to.
Dimensional tables are similar to mutual comparison tables, except that only one subject is discussed. They reveal dimensions of a single topic. Let’s look at a table from Wikipedia about winners of the Booker prize for literature. The subject of the table is the Booker prize.
The table has rows of information relating to the winner for each year. Although the table allows sorting by any column, the key column that defines how the content in a row is related is the year. We can say that the year property is the primary dimension, while other properties such as country (of the author) and genre are secondary dimensions. Such tables identify some primary dimension that varies as a way to structure the content. Typically the most important property of the subject will be the left column of the table. In many cases the primary property is one that is required to exist in order for other properties to also be present. The best way to think about dimensional tables is to consider that they involve a chain of statements. First, we announce that a Booker prize was awarded in 2016. If no Booker prize was given in 2016 (and some awards choose to skip years if they don’t like the candidates), then none of the other properties relating to a 2016 winner would make sense. Two kinds of statements are supported by the structure of the table:
A Booker Prize was awarded in 2016.
It was given to Paul Beatty.
Dimensional tables can be applied to qualitative as well as quantitive properties and values. Here’s an example that’s more conceptual. The subject of the table is strategic communication. Again we see that the columns are not of equal importance. The primary dimension relates to communication function, while other dimensions are structurally dependent on that. The structure of the table indicates that its author considered communication function as the key to understanding communication approaches, rather than say, channel.
The structure of a dimensional table is shown in the diagram below. The secondary properties and their values depend on the primary property.
Alternative List Tables
An alternative list table is similar to a dimensional table in that the table refers to one subject only. It differs in that each property addressed by the table is independent of the others. This means that the rows presenting values aren’t related. The following example of an alternative list table relates to spending decisions. Although the table has no title, the subject of the table is spending. The subject has two properties, which are alternatives. The table answers which kinds of purchases are major, and which are minor. Examples of each are listed under the columns. This is a common kind of table to display content, and is often used to compare products.
The following diagram shows the structure of the content in an alternative list table.
What can make alternative list tables difficult to interpret is that sometimes the creator of the table leaves out information, or implies relationships that may or may not be intended. Let’s look at another example, from the World Bank. The table discusses two alternative ways of thinking, automatic and deliberative. Examples are shown for each alternative. Are the examples just a random list, or do they suggest some additional dimensions?
Many tables using this format choose to leave out a column on the left that would explain what each value represents. In this table, a line is drawn across the values implying that each pair is related. For example, “narrow frame” and “wide frame,” or “effortful” and “effortless,” both seem related pairs. But what about “associative” and “based on reasoning”? Are those opposite or similar, and what exactly do these values refer to? What’s the difference between associative and intuitive, which are both properties of automatic thinking? When tables drop labels, the reader can’t understand the structure of the content presented in the table without consulting accompanying text. This prevents the table from being reusable in different contexts.
A spectrum table is a special type that mixes elements from the alternative list (showing alternative kinds) and the dimensional (addressing distinct properties of a subject) models. When structured properly, it is a sophisticated way to present content.
A spectrum table answers the question: how does a value for a property vary according to some other factor? One set of properties are treated as dependent variables (values change depending on the property considered), while the other set are treated as independent variables. A concrete example will illustrate how the structure works. We can see the service hours provided increases with the price of the monthly package.
In the left column are all the features that could be part of a service offered for sale. The other columns represent different price options, and the table reveals how much of each feature is offered according to price.
The following diagram illustrates the structure of a spectrum table. The column heading will be of the same data type, which allows them to be compared directly.
Most of us are familiar with the pattern shown in the example. But not all product comparison tables are spectrum tables. Many are alternative list tables. Marketers often remove any labels explaining what the values refer to, which allows them to make apples to oranges comparisons, so that the values of every option often sounds positive, even through they many not be addressing the same properties. It’s a disingenious way to hide information when some options lack certain features. Such tables can never be constructed on the basis of features offered, since there are no rules governing what is shown. They are brittle and one-offs. It is not an approach that scales well.
Many tables appear to be matrices, because they contain both row and column headings. A genuine matrix table has unique structural characteristics. Its defining characteristic is that both row and column headings are of equal importance. Each value has two properties. Matrix tables are not common in web content, but can be useful for certain situations, such as classifying concepts. For example, e-learning content might use matrix tables.
First, let’s look at a quasi-matrix. This example from the Sloan Management Review on first appearance seems like a matrix, but actually isn’t. The table has a simple structure, showing percentage values, with both column and row headings of seeming equal importance. On closer inspection, however, the table is actually a mutual comparison table. Although not explicitly noted, the table emphasizes the percentages in the rows representing industry sectors, rather than the columns representing technologies. The percentages in the rows add up to 100%. The row of the table show the relative interest of each industry in different technologies, but the columns don’t show what the relative interest of a technology is among industries. If the survey’s answers were translated into investment forecasts, the table might suggest what percentage of new investment by the retail industry will go into analytics, but it won’t suggest what percentage of spending on analytics will be made by the retail industry. Hence the table is not truly bidirectional in structure.
A genuine matrix can start with a value, and answer two separate questions. Consider the following example, from the World Bank. It answers what kinds of relationships different social networks involve. The relationships involve two independent facets, neither of which is more important than the other. We can look at a friendship network such as Facebook and learn both the type and direction of the ties it involves (assuming of course we understand the terminology used in the table).
The structure of content in a matrix table is presented below. Matrix tables describe two facets of a subject, and explore alternative categories for each facet. Each value will have two properties, which together describe the subject. In terms of the example, we can see that a social network that has both explicit and directed ties is called a friendship network.
Tables presenting content should be planned according to long-term audience and business needs. Unfortunately, ad-hoc tables are far too common. Problems arise when:
Audience-facing tables are not designed around their needs, but are simply generated on demand from queries.
Tables are hand-crafted without thought to their wider use.
For database experts who think about tables in terms of rows and columns, an endless variety of tables can be generated. Much data-centric content suffers from looking like a raw database. Having many variants can be useful for individuals needing highly specific reports, but an anything-is-possible approach lacks editorial oversight. Audiences need tables that explain and compare key variables influencing their decisions. They want to have confidence they both understand, and know they are not missing any key information.
The other kind of unplanned table is created by authors who design on their own to fit a specific need. The problem is especially common in content marketing. Idiosyncratic tables routinely drop explanatory headings, and sometimes add extraneous rows or columns that aren’t directly related to the subject of the table. Authors focus on how to emphasize the wording of content that appears in tables to attract attention to specific items of information. They design online tables as if they were PowerPoint slides, centered on specific messages, instead of representing the content as a whole. Their tables don’t consider how the content may need to be revised and reused in the future. Audiences can find glib tables confusing and untrustworthy.
Content structure is discovered by deconstructing examples. For those involved with content design and content engineering, the first step is to take an inventory of tables used in content published. Look for patterns in tabular content, and standardize these patterns in templates. Remove unnecessary variation, and designs that can’t be used widely. Standardized tables allow content to become more flexible. Templates based on standard table structures will make initial publication and subsequent reuse and updates easier.