Modeling buttons/links

Hello,

I’m curious how people go about modeling links/buttons in general and for call to actions in particular.

The basic model

Is what’s used in the samples : two fields button_link and button_label

Pros

  • This is very simple to model
  • Editors can easily use different texts for buttons that link to the same document in different contexts
  • you can add a 3rd key field to use as an alternative if you want to provide an internal relative link not to a document

Cons

  • This model becomes quite painful on the templating side when you have multiple buttons because the template has to know all the field names that need to render to a button and what they mean:
    • primary_cta_link
    • primary_cta_label
    • secondary_cta_link
    • secondary_cta_label
  • This relies on convention where fields with a given prefix relate to the same button/link
  • This can easily lead to an inconsistent experience if editors keep using different terms when referring to the same document

The basic+ model

I call this basic+ as the idea is to use a group to create a field with both the link and the label

Pros

  • Not too complex to model
  • You can make it repeatable
  • You can add a select field to define primary/secondary/ or whaterver status/css class makes sens,
    *This makes it slightly easier to render on the templating side.
  • Editors can easily use different texts for buttons that link to the same document in different contexts
  • you can add a 3rd key field to use as an alternative if you want to provide an internal relative link not to a document

Cons

  • You can’t nest a group within a group (at least that’s what the json editor tells me, maybe I missed something) so this model cannot be used everywhere.
  • It still relies on convention but only to know that a field is a button/link in templating, once you know that you get attributes
  • It doesn’t help on the consistency side

The Richtext model

Using a RichText which is restricted to hyperlink, you can use labels on the field to help with templating (is it a link or a button, is it squared or rounded, primary or secondary or tertiary,…)

Pros

  • Can be used everywhere
  • Groups link/button properties in a single field
  • Editors can easily use different texts for buttons that link to the same document in different contexts

Cons

  • Needs the json editor for modeling
  • It doesn’t rely on convention anymore
  • It doesn’t help on the consistency risk
  • it become painful quite fast if you want to control multiple attributes on the final tag
  • cannot be used for internal relative links that are not documents since prismic will force add http:// or https:// when you choose link to the web.

The custom type model

Where you have a custom document type for buttons/links, you then create as many documents as there are buttons/links in your website. You give access to a library of predefined links to your editors.

Pros

  • since it’s a document type its very easy to identify on the templating side
  • It is reasonably easy to model
  • it helps with the consistency of actions
  • you can include a key field if you want to use relative hrefs to things that are not documents

Cons

  • It pollutes the “document” list with a possibly high number of links
  • it’s forces editors to create a new link if they want to use an alternate label
  • external documents are not automatically fetched so you must resolve them when rendering the template or remember to prefetch them which is not always obvious

The advanced custom type model

is where you use the custom type model in combination with the basic model model to provide an easier alternate text for the link to your editors while having a default text that’s always available

Pros

  • everything from custom type model,
  • Editors can easily use different texts for buttons that link to the same document in different contexts but they have a reasonable default provided

Cons

  • fairly complex model
  • external documents are still not automatically fetched so you must resolve them when rendering the template or remember to prefetch them which is not always obvious

We usually use the custom type for recurrent call to actions and rich text for the rest. We add a custom key field when a richt_text link needs a relative href

I can’t help but feel there is something missing in the components library for links/buttons though.

What are your models/experiences ?

thanks

1 Like

I use what you call the ‘basic model’, but don’t have namespace issues as I use slices.

With slices, you can also have labels for ‘primary’, ‘secondary’, ‘tertiary’, etcetera.

I like to be able to separate links from buttons, especially as I don’t think the RichText links allow metadata to be added, other than target="_blank" or not.

hmm you use slices for individual components (such as buttons) or you use a slice and within the context of that slice the link can only be a link/button ?

also I don’t see how that avoids the namespacing issue : what if you have to call to action in the same slice ? for instance in this theme (forget the fact that its wordpress;) https://colorlib.com/wp/themes/illdy/ I could have a slice for the banner (with title, image, two buttons) but I can’t have a group in a slice or a slice in a slice (that I’m aware of).

Not entirely, since the website doesn’t require buttons like that. But I have a form slice with a button in it, and a mailing list subscribe slice.

Slices have repeatable zones, so yes, you would be able to make that without conflicting names.