Monthly Archives: January 2015

Content Variables in Content Engineering

Content engineering is an important new approach that can offer greater precision and flexibility in how content is delivered to audiences.   It defines how content is developed, and how it is made available to audiences in different situations.  Much of the flexibility and precision of content engineering comes of its use of content variables.  However, the topic of content variables has received limited discussion thus far.  I want to offer some ideas to advance thinking about this important dimension.

Prevailing Concepts of Variables in Content

Discussions of variables in content tend to treat variables as a list of items that can be reused.  For example, according to MadCap software, a popular tool for managing technical content: “Variables are pre-set terms that you can use in your project over and over.” They elaborate: “Variables are used for brief, non-formatted pieces of content (such as the name of your company’s product or your company’s phone number).”  This explanation assumes the term is “pre-set” and implies a simple substitution of a word or phrase in a location. The problem with looking at a variable as a “term” is that is doesn’t distinguish between what something is called, and what its value is.

Another common form of substitution is to swap out big sections of content to create different versions.  But treating an entire section as a single variable falls short of the precision and flexibility promised by content engineering.

The function of variables in content management systems can be opaque to authors.  In Drupal, for example, some variables may be unique to particular templates, while others are common to all.  Authors don’t have control over where variables can be used in many CMSes. Variables are often administrative in character. A variable might represent “last updated,” which is supplied by the system. There may not be a clear distinction between which variables are strictly backend variables, and which are audience-facing.

Discussion of variables has largely focused on making things simpler for authors, relieving them from having to recreate snippets of content.  While that’s a solid motivation, it focuses on business efficiency rather than on business growth.  The goal should be to consider the business value of a content variable, and offer specific content that offers the highest value to customers and the brand.

photo of bird
This bird is called a variable oystercatcher.  I would see them when I lived in Wellington.  Seemed fitting to have a bird named “variable” looking to catch oysters to inspire us to poke around to find something valuable.  Photo by Tony Wills via Wikipedia.

Application of Content Variables

Content engineering evaluates different content needs, and translates these needs into requirements and designs that support the goals of both audiences and brands. Designated variables reflect the needs of the audience, the business, and the design of the content incorporating the variable. The specification of variables is a core ingredient of content engineering.

  • Audience requirements: From an audience perspective, variables can highlight aspects of content that are engaging.  Our visual perception is drawn to what’s changed, because it might be interesting, or be of concern.  We want content that seems relevant, which is often related to dimensions of time, geography, or frequency.  We desire content that’s personalized, tailored to our specific needs.
  • Business requirements: Brands want to present different content in different situations.   They don’t want their content to be wooden: it needs to respond both to whom the audience is, and to different operational needs of the brand.  Variables enable optimization of content.  With variables, content can change dynamically based on usage, or customer and business analytics.  The variables can reflect — and express — the brand’s business model.
  • Content design: Content design translates the audience and business requirements into specifications that are implemented to deliver content as desired.  These specifications define elements, and associated metadata and business rules, to display different content elements in various circumstances. Variables in these specifications delineate what precise content appears within what section of content.

Variables in Declarative and Imperative Content Objects

Rather than viewing variables as simple text snippets, the content engineering approach considers variables as living content objects, a bit like a Tamagotchi.  Content professionals can benefit by leveraging ideas about variables from computer programming.  While there are differences between how backend systems process variables and how they need to be displayed to audiences, there are broad similarities. Because I want to locate useful common ground, I am going to highlight these similarities in a simplified manner.

Computer programs typically rely on either declarative statements (a statement of what happens) or imperative statements (a statement of what should happen).  Ideally, variables will support not just declarative content (e.g., place content with a given mark up in this place, such as <place author’s name here>.) It will also support imperative content — content exhibiting some novelty when generated through the use of a sequence flow, a test condition, and a calculation.

Declarative statements specify what information to show, rather than how to develop information.  It says “SELECT  {item}… FROM {set of items}….WHERE {qualifying criteria}…”   The qualifying criteria tends to be simple, using an attribute that already exists.  Sometimes there is a compound criteria (e.g., include this but not that), but the filtering still uses known criteria. Declarative programs are typically simpler than imperative ones, and are used when the kind of information that is available is already known. The best examples are SQL database queries, or instructions for accessing content available through an API.

