Architecting your Content for the Unknown Consumer

TM

Architecting your Content for the Unknown Consumer

19.10.16

Richard Jones, Technical Director@richardjones @inviqaDigital Publishing Innovation Summit, London 2016

Your customer’s behaviour is changing faster than you are

TM

#DigiPub @richardjones @inviqa

You need to keep pace with requirements you may not

even be aware of

TM


Being PreparedWhy today’s web is unpredictable What’s likely to change How you can be ready now


The Known Consumer

Anything you are testing for Assume everything else is unknown

“Internet of Things”


Defining the IoTHeadline devices Smart Refrigerators Household domestic appliances

Beyond the headlinesMedia Advertising Billboards

Beyond the headlinesEnvironmental monitoring Infrastructure management Manufacturing Energy Management Medical and Healthcare

Consumer Wearable Quantified Self Smart Retail

Beyond the headlines

5.5 million new things get connected to the internet each day

(Gartner)

How many of these are content consumers?

Vodafone: Store kiosks driven

from central content repository

Amazon Echo: A revolutionary

content consumer

Some future gazing…


Some content dates quickly

What if you could correct at source?

Could content save a life?

A Smart device could check for itself if it had been recalled

Always up to date

A self driving car could consume many types of content to improve its abilities

How we present this data is the key


Software is not good at interpreting meaning


Unstructured vs Structured Data


Use of structured data for other purposes


How do we support these unknown consumers?


Many people still think in the “page” model Pages may have semantic elements At best these are signals for interpretation

The Web as Pages


We need a Content Management System to allow us to move beyond “page” thinking

Beyond the page


Content model and structure Delivery / Access mechanism

Essential ingredients


Content creators need to think beyond pages Relinquish control of layout Challenging the status quo

Challenges


A debate well covered elsewhere aka Battle for the Body Field A conversation that is still ongoing

Blobs vs Chunks


Also a well covered topic Very relevant to our scenarios The use case for context specific content is valid here

Adaptive vs Responsive


Do we want to?


Open Data Paid API access Metered API access

Business Models


Value added service Offer content in a usable format

Business Models


Is “naked” content the alternative in the age of the Ad Blocker?


How do we get there?

Structure the content model Expose content using a documented API

Steps to Prepare


Conceptually can start quite simple Complexity tends to escalate as you work through the relationships

The Content Model


Example

Article

•Headline •Body •Image



Content Model theory


Object Oriented Programming Well understood in the computer science world Some principles could be applied to content modelling

Comparing to OOP


Objects which may contain data in the form of fields Code in the form of methods Single responsibility principle

Definition


A content type should be as simple as possible It should be for one purpose only Do not assume dependencies that may not be present A field should have one clear purpose

Loose interpretation


Content Modelling Antipatterns


Content Antipattern #1 Non-content content


Content types that provide nothing in isolation “Signposts”, “Jumps”, “Shortcuts”

Non-Content Content


Instead use alternative views of the referenced content: e.g. Teasers, List view

Non-Content Content



Content Antipattern #2 Godzilla Content Type


Content Antipattern #2 Godzilla Content Type

Multiple use cases Violates the single responsibility Reluctance to have multiple content types leads to a monster content type

Godzilla Content Type


Multiple use cases Violates the single responsibility Reluctance to have multiple content types leads to a monster content type



Instead: Don’t be afraid to have more smaller content types Consider relationships Think carefully about single responsibility



Content Antipattern #3 Field Ambiguity


Using a field name that doesn’t make immediate sense to the editor Fields that are used for different things in difference scenarios Lead to loss of structure

Field Ambiguity


Instead: Agree clear naming with all content stakeholders Create clear guidelines / help text.

Field Ambiguity


Content Antipattern #4 Using Content for Logic


Fields that are not really content Designed to affect the layout of the “page” via template logic

Logic Fields


Don’t mix layout with content The application theme layer can handle this for you.

Logic Fields


What Next?


Use a CMS with a good Content Model Toolset


Educate Stakeholders regarding the benefits of structured content


Split content from design


Handle creative objections early


Spend time on the content model


Allow more time than you think you need Focus on the future - and abstract Simplify the design - leave no room for interpretation Consistency of fields - eg date formats

Content Model


Think through all possible relationships Break content into the smallest possible pieces Hold the smallest amount of formatting possible

Content Model


Future proof your content


Future proof your content

Prepare your content for the future


Ensure portability


Embrace the unknown and create a legacy


TM

Questions?

Richard Jones Technical Director Inviqa @richardjones @inviqa

TM

Business first
