Whilst CMS communities talk headless, the market is starting to talk CaaS (Content as a Service), in which content is created and managed independently of the place it will be consumed. CaaS becomes especially important when considering the Internet of Things or more traditional end points such as websites and mobile apps. Over time, this could mean everything from your TV or watch to your fridge. This session will look at how eZ can be used to offer CaaS by positioning it as the Digital Hub of the enterprise.
43. Object Oriented Programing
Well understood in the computer science
world
Some principles could be applied to
content modelling
Comparing to OOP
44. Objects which may contain data in the
form of fields
Code in the form of methods
Single responsibility principle
Interface segregation principle
Definition
45. 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
47. Different roles have different relationships
with the content
Engaging with all the voices helps us build
a complete content model
Content Workshops
52. Data always beats judgement
No matter how long you’ve been in the
industry
No matter how well you know your
products
Intuition is not a science
Examining Relationships
56. Content types that provide nothing in
isolation
“Signposts”, “Jumps”, “Shortcuts”
Non-Content Content
57. Instead use alternative views of the
referenced content:
e.g. Teasers, List view
Non-Content Content
58. A content type that covers multiple use
cases
Violates the single responsibility principle
Reluctance to have multiple content types
leads to a monster content type
Godzilla Content Type
59. Instead:
Don’t be afraid to have more smaller
content types
Consider relationships
Think carefully about single responsibility
Godzilla Content Type
60. 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
61. Instead: Agree clear naming with all
content stakeholders
Create clear guidelines / help text.
Field Ambiguity
62. Fields that are not really content
Designed to affect the layout of the “page”
via template logic
Logic Fields
63. Don’t mix layout with content
The application theme layer can handle
this for you.
Logic Fields
70. Allow more time that 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
71. Think through all possible relationships
Break content into the smallest possible
pieces
Hold the smallest amount of formatting
possible
Content Model