Imperative statements specify how to develop the information to show. Most programming languages that use a sequence of instructions rely on imperative programming. Unlike declarative statements, imperative ones produce derived variables.  Such scripts use content variables to deliver fresh information to audiences. A simple example of a derived variable is a list of the top five most popular articles for a given week. The list represents an imperative variable, telling the computer how to create the list, but not knowing in advance what the information will be.  The information is recalculated each week: the content itself subject to change. A more complex example would be showing what articles are popular with your neighbors.  The list has to respond to an abstract concept of a neighbor, which might be based on visitors to an app or site whose IP address or GPS location indicate they are within 20 kilometers of your current location.

Scripts support business goals as well. Content variables can work with marketing automation and predictive analytics technologies. Digital content is becoming more dynamic, optimized based on known and inferred preferences and predicted behaviors. Such calculation requires imperative programs, and will be essential for personalization of content in the future.

Discussions of structured content, particularly within the technical writing community, have focused on declarative content rather than imperative content. In addition to supporting complex but static publishing of multiple versions of a document, content engineering also produces imperative content to address an infinite range of scenarios, and to provide dynamic, realtime information. We need to be able to support both forms of content: content that’s predetermined, as well as content that’s a more fluid and adaptive. Declarative statements are easier to implement, but imperative ones enable more flexibility and customization.

How can content engineers, who are responsible for developing audience and business requirements, identify needed content variables?  Concepts in programming suggest a framework for thinking about audience uses of variables that can be broadly related to the needs of backend systems.  How backend systems need to handle variables efficiently will be different from how audiences think about them, and even among developers and between programming languages, terminologies can vary. The terrain at times can seem confusing, but I believe the foundations center on three elements.

Framework for Content Variables: Labels/Values/Context

Variables need to be considered in three parts:

  1. The labels used to describe them
  2. The values associated with them
  3. The context in which they are used.

The diagram below introduces a content variable framework addressing the relationship between labels, values, and context.

diagram: content variables
A framework for considering variables in content engineering

Variables are a combination of a label (an attribute identifier) and a value.   The label is the variable’s name. The term label is more helpful than name, because it captures how audiences perceive the identity of what they see.

Values are bound to labels.  The nature of the binding can be subtle: some values can change, others can’t.  Labels for an attribute can potentially change as well.  And differing contexts can redefine both labels and values.

To understand the difference between what something is called, and what its value is, consider two situations.  In one case, people are interested in knowing how many times a given thing appears — counting the number of instances of an item that is labeled in a certain way. For example, how many articles have been written by a given author? In another case, audiences are interested in knowing how many different items (items having distinctly different labels) share the same value.  For example, how many other items have been shared on Facebook as frequently as this article? These examples  are admittedly trivial, but one can highlight interesting and meaningful relationships when content items have multiple attributes.

Range: How Variables Vary

Some attributes have persistence, while other attributes are fluid.  We describe the difference in character as attributes with fixed values, and attributes with mutable (changeable) values.  Knowing whether the range of values for a variable is fixed, or mutable, is a central question.

Fixed variables have values that are frozen. They are identifiers — any ID-type value needs to be fixed. They express discrete (non-continuous) properties. Fixed variables are predefined, rather than being dynamically defined. Text variables are generally fixed: think of a value of a state or province. Other textual variables, the word that describe colors of clothing, or the name of a conference event, are fixed as well. Predefined numeric variables such as postal codes or phone numbers are also fixed — they don’t fluctuate over time. Due to their role as identifiers, fixed values often have rules for what values are considered valid.  Fixed variables are constrained according to these rules, and entries may be validated.  Because their value doesn’t vary over time, they can be counted, and one can count the number of instances of a variable, and determine sets of content items having these defined characteristics. Fixed values are handy for declarative variables: show items with a value of X that does not have a value of Y.

Fixed values can be “keys” that can be mapped to other content. If a content item has an author of a given name, that name is a fixed value.  The author’s name can be mapped to other articles she has written. If there are several fixed values associated with the content, one can find a set of items having common keys. Some fixed values, such as an ISBN number for books, are unique, allowing the attribute to identity the larger item with which it is associated.

Another kind of fixed value is an ordered sequence. The order will never change: the forth U.S. President will always be number four on the list.

