Kentico content architecture @ the Inaugural Seattle Kentico Users Group - Redtech - May 2017
•Télécharger en tant que PPTX, PDF•
3 j'aime•360 vues
Kentico content architecture: Wading through the myriad of options to produce easy-to-use, future-proof solutions.
Recommandé
Contenu connexe
Similaire à Kentico content architecture @ the Inaugural Seattle Kentico Users Group - Redtech - May 2017
Similaire à Kentico content architecture @ the Inaugural Seattle Kentico Users Group - Redtech - May 2017 (20)
Dernier
Dernier (20)
Kentico content architecture @ the Inaugural Seattle Kentico Users Group - Redtech - May 2017
- 1. Kentico Content Architecture Wading through the myriad of options to produce easy-to-use, future-proof solutions. Mike Wills, Sr. Solutions Architect
- 2. o Web parts o Widgets o Editable Web Parts o Templates o Page Types o Kentico Draft o MVC Myriad of Options o Myriad of Options
- 3. Kentico training features myriad of options
- 4. Sample sites feature myriad of web parts and widgets
- 7. Firstapproach Simple template build with zones & editable text
- 8. Firstapproach Number of web parts grows
- 9. Firstapproach Markup is spread across many web parts
- 10. More flexibility: Optional child elements
- 12. “Natural” solution, Widgets & Layouts
- 14. Firstapproach,challenges Author usability: Numerous dialogs
- 15. Firstapproach,challenges Author usability: Hidden and overlapping buttons
- 16. Firstapproach,challenges Author usability: Conflicts with page designs
- 17. Designer flexibility: Changing templates require o Matching web parts types. o Matching web part IDs. o Matching widget zones. o Matching widget IDs. o Manually updating widgets Firstapproach,challenges … or, recreating pages.
- 18. Additional limitations o Importing from Kentico Draft o Querying content for rollups, etc. o Using MVC o Ensuring data integrity Firstapproach,challenges
- 19. Is there a better way?
- 20. “This is my most favorite approach and most recommended by Kentico and any developer/partner who knows what they are doing” – Brenden Kehren, Kentico MVP Kenticocommunity “…lend itself better to using a pagetype to hold the data and a transformation to display it. …it will also fall in line with our best practices” – Matthew Sandstrom, Kentico Support “Using these tips really makes it easier for the content editor, they'll thank you for it.” – Joel Dahlin, Kentico Certified Developer Cut through the myriad of options, ask the Kentico community…
- 22. Contenttreeapproach Create custom page types to structure content
- 23. Contenttreeapproach No conflict: Author view is free of widgets, web parts & zones
- 24. Contenttreeapproach Simplicity: Pages are built with less web parts and nesting
- 25. Contenttreeapproach Simplicity: Page markup is not spread across many properties
- 26. Contenttreeapproach Flexibility: Add optional section with child content
- 27. Contenttreeapproach Flexibility: Add child, content-only sub pages
- 28. More flexibility: Mix-n-match visual elements
- 31. Contenttreeapproach Flexibility: Build content tree with typed containers & content-only pages
- 32. Contenttreeapproach Flexibility: Hierarchical Viewer is King
- 33. Content tree approach benefits
- 34. Contenttreebenefits Benefits: Easy, instructive, author experience
- 35. Contenttreebenefits Benefits: Easy, powerful design experience
- 36. Contenttreebenefits Benefits: Design flexibility, switch transformations or templates
- 37. Contenttreebenefits Benefits: Switch transformations or templates without rebuild
- 38. More benefits – Future-proof o Performance optimizations o Switch to MVC o Map data from Kentico Draft o Support mobile apps, and web services o Export your data o Less custom code, easier upgrades Contenttreebenefits
- 39. More benefits – It’s solid o Data integrity is ensured by SQL constraints o SQL Server is leveraged to ensure o Successful saves o No lost data Contenttreebenefits
- 40. More benefits – Enforce compliance o Accessibility requirements (WCAG 2.0) o Brand and design requirements o SEO optimization Contenttreebenefits
- 42. Contenttreetips Form design o Design clear type and field names o Utilize field requirements & validation o Use field descriptions & explanation text o Use field groups
- 43. Contenttreetips Create a “Page content” container for content-only pages
- 44. Contenttreetips Use Allowed Types and Scopes to guide and protect users
- 45. Contenttreetips Provide a little code, to add a lot of ease o Use document event handler o Auto create “Page content” container o Even create default content
- 46. Questions?
Notes de l'éditeur
- Points Introduction. Content architecture best practices Largely learned through the Kentico community The architectural approach takes Kentico from cool to exciting Devs love it. Authors say, “It’s so easy”
- Points Let’s try to look at Kentico through the eyes of Dev w/experience in other platforms ? How many of you came to Kentico from other platforms ? A new developer will quickly seem many familiar concepts Web parts Zones Templates Best practices for content architecture is not clear Naturally drift towards what looks familiar
- Points Kentico training provides an overview of the myriad of options ? How many of you took Kentico’s Developer Essentials? ? Recognize this? The training covers a breadth of features, doesn’t necessarily prescribe best practices. New dev can be easily led to believe that the “Kentico way” is to use Web part layouts Editable web parts Widgets
- Here’s an example of a sample site. Notice it uses editable web parts. Again, it implies this is the default approach.
- And another part the Dancing Goat sample site. It even suggests that having lots of editable web parts on a page is expected. BTW: When I was at a Kentico office, one of their consultants told me about his struggle to convince a new customer to not base their architecture on a sample site. Sample sites and training are intended to showcase features, not be a model architecture.
- Points The new dev has had a lot of exposure to editable text web parts, layouts & widgets. Building templates with these is his natural inclination because its familiar. Let’s look how this could progress.
- Points The first template is likely built with zones, and editable text web parts. Simple Understandable Works
- Points As he continues to build the template. The number of web parts and editable text web parts grow Dev might be starting to feel uncomfortable with spreading markup across many web part properties.
- Points Markup is spread across many web parts Updating the markup Finding the markup Cumbersome, unwieldly Dev might be starting to feel uncomfortable. “Is this right?”
- Points Now lets look at where the design may go if more flexibility is required What if we need even more flexibility?
- Points Provide a template that allows authors to: Add and remove sections Add one or more elements to a section This is a likely requirement from customers who want to implement pages with design components.
- Points Seems natural to allow authors to add and remove layout widgets add child widgets populate fields Notice this screenshot has a layout widget Three widgets inside it However, what if you want the whole section to be in a split layout Nest it all inside another layout widget. This approach presents immediate challenges
- Points At this point, using an editable text and widget based approach. Dev running into some problems. Editing templates is unwieldly. Let’s look at some of the challenges encountered.
- Points Author usability To edit widget properties, open dialogs If every components is a widget, maintenance becomes unwieldly
- Points Author may have trouble opening a widget’s dialog. Widget and zone buttons can overlap.
- Points Since widgets are accessed within the page design Custom page elements can interfere with accessing controls. In this screenshot, as the user brings the mouse towards the widget controls, The custom tool tip covers the controls
- Points A significant challenge is designer flexibility. You may want to apply a new design to your pages. However, Will your new templates require different webparts or widget? Do you want to put content into new markup? Do you want to change markup used as default widget values? You basically cannot change templates unless the web parts and widgets match what is in the old template. Except for very minor changes, you’ll need to recreate pages.
- Points Kentico Draft If you prepare content in Kentico Draft or GatherContent, you will not be able to map the data to editable web parts or widgets. Querying content The data in editable web parts or widgets is very difficult to reuse. If you want to display a page’s description as teaser content in a rollup, it better not be in an editable text web part. This model will not work with MVC. It requires using content-only pages. Data integrity Aware of multiple cases in which authors could not successfully save content using this model. Troubleshooting required ensuring web part IDs and GUIDs in DocumentContent XML were correct and had no collisions.
- Points By this time, a developer is probably - thinking, I like Kentico, but… - wondering if there’s a better way If he’s gone very far in this direction, changing can be difficult. Hopefully, the developer discovers that there is a best practice for content architecture.
- Points Our developer has been wading through a myriad of options Going the direction that seemed natural, but has hit numerous limitations Whole time, there is a powerful core feature of Kentico. The potential can be easily overlooked. Using this feature/approach is what MVP Brenden Kehren calls: “recommended by Kentico and any developer/partner who knows what they are doing” And “most powerful approach you can use to make your Kentico site” What is this approach? Reference Tips for Creating Page Types in Kentico http://dahlindevelopment.com/blog/july-2016/tips-for-creating-page-types-in-kentico/ Joel Dahlin 3. This is my most favorite approach and most recommended by Kentico and any developer/partner who knows what they are doing with Kentico. Kentico is built around document/page types. If you look at how the content tree and navigation are setup you'll see this approach is not much different than using a static or editable text webpart on a page. Reason I say this is because a "page" (cms.menuitem) is a page type and has essentially the same query as would a custom page type. … Creating custom page types to work with templates and shared layouts is the most powerful approach you can use to make your Kentico site. https://devnet.kentico.com/questions/webparts-vs-widgets-vs-static-html Brenden Kehren Kentico support I noticed that most of the editable text web parts in your template have HTML content before and after. The way that they are set up might actually lend itself better to using a pagetype to hold the data and a transformation to display it. This way your content editors can add the text on the Form tab and you can reference it from within a transformation. You will be able to keep all the markup in one place rather than having it spread among several web parts, and it will also fall in line with our best practices than the current setup.
- Points Anyone who’s gone through Kentico training will have learned about creating custom Page Types. However, the approach of storing all content in Page Types within the content tree may be new. It puts Kentico in a new light. The perception of the platform goes from good (or waning) to exciting. Next: Let’s look at how this approach works. We’ll start with a basic & familiar example, to more complex and flexible scenarios. If you are not a dev, pay attention, because by ensuring your site is built this approach, you’ll be able to reduce maintenance costs maintain design flexibility reduce support issues.
- Points Instead of putting Editable Text web parts on a template Create a custom Page Type for the content. Ask authors for the content needed to render pages according to Brand requirements SEO requirements Accessibility requirements
- Points Notice the page view does not include widgets, web parts or zones. No potential for button-CSS conflicts.
- Points In the design view, notice there are not many web parts, with nested child web parts Designers do not have to jump in and out of web part dialogs Instead...
- Points Most of the previous screenshot is rendered in one web part Markup is all together, easy to update, and troubleshoot
- Points So we have a way to store page-level content in a custom page type, But How do we add flexibility? How do we add child data? Seemed intuitive with zones and widgets.
- Points Store child content as content-only child pages in the content tree Same technique used for banners on the home page of the E-Commerce sample site. To edit child content, an author merely picks the desired node in the content tree to access its form. No dialogs No webpart buttons Never conflicts with custom user-interface elements I’ve heard customers say “this is so easy” Even customers who were migrating from WordPress
- Points What if we need even more flexibility? The requirements entail allowing building many pages with a variety of sections (visual building blocks). The requirements might even be communicated as the ability to use a variety of widgets. Requirements: A variety of section types Optional section types Change order of sections Multiple sub-elements Here are example snippets from a template requiring optional sections.
- Points Example of multiple section types Notice that some need to allow multiple grandchildren.
- Points Sections can be represented by simple content-only pages Or, containers that have multiple content-only pages in them Order of sections can be controlled by order of nodes Notice child-depth and flexibility isn’t making it unwieldly
- Points Alan once told me the Hierarchical Viewer is king. The Hierarchical Viewer can query the child data apply transformations by depth or type query the child-data in one round trip Theoretically, a complex template could be rendered with one Hierarchical Viewer web part.
- Points We’ve already seen a couple of benefits to the content tree approach. Much better user experience for authors And for designers too (Markup is in transformations instead of spread across properties) There are many more benefits (Serious, long-term benefits)
- Points Users love this experience. I’ve heard “It’s so easy” on multiple projects Select a node in the content tree. Update the form. Fields have: Validation Instructions
- Points Notice how much easier it is to maintain the markup. It’s all in transformations instead of web part HTML Envelope properties.
- Points A key benefit to this is approach. Data is separate from template design, and transformations Switch templates or transformations without rebuilding pages, or reentering content This is a huge, future-proof benefit
- Points Here’s the same data from the last slide, rendered with a different transformation.
- Points By using the content-tree approach, the solution is future-proof in multiple ways The data isn’t tied to using a particular web part You can completely change how the data is queried and rendered. You can access the data through the API or queries easily Benefits Options and control, support performance optimizations You can switch to MVC (not possible with editable web parts) Map data from Kentico Draft Create web services, support publishing content to mobile apps Own the data. The data can be easily exported or transferred. By using page types and transformations, you are much less likely to need custom code. Upgrades are easier
- Points Content-approach leverages custom SQL tables to store the data. Colliding or orphaned web part IDs and GUIDs are not an issue, as it can be with DocumentContent XML Changes will not be lost.
- Points Compliance is becoming more and more important At Microsoft, a web site cannot be launched without achieving high, accessibility requirements. Branding and design teams want to ensure brand compliances Marketers want SEO optimizations to be ensured With the content-tree approach: Data is validated Instructions are clear Templates and transformations are responsible for markup This makes it easy for authors, and allows compliance to be assured.
- Points We looked at what the content-tree approach is. Looked at the benefits. Now, I’d like to share some tips that will help it really pay off. Most of these tips are simple choices Big-bang for the buck.
- Points This might be obvious, but not all developers think about Organizing fields Providing clear names & descriptions Validating data entry
- Points Prevent mixing of regular pages and content-only pages For each page type, create a “Page content” container to contain its content
- Points Guide authors to pick the allowed page types Makes it easier Protects them from breaking the solution BTW: This is a much better experience than having to find the right widget in the gallery Use Allowed parent types and Allowed child types Use typed containers if needed. (Home page might have a different “Page content” type than News page) Use Scopes to limit page types to certain parts of the tree Again the goal is to hear “this is so easy” Naming Try to use semantic names like “Subtopics section” Rather than names reflecting a temporary design like “Accordion section”. Name it for the type of data, rather than how it is rendered at the moment
- Points A little-bit of code can make author’s lives much easier It not only reduces clicks, but reduces mistakes With a simple event handler, create a page’s “Page content” container (Document_Insert_After) Even create standard child content. In this example, every product page has a “Feature list” section