With the event being remote the last two years it was nice to finally reconvene as a community. This year, they chose one of my favorite European cities – Budapest!
I was lucky enough to attend in person again, joined by Velir colleagues current and former MVPs Dan Solovay, Daniel Delay, and Chris Sulham. There were approximately 500+ attendees largely made up of MVPs, developers, savvy clients, a Sitecore reps.
Why did we attend?
Over the past few years, Sitecore has moved away from its home-grown, self-contained platform and began acquiring products that would help speed their transition to a cloud-native platform that is more composable in terms of features and functions.
For many of us, this was a massive paradigm shift and one that left many of us feeling a bit unsure what we do and don’t know about the solution and its direction. We went to SUGCON seeking some answers.
What did we learn?
Sitecore’s CEO, Steve Tzikakis, kicked off the show.
Doubled R&D spend over next 4 years (22%)
Focus is firmly on strategy and building out the composable DXP
Doubled the number of employees across the organization – 60% of staff have only been at Sitecore a year or less!
Widening presence with offices like Boston and Dubai
The affirmation that “We will always be a CMS solution”
Commerce is being totally redefined
Sitecore’s CPO, Dave O’ Flanagan followed up.
Not trying to sell customers the whole Sitecore stack but just the parts they really need
XM Cloud coming soon!
Content is still the center of gravity for the platform
Cloud native, headless by default, Jamstack ready, analytics/testing/personalization really baked in
New successor to XP is XM Cloud so the upgrade path would be here since personalization and analytics are included but for more advanced needs may need to add CDP
Sitecore search rearchitected from Reflektion to be generic
Sitecore portal coming for DXP management
All visual user interfaces will be rethought for cloud based Sitecore
Dusting off Horizon and adapting elements of it
Sitecore announced a lightweight/decoupled version of Content Hub branded “Headless CMS”. It could be an alternative CMS like Contentful or Storyblok.
Conclusions and Takeaways
Sitecore is keeping XP for now, but the big sales push from Sitecore is XP > XMP (Sitecore XM + Personalize).
Upgrade path could be complicated for clients currently on xDB and have complex personalization rules. May require starting over data-wise.
Personalization configuration will at first be less turnkey for BSAs and Digital Marketers. Requires JS code and developer involvement.
You can’t just swap component data sources in Sitecore like you can in XP right now. You need to somehow get that content over to Personalize. More like an ad server or Adobe Target.
Overlapping capabilities from the acquired products still being resolved.
Composable systems don’t have visual editor for the web or any channel so this is one of the trade-offs
This year, along with Dominic Hurst of Valtech, I was very fortunate to have presented at the Sitecore Symposium in Las Vegas, Nevada. Both Dominic and I have worked on a variety of Sitecore installations and over the years have noted some mutual industry observations:
The role of the Content Author in modern CMS solutions has evolved into a multi-dimensional job. Too often these every-day heroes have to fight inflexible and uninspiring solutions to overcome the even smallest tasks
Many organizations spend the lion’s share of their budgets on CMS implementation, yet pay little attention to the efficiency of the operational processes that enable it
Poor authoring experiences can lead to UX erosion over time. Bad AX → Bad UX → Bad CX
Content authors are rarely empowered to aid in design, personalization, and performance analysis
Together at the Symposium we decided to address these observations and present our top 10 tips for organizations to empower their content authors to deliver real value on a daily basis. Many they can enact right away. Below are links to 10 blogs posts that cover each of these points in greater detail. We hope you enjoy these posts and, of course, please reach out to either of us to continue the conversation. Dan – @sitecorelations; Dominic – @dh_analytics)
Three of the guiding principles I always keep in mind when trying to build usable systems in Sitecore are:
Reduce the number of decisions a content author has to make
Reduce the number of things that require editing in the first place
Make it easy to do the “right” thing
One of the greatest tools for ensuring that these three things are achieved are Sitecore branch templates. Branch templates allow creation of item hierarchies in a singled click using dynamic placeholders. You can instantly create complex but predictable multi-tiered structures so that an author need not recreate these manually.
A content author creating yet another news article need not see a blank slate each time when it’s likely that this content type is highly structured and will have instances of the same components in the same layout, at least as a starting point. Below are some examples of branch templates for pages that specifies a core collection of default components to be included with each new instance of the page.
This is even more useful for creating multi-tiered structures such as office microsites or any other repeated content grouping that all have the same basic hierarchy. Why have content authors doing data entry for content objects that are predictable and repeatable? This is time-consuming, prone to error, and discourages consistency. Companies tend to treat content authors time as expendable, but it’s really not when you consider the cumulative total of all of these tasks and micro-interactions with the CMS.
Leveraging branch templates requires a holistic approach to content modeling that is best done when a platform is being constructed as it requires some forethought and consensus on standardization. That said, it’s not impossible to inspect existing structures and create supporting branch templates for use moving forward. Finding ways to accelerate repetitive tasks may just improve content author morale as much as their efficiency and free them up to do higher value work!
Information architecture and system design decisions can have a major impact on the ease with which content can be created and managed in Sitecore. Authoring experience is not always front-of-mind as architects and developers are shaping a system, but this can prove short-sighted as content teams begin to build content in the system.
During recent authoring experience audits of clients’ Sitecore platforms, I have noticed one key thing negatively impacting author efficiency. Many times, local components are not grouped with their parent page. While this is common and expected for globally shared components, it’s not recommended for unique instances of components referenced only by a single page. In one such case, there was a total separation of pages and components. There was an entirely separate directory for components that mirrored the page hierarchy manually. The rationale was that it kept page objects in the tree simple and uncluttered (which was true) but the end result was that authors were pre-creating all necessary components for a page ahead of time rather that authoring a page inline in Experience Editor. Rather than simply choosing from a list of allowable components and dropping an instance on a page, the first thing the content authors were required to do was establish a link to an existing data source. This really threw a wrench in the inline editing experience and was affecting content authors impressions of Sitecore – thinking “that’s just how it works.”
To allow for greater automation and improve author efficiency, dynamically nest components locally under each page object so that pages can be more quickly constructed and fully edited inline.
Through use of branch templates and standard values, a local Components folder can house all unique instances of components applied to a page. The content author doesn’t have to spend a lot of time thinking about where they should go. It reduces the number of decisions they have to make and speeds the authoring process. If you want to get fancy, you can even include sub-folders to keep multiple instances of different kinds of components organized (e.g. multiple rich text blocks, images, or videos).
This approach also simplifies the publishing process when you want to publish all components along with a page. Since these are sub-items, this relationship is easier to deal with rather than referencing components as related items.
This is something I have had a lot of success with and as the trend towards greater componentization in WCM systems continues it’s becoming a standard approach in the platforms Velir builds.