Mutable variables are the opposite of fixed ones: the value mutates over time. Mutable variables are dynamic — we expect the value to change. Suppose you are looking for content about vacation destinations that are warm, or stocks that are undervalued. The values associated with those attributes are in constant flux, depending on the weather or the stock market. Many content variables fluctuate in relation to other variables, responding to interactions with other content and with audiences.

Mutable variables are often numeric, representing a continuous range of values. They may relate to the content itself: a count of content items, or analytical data about the audience’s use of the content. Alternatively, the values can represent real world properties that can change, such as prices or inventory levels.

The other major type of mutable content is lists. Lists are collections of items, and items can be added, deleted and reordered. The total number of items will fluctuate. List variables can contain text items that are described with fixed values, but the collection of values in the list itself is open to change.

Mutation Verses Reassignment

Time now to address a technical aspect of variables that can cause confusion: the difference between the assignment of values, and the behavior of values.  It may sound somewhat contradictory to speak of a fixed variable: what varies if the value is fixed?  The answer is the assignment of the fixed value to the label of the attribute.  I have a phone number with a fixed value, a series of digits.  It is different from your phone number, so it is a variable.  But my phone number does not change from day to day. It is not mutable.

Now, suppose I move house. I might speak about changing my phone number, but strictly speaking I am not changing the number itself (its value). I am having a different number assigned to me. My old phone number has a fixed value, and continues to exist, ready to be assigned to someone else. Meanwhile, I acquire a new phone number because an existing number has been reassigned to me from an inventory of numbers not being used.

When two things are related to each other, and both have fixed identities, to make a change, they must be reassigned.

Because of the significant difference between reassignment and mutation, it is best to avoid speaking generically about “changing” a variable.

Scope: Where Variables Can Be Applied

Another key aspect of variables is where they can be used, and what precisely they refer to.  Some variables are comprehensive variables: they refer to the brand as a whole, and all people who interact with the brand. Other variables are more limited in their scope. Scope determines both where a variable can be used, and how a variable is presented. We can think of variable scope in three buckets;

  • Global variables
  • Behaviorally framed variables
  • Local variables

Global variables are the simplest to understand.  They can be used anywhere, and wherever they appear, they mean the same thing. So if an article is listed as the most visited article, it is the most visited article for all platforms, the most visited by all audiences. Everyone sees the same information, regardless of who they are, or what platform they are viewing.

Behaviorally framed variables are the most complex. They are variables where the value is dependent on conditional characteristics, such as time period, audience segment, promotional campaign, or other behavior that is at least partly extrinsic to the content item. The variable is placed within a context: the time frame, the person, or reference group the variable relates to. Consider the seemingly straightforward variable of price. The price shown of an airline ticket can depend on many factors, external and internal. It may depend on timing: different times of year command different prices.  Externally defined variables may have different business rules governing them, reflecting demand and supply.  But other factors are less impersonal. The value presented can depend on who the person is: people who have certain characteristics such as past buying behavior or presumed willingness to pay a given price will be offered different prices.  People who use certain browsers, or who are based in certain locations, may be presumed to pay more or less for an item, and accordingly be shown a different price. The variation in content values can be extended well beyond literal values such as prices to more experientially-focused content variations (such as what order of a list of items to present) that depend on a host of behavioral characteristics. For now, I just want to introduce the notion that a variable relates not just to the label it is associated with, but also the context in which it is viewed. That context may not be explicitly identified to the person viewing the variable.

Finally, local variables apply to how and where content is shown in different content types. For simplicity, let’s consider content types as being a distinct page section, widget, card, or tile, that displays content. The values shown in each of these may be specific to these elements, such as when you present the “most popular <content type>.” Local variables can be more impactful when used to populate specific content types with specific variable content. Suppose you designate some content as a “special promotion for this week.” That designation may trigger a discount (a behaviorally framed adjustment) and also invoke a rule concerning where the content should appear. Designated items might be displayed in a special section of tiles dedicated to promotions, in addition to its default content type location. Content that meet certain criteria can be promoted in various content types to amplify how often it is seen. Viewed from a pull perspective, a content type will include content variables that satisfy certain criteria.

Label Morphing: Getting Microcopy Right

