Dude, where does my data go?

Editor's Notes

• #2: DO NOT REMOVE THIS SLIDE
• #4: 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
• #5: 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
• #6: …not actually writing any code at all…
• #7: …and using up a lot of stationery (thank you, Sitecore), in search of brief moments of clarity…
• #8: ... 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
• #9: “Can Sitecore do…”
• #10: 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.
• #11: 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
• #12: 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
• #13: 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?
• #14: 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
• #15: For each type of data, we must consider – what are my options in the context of Sitecore?
• #16: What’s the best option for this type of data, in this business scenario?
• #17: And why – from the point of view of everyone involved in your project, from UX through to the users.
• #18: Let’s kick off with site content.
• #19: What’s so complicated about that, exactly? Training suggests that it’s easy.
• #20: Create some data templates.
• #21: Assign some presentation details.
• #22: And you’re done – and yes, setting up a single-page campaign site in Sitecore can be that easy.
• #23: 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.
• #24: 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:
• #25: Depending on your business requirements, this can get pretty crazy, pretty quickly.
• #26: 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
• #27: Needless to say, when UX hands us this…
• #28: …we think this.
• #30: 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 …
• #31: … 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.
• #32: Let me share some True Life Stories with you.
• #33: 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
• #34: What about using one tree for everything and filtering by meta data?
• #35: Here are 3 versions of the IIS topic.
• #36: Each one is tagged with a ‘to’ and ‘from’ version
• #37: We filter with a query string, and possibly rewrite that into a nice URL.
• #38: 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.
• #39: OK – could we use events? How about replicating our actions across trees!
• #40: 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.
• #41: We could set up some kind of ‘maintain inheritance’ checkbox, and make sure an item knew who its predecessor was.
• #42: If I change the title in one location, it changes somewhere else.
• #43: 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.
• #44: 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.
• #45: We have a structure in one folder, and the content in another folder.
• #46: 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!
• #47: 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.
• #48: 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.
• #49: Until finally, we thought – what about link items? And I want to thank the many consultants, Sitecore and not Sitecore, for helping us out.
• #57: …that not all your content has to be stored in Sitecore.
• #80: DO NOT REMOVE THIS SLIDE