Successfully reported this slideshow.

Dude, where does my data go?

2

Share

Upcoming SlideShare
Google Is a Two Page Site
Google Is a Two Page Site
Loading in …3
×
1 of 79
1 of 79

Dude, where does my data go?

2

Share

Download to read offline

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?

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?

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Dude, where does my data go?

  1. 1. Dude, where does my data go? Martina Welander Sitecore @mhwelander Sitecore User Group Conference 2015 1
  2. 2. Sitecore User Group Conference 2015 2
  3. 3. > Hi, my name is Martina • Technical Consulting Engineer • Community Super-Fan • Ecosystem Websites • Team LST in Dnepropetrovsk • dev, doc, kb, marketplace, community, sdn
  4. 4. Not mine, too fancy
  5. 5. "Can Sitecore–"
  6. 6. "Let me stop you there. Yes. Whatever you’re about to ask – yes, I can make Sitecore do that."
  7. 7. + /products-my-precious
  8. 8. much extend such flexible wow
  9. 9. Dude, where does my data go?
  10. 10. > 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
  11. 11. What are my options?
  12. 12. …what’s the best option?
  13. 13. (WH)Y?
  14. 14. Site content
  15. 15. What’s so complicated about that?
  16. 16. > 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
  17. 17. Personalization & Content Testing
  18. 18. > OK, let’s get crazy • Test form labels • Test button text • Personalize introductory paragraphs • Personalize headings The problem with datasources… Martin Davies, Kagool
  19. 19. > Page Title: The Loneliest Field
  20. 20. Example Sitecore Documentation Versioning
  21. 21. Business Requirements Visitors • http://doc.sitecore.net/sitecore-xp/8-1/ • Stable URL for latest version – http://doc.sitecore.net/sitecore-xp Writers • No duplication for writers • Update, delete, move, rename across versions • Update-specific exceptions
  22. 22. Option #1 Single tree, filter by meta data
  23. 23. Verdict Pros • No duplication Cons • URL rewrites • Sad Google • Complex tree, does not scale
  24. 24. Option #2 Replicate edits <events>
  25. 25. Verdict Pros • Automatic duplication • Version-specific presentation • Nice URLs Cons • Anticipating all actions and exceptions • CM performance
  26. 26. Option #3 Publish to structure <pipelines>
  27. 27. master
  28. 28. web
  29. 29. Verdict Pros • Nice URLs • Publishing does the work • No duplication Cons • Complex pipeline • Complex structure tree • No presentation variation
  30. 30. Option #4 Link items
  31. 31. Verdict Pros • Nice URLs, minimal rewrites • No topic content duplication • Minimal customization, maximum flexibility • Editor experience • Bonus testing capabilities! Test topic-1 vs topic-2 content
  32. 32. User-contributed content
  33. 33. > What do I get from Sitecore? • Workflow and security • Content re-use • Translation • Testing • Personalization • Tagging
  34. 34. Access to master database
  35. 35. Publishing clears cache
  36. 36. > 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
  37. 37. Off the top of my head…
  38. 38. > 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?!
  39. 39. Like a sir lady
  40. 40. User data
  41. 41. > xDB • Highly extensible • MongoDB / JSON • Data that enhances the experience (not passwords!) • Extend with facets • Surface in reporting
  42. 42. > Security! • Firewall / DMZ • HTTPS • OnPrem vs Cloud – insurance, finance
  43. 43. > Sensitive data questions?
  44. 44. And beyond…
  45. 45. > Media • Database • File system • DAM / CDN
  46. 46. > Commerce • Sitecore Commerce powered by.. • Dynamics • Commerce Server • uCommerce • Insite • Active Commerce
  47. 47. > Print Collateral • Print Experience Manager
  48. 48. > Hi, my name is (still) Martina • @mhwelander • mhwelander.net for blawgs • community.sitecore.net • sitecorelst.tumblr.com
  49. 49. Thank you Sitecore User Group Conference 2015 79

Editor's Notes

  • DO NOT REMOVE THIS SLIDE
  • 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.
  • DO NOT REMOVE THIS SLIDE
  • ×