We like to think of the name of our variable as being reliable.  While information architects and copywriters understand the importance of having clearly worded labels, there hasn’t been much attention given to how labels should change in different circumstances. Labels need to adapt to two factors: values, and context. There are two types of label adaption:

  1. Label – value agreement
  2. Label aliasing

Label-value agreement specifies how the label needs to change to accommodate differences in values associated with the label.  The most common example is pluralizing a label, though sometimes the label reads better when the entire label wording changes: for example, one person changes into two people. Some developers squawk at the extra effort required for such label changes, and copywriters lacking an understanding of variables have defaulted to work-arounds that avoid using words that trigger agreement changes. But as personalized, dynamic content becomes more ubiquitous, it is important to build the capability to have labels adapt dynamically with changes in value. Although English is less complex than some languages when it comes to rules for pluralization, it does have numerous special cases: words ending in -o, ending in -y, or ending in -f, proper nouns, and compound nouns. Rather than try to develop a complex rule set to generate plurals imperatively, it is easier to approach the problem declaratively by stating that content should display the proper singular or plural form of a countable noun, and supply the exact wording for each.

Another dimension is how labels may need to adapt to time. For labels involving status-related verbs, the wording needs to change dynamically according to the period of time specified. Differences between past tense and past particle need to be indicated. “You gave $100 in 2012” needs to be rewritten “You have given $200 since 2012” when the user changes her query.  This example highlights how labels themselves can be interactive elements.

Aliases are necessary when an attribute needs to be referred to by different names in different contexts. While consistent labeling is beneficial for helping people learn and understand quickly what you say, rigidly consistent labels are often a hindrance. Adaptive content implies that content labels should adapt to different contexts. The same value, representing the same attribute may be used in many different contexts, and needs to be referred to in slightly different ways. The most obvious example is the limited space on a small mobile device: even if a longer label might be ideal, such a label would interfere with the presentation of content. Tables often use short labels or even abbreviations. Labels adapt not only to space constraints, but also to address the degree of potential ambiguity. Labels for commonly recurring variables can be shorter, as they will be familiar.

Alias names used may be longer or shorter or abbreviated, and may be more formal or less formal.  For example, a label saying “vehicle” is shorter, but more formal, than one saying “cars and trucks.” Consider the scope in which a variable will appear, and develop appropriate alias options for different content types.

Inter-relationships

The three elements of variables — labels, values, and context — work in concert. How something is labeled can depend on its value and the context in which it appears. Dynamic, mutable values are often likely to be behaviorally framed, considering the context of who is viewing the variable, or changing according to a when the variable is viewed.  Such mutable values also need to have labels that agree with the values presented.

There are many more dimensions to content variables, particularly prioritization of content and the dynamics of whether to show variables, or not, depending on audience behaviors — issues of sequencing and level of detail. In practice, personalization is accomplished through how a collection of variables are presented together.

Because the topic of content variables is not well-developed, it is especially tricky to get the terminology right, making it understandable to content creators and software developers alike. I’ve tried my best to avoid existing jargon that carries diverse meaning or no meaning to different stakeholders.  I would welcome suggestions for improvements.

— Michael Andrews

The Benefits of Hacking Your Own Content

How can content strategy help organizations break down the silos that bottle up their content?  The first move may be to encourage organizations to hack their own content.

Silos are the villains of content strategists. To slay the villain, the hero or heroine must follow three steps to enlightenment:

  1. Transcend organizational silos that hinder the coordination and execution of content
  2. Adopt an omnichannel approach that provides customers with content wherever and however they need it, so that they aren’t hostage to incoherent internal organizational processes and separately managed channels that fragment their journey and experience
  3. Reuse content across the organization to achieve a more cost-effective and revenue-enhancing utilization of content

The path that connects these steps is structured content. Each of these rationales is a powerful argument to change fractured activities.  Taken together, they form a compelling motivation to de-silo content.

“Content silo trap: Situation created by authors working in isolation from other authors within the organization. Walls are erected among content areas and even with in content areas, which leads to content being created and recreated and recreated, often with changes or differences in each iteration.”  Ann Rockley and Charles Cooper in Managing Enterprise Content: Unified Content Strategy.

