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

3 Likes

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.

This issue has been closed due to inactivity.

I agree with Jean. It's strange that Prismic has tons of great features but doesn't have a field option for 'buttons' with the built-in standard button toggles (style, content, action/link). Which is just as commonly used in websites as images and probably far more used/needed than more niche fields such as 'GeoPoint'.

Whilst I could feasibly build a button as a slice and create variations (e.g. primary, secondary ...) I can't then include this slice inside another slice, e.g. I have a 'hero' slice section. Still, I want this to have a button (a slice), but there's currently no way to add this in. Therefore, every time I want to add a button to a slice, it has to be created from scratch.

So, I'm currently using the SliceMachine, a fantastic tool, and I'm really enjoying it.

However, a really annoying problem I've run into (so far) is the inability to add 'groups' (which I can do in content models?) or even better yet have the ability to use another slice within a slice. As I described above, Prismic would be infinitely more versatile if this was an option.

3 Likes

Thank you for your comments. Today there are alternatives to building a button in Prismic. You need to use either a Link field or a custom code field. And if you want to reuse it, you can do it with a Content Relationship field. Because not every button in a web app has the same behavior so by having the components available to build whatever you need is more flexible!

For example, you can create a Custom Type 'Button' with a Rich text field to which you can add labels and a Link field to add links to internal documents or external URLs. Or you can add the same Link field and then your Custom code field to add the HTML and className you want there.

Do you have any tutorials (code examples) of Button with Prismic?
I still can't wrap my head around how to do this, which should be a simple task in any CMS.

I'd like a button which can link to external url or internal doc with a custom title and a possible option to select "Primary/Secondary" and which could be included in any slice

1 Like

@tadas.majeris I might create a tutorial detailing how I do it, but in overview, there isn't a solid way to model buttons as you can't create "custom fields".

At the moment I add three fields:

  • ctaText -> key text field
  • ctaLink -> link field (can both link to external URLs and internal documents)
  • ctaType -> select field (primary/secondary/white, etc)

The downside is obvious -> you have to include those 3 fields any time you want to add a button in your models/slices and you have to remember to keep them up to them (eg if you add a new CTA type)


Furthermore, I just wanted to touch on another solution that has been proposed here. The proposed solution of using Custom Type + Custom Relationship is not really viable as you'd need to create a new document for every text/link/type you want to add to the page, which are almost always unique for a marketing website. So if you want to add a new button, you'd need to:

  1. exit your document you are editing
  2. create a new document, populate the fields and publish
  3. go back in into the doc you are editing
  4. select the button from the dropdown
  5. every time I want to edit my button, I need to go back to the individual document and edit it in there. I need to also be careful that it hasn't been linked in another document.

This is why I encourage the Prismic Team to either create a button field, or even better - create the ability to create our own "custom fields". Since Slice Machine is work in progress, it might be a perfect opportunity to explore this feature. Pinging @angeloashmore in case he wants to add something to the discussion.

4 Likes

It would be interesting to open a window to create and link or just link existing relational content

Hi @isaiaszmendes,

Thanks for posting here! Why would you need such options? Can you describe your usecase?

Hi, the same topic about @kris comment before, the option 5 "every time I want to edit my button, I need to go back to the individual document and edit it in there. I need to also be careful that it hasn't been linked in another document." It would be interesting to open a window to create and link or just link existing content relationship on the same page editor

Thanks!

I see your concerns. This conversation is gold to us, we're indeed evaluating the problems/solutions to improve Prismic's capabilities for use cases like buttons.

To be fully transparent, this is not our number one priority at the moment but it is part of the general topic of modeling capabilities that we're focused on at the moment.

See more here: Native content modeling options for your most elaborate slices