The 17:10 presentation at SUGCON - a mixture of comic relief and hard-earned Sitecore experience: where should your data go, does it need to be stored in Sitecore, and why?
3. > Hi, my name is Martina
• Technical Consulting Engineer
• Community Super-Fan
• Ecosystem Websites
• Team LST in Dnepropetrovsk
• dev, doc, kb, marketplace,
community, sdn
13. > Let’s talk about data
• Site content
• Pages, labels, buttons
• User-contributed content
• Comments, blog posts
• User data
• Name, address, favourite cheese
• Commerce, media, print, and beyond
22. > Lol, no.
• Custom URL structure and SEO
• Performance
• Maintainability
• Search and indexing
• Content re-use
• Content specialization
• Navigation title vs <h1> vs <title>
• Summary vs tagline vs content vs abstract
25. > OK, let’s get crazy
• Test form labels
• Test button text
• Personalize introductory paragraphs
• Personalize headings
The problem with datasources…
Martin Davies, Kagool
62. > Options
• Write directly to master
• Item Web API
• Sitecore.Services.Client
• Custom API
• Sitecore database with a twist
• Copy of a Sitecore database (web content)
• With data provider
• Custom database
• Not even a database!
• Write to index
• Disqus
65. > Hey, I’ve got a community!
• Engaged community
• Searchable content
• One forum thread per documentation topic
• ID/GUID link
• FxM and xDB to stalk you
• Special Feedback Champion Unicorn award?!
Hi, my name is Martina
I am a technical consulting engineer at Sitecore, in a team that helps clients and partners with whatever they need help with, and producing content as a by-product
Over the past year, I have also become part of Team LST of Dnepropretrovsk, Ukraine, and together we work to bring you such dev, doc, and most recently – community.sitecore.net
In my case, being a technical consulting engineer means spending a lot of time being a n00b
I’ve been a SPEAK n00b, MVC n00b, and more recently an xDB session state n00b
Combined with the work I do with the LST team managing 8 sites with various stakeholder and visitor needs, it means I spend a lot of time looking like this
…not actually writing any code at all…
…and using up a lot of stationery (thank you, Sitecore), in search of brief moments of clarity…
... usually result in furious blog-writing or backlog-rearranging – to bring you such tales of learning as SPEAK for n00bs or MVC for beginners
Spending this much time pondering Sitecore and how to use it means that whenever you so much as sense that a question is going to start with
“Can Sitecore do…”
My answer is always – yes. Whatever you’re about to ask me, I can pretty much guarantee you that I can make Sitecore do that.
You want a pipeline that checks the phase of the moon and appends Gollum’s catch-phrase to every single URL if it’s full? Done.
The point I want to make – and there is one – I promise – is that Sitecore is infinitely extensible
You have specific requirements for how URLs should be rendered? No problem, Good Guy Sitecore has got your back.
But that same quality has the capacity to make it a real Scumbag Steve – you can make Sitecore do anything, and it won’t stop you…but should you?
This particularly affect’s your application’s data structure, hence my title – and daily question to myself
Something I ask myself pretty much every time – especially after being burned by some poor decisions on my part – is dude, where does my data go?
Let’s talk about data. What do I mean by data? I mean pretty much all content.
That could be site content, which all of us deal with – your pages, labels, buttons, banners
That could be user-contributed content – like comments, or blog posts
That could be user data, like your name, address, or favourite cheese
Going further, there’s also more specialized data – like commerce and media
For each type of data, we must consider – what are my options in the context of Sitecore?
What’s the best option for this type of data, in this business scenario?
And why – from the point of view of everyone involved in your project, from UX through to the users.
Let’s kick off with site content.
What’s so complicated about that, exactly? Training suggests that it’s easy.
Create some data templates.
Assign some presentation details.
And you’re done – and yes, setting up a single-page campaign site in Sitecore can be that easy.
But usually, as many of us know first hand, it’s never that easy.
We have to think about how or decisions affect URL structure and SEO – not just now, but in the future.
Are we building something that’s maintainable?
And specific to data – what can be re-used, and what should? My favourite scenario is navigation titles and taglines. Often I end up with six different summaries to account for different lengths, tone, and business purposes. I think my UX buddy would murder me if I simply took one text field an cropped it to different lengths and added an ellipsis to the end.
For Sitecore’s in particular, we must always be mindful of personalization and content testing – both of which rely on adequately componentized data and presentation.
Or, for short:
Depending on your business requirements, this can get pretty crazy, pretty quickly.
Imagine you run an e-commerce site – you need to test every single form label, and there are twenty of them
Each one is a component, each one takes a datasource – you end up with itty bitty pieces of content everywhere
Sound ridiculous? It isn’t – that is a real scenario
You can join in the conversation on Martin Davies’ blog about real life uses of datasources, and some of the challenges
Needless to say, when UX hands us this…
…we think this.
My homepages often have a single, lonely little title field – and all other data comes from elsewhere in the tree, whether that’s abstract content items or other ‘page’ items
Working with Sitecore is a constant balancing act …
… between delivering business value quickly, getting the most out of Sitecore as a platform, and keeping it as simple as possible. Figuring out how to go from wireframe to data structure in Sitecore is one of the most challenging parts of that.
Let me share some True Life Stories with you.
Recently, the team and I discussed the requirements for versioning our documentation – you know, choosing between 8.0 and 8.1.
We have two distinct sets of requirements – one for visitors, and one for our writers.
Visitors need sensible URLs, and for SEO purposes, we want our most recent version on a canonical URL
And since some content is relevant across versions of Sitecore, we need to keep duplication of their work to a minimum – write something once, use it four times
Here’s a look at our thought process
What about using one tree for everything and filtering by meta data?
Here are 3 versions of the IIS topic.
Each one is tagged with a ‘to’ and ‘from’ version
We filter with a query string, and possibly rewrite that into a nice URL.
The verdict? No – too complicated. Sure, we’d avoided duplication, but we still had to contend with URL rewrites, weird item names, and a tree that simply would not scale. Nope – next.
OK – could we use events? How about replicating our actions across trees!
Let’s say we have these two trees. The content has not changed between those two versions, so updates to ‘testing’ in one location updates the other.
We could set up some kind of ‘maintain inheritance’ checkbox, and make sure an item knew who its predecessor was.
If I change the title in one location, it changes somewhere else.
OK, looking a bit better… I like that we’re allowing Sitecore to do the hard work with our URLs, but anticipating all actions and exceptions to those actions… nightmare. No. Let’s see what else there is.
Can we do anything with pipelines, the extensibility gold dust of Sitecore… and maybe publishing? Let’s separate out our two areas of concerns – we’ll let the writes do whatever they want, and worry about structure separately.
We have a structure in one folder, and the content in another folder.
On each topic, we’ll tag it, and make sure it knows where it belongs in the tree.
Then, on PUBLISH, we’ll work out where each item goes!
All the hard work is done at publish. We get clean trees, no customization apart from the publishing pipeline, and the writers can work in a more unstructured manner and take advantage of a bucket for search.
OK, we’re getting there! But… the more I thought about it, the more the idea of editing the publishing pipeline struck me as A Lot Of Hard Work, and potentially a maintenance nightmare. So we ploughed on.
Until finally, we thought – what about link items? And I want to thank the many consultants, Sitecore and not Sitecore, for helping us out.
…that not all your content has to be stored in Sitecore.