The definition of a content silo trap emphasizes the duplication of effort.  But the problems can manifest in other ways.  When groups don’t share content with each other, it results in a content situation that divides the haves and the have-nots.  Those who must create content with finite resources need to prioritize what content to create.  They may forego providing their target audiences with content relating to a facet of a topic, if it involves more work than the staff available can handle.  Often organizational units devote most of their time to revising existing content rather than creating new content, so what they offer to audiences is highly dependent on what they already have.  Even when it seems like a good idea to incorporate content related to one’s own area of responsibility that’s being used elsewhere, it can be difficult to get it in a timely manner.  It may not be clear if it is be worth the effort to re-produce this content oneself.

What Silos Look Like from the Inside

Let’s imagine a fictional company that serves two kinds of customers: consumers, and businesses.  The products that the firm offers to consumers and businesses are nearly identical, but are packaged differently, with slightly different prices, sales channels, warranties, etc.  Importantly, the consumer and B2B businesses are run as separate operating units, each responsible for their own expenses and revenues.  The consumer unit has a higher profit margin and is growing faster, and decided a couple of years ago to upgrade its CMS to a new system that’s not compatible with the legacy system the entire company had used.  The B2B division is still on the old CMS, hoping to upgrade in the near future.

A while ago, a product manager in the B2B division asked her counterpart in the consumer division if she’d be able to get some of the punchy creative copy that the consumer division’s digital agency was producing.  It seemed like it could enhance the attractiveness of the B2B offering as well.   Obviously only parts were relevant, but the product manager asked to receive the consumer product copy as it was being produced, so it could be incorporated into the B2B product pages.  After some discussion, the consumer division product manager realized that sharing the content involved too much work for his team.  It would suck up valuable time from his staff, and hinder his team’s ability to meet its objectives.  In fact, making the effort to do the laborious work of sending each item of content on a regular basis wouldn’t bring any tangible benefit to his team’s performance metrics.

This scenario may seem like a caricature of a dysfunctional company.  But many firms face these kinds of internal frictions, even if the most prevalent cases happen more subtly.

Many organizations know on a visceral level that silos are a burden and hinder their capability to serve customers and grow revenues. But they may not have a vivid understanding of what specific frictions exist, and the costs associated with these frictions. Sometimes they’ve outlined a generic high-level business case for adopting structured content across their organization that talks in terms of big themes such as delivery to mobile devices and personalization.  But they often don’t have a granular understanding of what exact content to prioritize for structuring.

The Dilemma of Moving to Structured Content

Many organizations that try to adopt structured content in a wholesale manner find the process more involved than they anticipated.  It can be complex and time-consuming, involving much organizational process change, and can seem to jeopardize their ability to meet other, more immediate goals.  Some early, earnest attempts at structured content failed, when the enthusiasm for a game-changing future collided with the enormity of the task.  De-siloing projects also run the risk of being ruthlessly de-scoped and scaled-back, to the point where the original goal looses its potency.  When the effort involved comes to the foreground, the benefits may seem abstract and distant, receding to the background. Consultant Joe Pairman speaks about “structured content management project failure” as a problem that arises when the expectations driving the effort are fuzzy.

Achieving a unified content strategy based on coordinated, structured content involves a fundamental dilemma.  Firms  with the most organizational complexity and that stand to benefit most are the ones that have the most silos to overcome.  They frequently have the most difficulty transitioning to a unified structured content approach.  The more diverse your content, the more challenging it is to do a total redesign of it based on modular components.

“The big bang approach can be difficult,” Rebecca Schneider, President of Azzard Consulting, noted during the panel discussion [at the Content Strategy Applied conference]. “But small successes can yield broad results,”  according to a Content Science blog post

Content Hacking as an Alternative to Wholesale Restructuring

If wholesale content restructuring is difficult to do quickly in a complex organization, what is the alternative?  One approach is to borrow ideas from the Create Once, Publish Everywhere (COPE) paradigm by using APIs to get content to more places.

Over the past two years, a number of new tools have emerged that make shifting content easier.  First, there are simple web scraping tools, some browser-based, that can lift content from sections of a page.  Second, there are build-your-own API services such as IFTTT and Zapier that require little or no programming knowledge.

Particularly interesting are newer services such as Import.IO and Kimono that combine web scraping with API creation.  Both these services suggest that programming is not required, though the services of a competent developer are useful to get their full benefits.  Whereas previously developers needed to hand-code using say, PHP, to scrape a web page, and then translate these results into an API, now much of this background work can be done by third party services.  That means that scraping and republishing content is now easier, faster and cheaper.  This opens new applications.

