Andrew Whitehead, Creative and Managing Director at Devotion presents real-world use cases of using Kentico Cloud for their projects.
Andrew uncovers 5 reasons he sees in using headless CMS:
- Flexibility
- Accessibility
- Control
- Speed
- Creativity
3. So, why am I up here?
#2
The lovely folk at Kentico
asked me!
#1
To provide an agency's real-world
perspective on using Kentico Cloud.
4. To give some credibility - completed projects.
Wine Australia
website
Devotion
website
Sekisui House
live auction platform
Why Kentico Cloud: streamline the
content development process.
Why Kentico Cloud: speed-to-market
and availability of resource.
Why Kentico Cloud: isolate content
within a bespoke application.
5. To give some credibility - in-progress projects.
Environmental cleaning
solutions website
Health fund
mobile application
Construction management
website
Why Kentico Cloud: budget and
creative requirements.
Why Kentico Cloud: multi-
platform content serving.
Why Kentico Cloud: limited
requirements.
7. In plain English, a headless CMS is…
...a content hub that pushes your content to multiple devices in any format
you wish. Traditional CMS platforms require you to think about page
layouts, custom code, security, scalability, and performance. However, a
headless CMS focuses your attention on the content.
8. As agencies, we usually ask what’s in it for us?
Why change what’s already working?
9. Simple.
Additional revenue streams - lower budget projects = less getting bogged-down.
Embrace the resurgence of brochureware.
Seamlessly manage multi-channel content.
Change our resource dependencies (roadblocks).
Rapidly deliver solutions - both longterm and short lifespan.
Constantly iterate the front-end with no impact to the CMS.
Remain fresh - keep our team engaged.
11. 1. Use any programming language.
2. Use your own process, or create a new one.
3. Retain staff longer - devs love using the latest technology.
4. Get developers up and running quicker as there is little onboarding.
5. The intended experience is not constrained (or dictated) by the CMS.
12. Devotion website.
● 2 weeks start to finish
● Front-end built in Vue.js
● Content entry prior to
front-end build
14. 1. Make content accessible to any channel or device via the API - think
web, mobile, kiosks, wearables, digital experiences etc.
2. Innovate and try new things as you’re delivering content components,
not pages.
3. Meet the needs of many customer scenarios - not aligned to one
vertical or segment of the market.
15. Big health fund application
(in development).
● Built using React Native
● Data provided by ERP
API
● Content provided by
Kentico Cloud
17. 1. Separate content (and its management) from its presentation.
2. Remove availability, security, performance, upgrade, and backup
concerns, as these belong to Kentico (the vendor) - simply control the
website or application.
3. Let people focus on what they’re good at - set your frontends free from
the structures of backend - eliminate “div-itis”.
4. Redesign your site without re-implementing the CMS.
5. Enable flexible workflows for different processes: reviews, approvals,
archiving, translation.
18. Sekisui House
live auction platform.
● $20 million auction
● 7 days development
● Content written and
entered in parallel
● 1000+ concurrent users
20. 1. Deliver things much quicker - agency teams can work simultaneously.
2. Remove bottlenecks/barriers that traditionally exist.
3. Deliver solutions that are fast.
4. Shift display logic to client-side and streamline the backend - leading to
increased responsiveness.
5. Backend becomes system of record - interaction happens real-time in
the browser.
21. Wine Australia.
● Used for ‘draft’ content
preparation while site
being built on Kentico
EMS (staged across)
● 3 months saved on
content creation
● 1700+ content items
written and reviewed
● Complex workflows
23. 1. Content/experience comes first.
2. As the content is separated from the technology, it’s easy to go
‘beyond the website’ and open up a whole new world of content-
managed, and integrated (or centralised) experiences.
3. Multiple frontends can peacefully coexist.
24. Environmental cleaning
solutions website.
● Brochureware with
complex frontend design
● Budget didn’t allow for
Kentico CMS
● Client entering all content
now (ahead of frontend)
25. So, to summarise...
Kentico Cloud is not Kentico CMS/EMS - be selective.
Think speed to market.
Look to add additional revenue streams.
Use the awesome Kentico support team.
Get creative - don’t be constrained by the platform you currently use.
Embrace simplicity - no infrastructure concerns.
27. Visit us
Level 1, 168 Oxford Street
Paddington NSW 2021
Australia
Contact us
+61 2 9356 7900
hello@devotion.com.au
See what we’re up to
www.devotion.com.au
Thank you.
Notes de l'éditeur
Hello…
You’re going to see some fantastic colourful presso’s today, so I’m setting the initial benchmark as low-fi with little colour.
Probably should scratch the ‘creative’ from my job title as punishment for this!
- - -
Why did Adele cross the road?
To say hello from the other side.
What do you call a singing computer?
Adele
Let’s set some context…
Quick show of hands:
How many people in the audience are agency folk?
How many are end users / clients?
if you are a client, look out, because you’re going to be popular
This is not a sales pitch.
It’s meant as an insight into some of the conversations we’ve had, and question we’ve asked when starting out with Kentico Cloud.
The interesting thing to note is that each reason for choosing Cloud was different
The interesting thing to note is that each reason for choosing Cloud was different
It’s important to remember that this is about a headless CMS, not a full-blown CMS. We haven’t done away with Kentico CMS/EMS, but rather been able to offer it as a new product/service.
Other people will go into detail today on the intricacies of what headless is, how it plays alongside the existing platforms and so forth, so I won’t go into too much detail now, but what I will say, is that it’s been important for us as an agency, to identify the right opportunities for Cloud…
Mobile apps
Rich web apps, custom layouts and frameworks that don’t fit with content being tightly controlled
Ecosystems of apps and websites where same content gets published in many places
But, we’ll get to the reasons...
I’m preaching to people who already know, but trust me, getting the plain English right around this has helped us with clients (and even internally).
Obviously still concerned about security, scalability, and performance, but these are inherently taken care of.
Why invest in something new, if we’re still capitalising well on the incumbent?
Why move to something with reduced functionality and reduced ‘upside’?
Why cannibalize the strength of the existing offering?
React
AngularJS
Vue.js
MVC Core
Why flexible:
Used whatever language we wanted (happy front-end devs) - Vue.js
Simultaneous process - design, content, and front-end happening together
Why Accessibile:
Content available to any device
Why control:
Separate the content (client very particular) from the bespoke MVC Core backend
Separation was important because of the tight deadline of 7-days
Load tested to 5000 concurrent users
Why speed:
Saved 3 months of content entry in EMS
virtual reality
digital assistants
Wearables
internet of things
… or anything else your creativity allows.
Why creativity:
Designers allowed to push the boundaries (for a low budget project) where usually they would have been reigned in
Choose the correct opportunities
Hello…
You’re going to see some fantastic colourful presso’s today, so I’m setting the initial benchmark as low-fi with little colour.
Probably should scratch the ‘creative’ from my job title as punishment for this!
- - -
Why did Adele cross the road?
To say hello from the other side.
What do you call a singing computer?
Adele