Content design patterns for XbyK

I'm looking at a PBI in our backlog that describes creating a CTA Widget Bar that is essentially a headline and 0-4 CTA buttons horizontally aligned.

Each button can be configured for label, URL, target, size, light|dark

The PBI indicates to create 4 copies of the fields, so CTALabel1, CTALabel2, etc. In my opinion, this flat structure is too denormalized, doesn't scale well, and just feels like an anti-pattern. I offered up an alternative which I believe follows more the way Kentico intends you to design content. This would basically be to create a LinkItem content type that gets stored in the content hub. Authors create their links here, and then they can be selected as "children" from widgets. In fact, if you make them generic enough, they can be a CTA, a Link, a Nav item, anything that uses a URL.

I got some pushback that this solution was overkill, overengineered, "it's just a simple button," or "we won't be reusing these very often." Further, to keep myself in check, I had my own concerns, mostly in terms of the potential disjointed editing experience requiring the author to go to the hub first, create the content, then hop back to PageBuilder to select the items. My next plan was to test that theory out, because if Kentico allows for the ability to create content items (and folders) in the hub on the fly from PageBuilder, then that squashes that concern. That essentially then puts the onus of good organization of content items in the hub on the authors which I don't consider a problem.

While my gut tells me my solution is probably the right call, I wanted to discuss with the community here so I could at least come back to the team with some extra input from the community on best practices.

Environment

  • Xperience by Kentico version: [30.11.2]

  • .NET version: [10]

  • Execution environment: Private cloud (Azure)]

Tags:
Content management Content modeling Project strategy Page Builder

Answers

Accepted answer

Your gut is right here. The type of model you’re suggesting, and one I also use in my own projects, is much closer to how Kentico generally encourages structured and reusable content.

Create a reusable Link content type in the Content hub with fields like:

  • Title
  • DestinationType with values like Internal page, External URL, File
  • InternalPage
  • ExternalUrl
  • File
  • OpenInNewTab
  • Optional InternalPageAnchor

Use DestinationType as the visibility condition for the destination fields.

Then, in the CTA Widget Bar, expose a content item selector scoped to the Link type and set MaximumItems = 4. Keep presentation options like button size, light/dark theme, alignment, spacing, etc. on the widget itself, not on the reusable Link item.

That gives authors a reusable structured link item, while the CTA Bar remains responsible for presentation. It also avoids creating four repeated sets of fields. Because the link itself is generic, it can also be reused across the content model in other places that need a destination, such as navigation, link lists, cards, or related-content blocks.

Kentico’s docs support this pattern as well: Page Builder widgets can reference structured reusable content from the Content hub, and authors can create reusable items from the editing flow through selectors. So the experience does not necessarily require creating everything in the hub first and then coming back to the page.

Supporting docs pages:

https://docs.kentico.com/guides/architecture/content-modeling/model-website-presentation-components/model-page-builder-widgets.html

https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-website-content.html

This case I would indeed make a Content Type and your widget select them, it will be easier to manage and there will be sharing.

There is a time and place to do a "Field1, Field2, Field3", but they are pretty rare, and you really have to think about the balance of having a to create the extra items and usage. I have 1 case where I have a "Mobile Friendly Table" widget, that has Column Headers (up to 5), and Row "Headers" (up to 12 rows), as these values are needed to create the mobile cell-hints and stuff, and as this won't ever be reusable I am okay with having the duplication in fields (I have logic to parse them into a dictionary, so adding more rows is easy if i ever come across the need for it).

Content Hub is low 'cost', it can hold hundreds of thousands of items easily, only downside is cleanups in the future, which if you're worried about that, just throw the CTAs into a workspace.

Thank you all. I knew the answer, but I wanted to prove to my team I'm not just being a zealot and get some outside opinions.

To response this discussion, you have to login first.