Screenshots of kimono
Screenshots of Kimono (via Kimono Labs)

Lowering the Barriers to Sharing Content

The goal for the B2B division product manager is to be able to reuse content from the consumer division without having to rely on that division’s staff, or on access to their systems.  Ideally, she wants to be able to scrape the parts she needs, and insert them in her content.  Tools that combine web scraping and API creation can help.

Generic process of web scraping/content extraction and API tools
Generic process of web scraping/content extraction and API tools

The process for scraping content involves highlighting sections of pages you want to scrape, labeling these sections, then training the scraper to identify the same sorts of items on related pages you want to scrape.  The results are stored in a simple database table.  These results are then available to an API that can be created to pull elements and insert them onto other pages.  The training can sometimes be fiddly, depending on the original content characteristics.  But once the content is scraped, it can be filtered and otherwise refined (such as given a defined data type) before republishing.  The API can specify what content to use and its source in a range of coding languages compatible with different content delivery set-ups.

The scrape + API approach mimics some of the behavior of structured content.  The party needing the content identifies what they need, and essentially tags it.  They define the meaning of specific elements.   (The machine learning in the background still needs the original source to have some recognizable, repeating markup or layout to learn the elements to scrape, even if it doesn’t yet know what the elements represent.)

While a common use case would be scraping content from another organizational unit, it might also have applications to reuse content within one’s own organizational unit.  If a unit publishing content doesn’t have well-defined content themselves, they are likely having trouble reusing their own content in different contexts.  They may want to reuse elements for content that address different stages of a customer journey, or different audience variations.

Benefits of Content Hacking

This approach can benefit a party that needs to use content published elsewhere in the organization.  It can help bridge organizational silos, technical silos, and channel silos that customers encounter when accessing content.  The approach can even be used to jump across the boundaries that separate different firms.  The creators of Import.IO, for example, are targeting app developers who make price comparison apps.  While scraping and republishing other firms’ content without permission may not be welcomed, there could be cases where two firms agree to share content as part of a joint business project, and a scraping + API approach could be a quick and pragmatic way to amplify a common message.

As a fast, cheap, and dirty method, the scrape + API approach excels at highlighting what content problems need to be solved in a more rigorous way, with true content structuring and a common, well-defined governance process.  One of the biggest hurdles to adopting a unified, structured approach to content is knowing where to start, and knowing what the real value of the effort will be.  By prototyping content reuse through a scrape + API approach, organizations can get tangible data on the potential scope and utilization of content elements.  APIs make it possible for content elements to be sprinkled in different contexts.  One can test if content additions enhance outcomes: for example, driving more conversions. One can A/B test content with and without different elements to learn their value to different segments in different scenarios.

Ultimately, prototyping content reuse can provide a mapping of what elements should be structured, and prioritize when to do that.  It can identify use cases where content reuse (and supporting content structure) is needed, which can be associated with specific audience segments (revenue-generating customers) and internal organizational sponsors (product owners).

Why Content Hacking is a Tactic and not a Strategy

If content hacking sounds easy, then why bother with a more methodical and time-consuming approach to formal content structuring?  The answer is that though content hacking may provide short-term benefits, it can be brittle — it’s a duct tape fix.  Relying on it too much can eventually cause issues.  It’s not a best practice: it’s a tactic, a way to use “lean” thinking to cut through the Gordian knot of siloed content.

Content hacking may not be efficient for content that needs frequent, quick revision, since it needs to go through extra steps of being scraped and stored. It also may not be efficient if multiple parties need the same content but want to do different things with the content — a single API might not serve all stakeholder needs.  Unlike semantically structured content, scraped content doesn’t enable semantic manipulation, such as the advanced application of business logic against metadata, or detailed analytics tracking of semantic entities. And importantly, even a duck tape approach requires coordination between the content producer and the person who reuses the content, so that the party reusing content doesn’t get an unwelcome surprise concerning the nature and timing of content available.

But as a tactic, content hacking may provide the needed proof of value for content reuse to get your organization to embark on dismantling silos and embracing a unified approach.

— Michael Andrews