RFC: Slice Variations Usage

[lihbr]

Summary

Improving slices workflow for developers by preventing code duplication and for content writers by improving the writing room with a new feature allowing variations of a same slice. This thread is meant to discuss their usage more than the actual interface.

Concept

The concept of slice variation is about allowing variations within fields used/displayed in the writing room for a given slice. Goals of them are to:

• Improve the writing room interface, only fields relevant to the current variation are being displayed to the content writer;
• Turning slice labels into variation, therefore empowering developers to create more powerful slices.

Example

Considering a SimpleHero slice with two variations:

For the Basic variation, the editor will only display those fields:

• Title (title);
• Description (rich text);
• Featured Image (image).

For the With CTA variation, the editor will also come with additional fields inside its repeatable zone:

• CTA Link (link);
• CTA Label (key text).

To Consider

1. What is happening to fields content if the editor switch from the first variation to a second?

Using the above example if the content writer was using the With CTA variation but decide to switch back to the Basic one:

• What fields are returned by the API?
• If they switch back to the With CTA variation are fields resumed?

2. What is happening if two variations feature a field with the same API ID but the field type is actually different?

Considering a TextMedia slice with a variation with an image field under the API ID media and another variation with an embed field under the same media API ID

Related

Discussing GraphQL/GraphQuery interface for Slice Variations

[lihbr]

Here are some personal reflections regarding slice variations coming from this statement:

At the end of the day, aren't slice variations just slices organized in folders?

To me the above is true to some extent, indeed the only thing really shared by variations is the component (slice) code itself, not the mocks, nor the models, as fields are different from one variation to another. Therefore I can imagine great usage and poor usage of variation:

Great Usage of Variations

Taking the RFC example of the BasicHero slice with two variations, Basic and With CTA, this is to me a great usage of variations as indeed both variations will share a lot in common, and the variation type will be used to conditionally render the CTA list part of the slice.

Poor Usage of Variations

A poor usage of variations would be in my opinion with a TextWithMedia slice. Indeed as you have the With Image and the With Embed variations, component code starts to become messy, almost reimplementing a slice zone inside it to display what the current variation needs (variation zone?) I can only imagine components with a lot of variations in that fashion quickly becoming an if/else hell to conditionally render or not tons of things in it. When you're facing that kind of use case to me you'd better have 2 different but clean and easily understandable slices (TextWithImage and TextWithEmbed), in that case, being able to define a TextWithMedia slice folder would be actually great to group those slices together (more on folders later).

So What?

To wrap my mind around it I think variations are great in my opinion when you're facing a minimal/regular/extended pattern for versions of your slice (referring to the RFC example again Basic variation is a minimal version of the SimpleHero slice where With CTA is its regular one).

Considering that, perhaps variations should not be about defining fields for a slice but about hiding fields from a slice, therefore for our SimpleHero slice the workflow would be:

1. Defining all fields (title, description, featured image, cta link, cta label);
2. Defining the first Basic variation when you pick from the defined field the ones to display (title, description, featured image);
3. Defining the With CTA variation with all fields visible.

This would also solve concern n°2 of the RFC, preventing by design having different fields with the same API ID. The first suggestion of the Graph API discussion would actually make sense here also.

Slice Folders

Where variations are solving part of the "too many slices" issue in the UI, folders of slices (having a similar UI) could also be useful to group visually/usage similar, but programmatically different, slices.

[ReeceM]

With regards the editing the content side of things, I think it would be real useful for the variations to be retained between switching in the editor during the editing session. But lost when leaving the editing instance for a document.

How I would see that being useful is that if the editor:

• adds a slice to the doc, and they save and use the preview feature to see what it would look like,
• check that out,
• don't like that look once it is actually in place,
• return to the editor and change variation
• preview again, be happy
• hit save and leave that doc

As long as they are in the editor the variation data is preserved between switching. Not sure if that is how it would work/ is working as haven't seen the variation UI.

[evolve2k]

I'm not sure if this helps at all. But we've addressed this by defining each of the header variations as /components and then in the Prismic content editor have added a dropdown selector called 'header_layout'.

The page template then includes this at the top:

# nuxt/vue code example

<template>
  <main>
    <span v-if="doc.header_layout == 'hero-image'">
      <hero-image :doc="doc" />
    </span>
    <span v-else-if="doc.header_layout == 'hero-column'">
      <hero-column :doc="doc" />
    </span>
    <span v-else-if="doc.header_layout == 'hero-column-cta'">
      <hero-column-cta :doc="doc" />
    </span>
    <span v-else>
      <hero-row :doc="doc" />
    </span>
...

So then the user creates a new document and they can leave the Header Layout dropdown untouched and will get the default layout.. alternativley they can select one of the variations and the page will include that alternative header hero section.

[lihbr]

Hey, thanks @ReeceM, @evolve2k for your inputs 🙌

@ReeceM that's something to consider indeed, I get your point here

@evolve2k interesting, somehow you're implementing another slice-zone here for variations 🤔

@hypervillain I'd be interested in your opinion on all of that ☺️

[davidparys]

This could be a gamechanger, include the picture of the slice, the variation of the slice, and the description of the slice, which would result in creating an actual design system.

[jrah]

I have a similar approach to @evolve2k where I use the select.

I like the idea of having a basic, standard, baseline slice variant and the others are variations of the base slice.

It is true that having many if/else can become untidy but so can having many slices. I think that slice variants can reduce the cognitive load (primarily for the content manager, secondarily for the developer and designer).

How I see them in principle is that slices have a significant change in design but uses the same content model (or similar?). How might someone name a variant might be purely semantic.

If you have a look at how TailwindUI has done it, you can see for instance in their "Hero Section" many of the "slices" are similar but likely share the same content model with slight design variations but there are so many granular changes that it is difficult to account with for all of them with just a select drop down. Sometimes they have buttons or sometimes without an image, I think in this case (IMO) it is possible to run a conditional to check if the image or button(s) exist/if they left it empty.

If we were to take some use real-life use cases (not sure if I can do this publicly, please moderate my comment if it is not):

Splash display (Hero) (base variant)

You might choose to use this as part of a header. It might have a big image and call to action(s) with the page title.

https://nexo.io/earn-crypto

This would be like "Hero sections" as in Tailwind UI but it might share the same content model as others that might be named (semantically) but also used differently (see below).

Splash display (Banner variant)

This uses a similar content model but is used differently. There is no image, but it does still have the heading and call to action. The background colour is also not full width but within the container.

https://nexo.io/earn-crypto

Splash display (banner variant with non-default options)

This might be an example of more granular options that could be available without migrating to a full variant.

When we compare it to the base variant with the default options selected a content manager will be able to choose if they want to either have default, reverse or center. If they include an image it would apply it as a background image.

sketch.com

I think that this way would be more understandable to a content manager and other stakeholders. Of course, it depends on the use case for the website or application. I think it also depends on how much freedom the developer/design team wants to give to the content team.

Considerations

1. I think this would be a nice idea if it can be implemented. I think users would expect to be able to switch between variants and for their original content to be there when they switch back (can see the panicked email and 60 missed phone calls now). Adding a warning would contradict Prismic no validation philosophy.

2. Could you not append the slice variant to the API ID? ${api_id}${variant_id} ? Would that create trouble?

P.S. Excited to see how Monogram has approached this next week. I agree with @davidparys, it will be really amazing! Looking forward to it.

[Duaner]

Hey all thanks for the great feedback, it's fantastic to have your input on that.

I completely agree with you @ReeceM we were thinking about that from the beginning of the project. We will support the content migration from a variation to another as soon as the field is having the same key in both variations.

For the design, we were thinking about something like that. Does it correspond to what you're looking for @davidparys?

Let me know what you think

[davidparys]

Hey all thanks for the great feedback, it's fantastic to have your input on that.

I completely agree with you @ReeceM we were thinking about that from the beginning of the project. We will support the content migration from a variation to another as soon as the field is having the same key in both variations.

For the design, we were thinking about something like that. Does it correspond to what you're looking for @davidparys?

Let me know what you think

Looks great. 👍

[hv-prov]

I have another perspective on variations, so allow me share my 2 cents 😊

To me, variations are not satisfying in their current state: the fact that variations don't truly share fields (just copies of configuration) brings a lot of overhead and is error prone on the long run. Pretty much like sharing slices between custom types before we introduced real shared slices.

Because fields are not shared, changing a field in one variation won't rapport the change in other variations, although you would tend to think it does. It also means that you'd have to manually propagate a change everywhere. Preserving state between variations in the editor would be somewhat possible but subject to errors too: consider 2 RichTexts with different options: copying content 1 to content 2 might break the constraint on content type (which would let the editor in a pretty weird state).

It's also much more difficult to handle in the editor and forces everything to be scoped: Storybook stories, both automatic and custom screenshots and mocks. I guess this part is not a major blocker of course 😊

Something I really like at Prismic is that we try to consider if a new feature enforces better practices before releasing it, but following @lihbr 's second message: as is, variations could be used both well and poorly. They require to be thought through carefully and by experience, we know that modelling things the right way is hard, especially in your first projects.

That being said, I would love to be able to preview variations screenshots in my editor, whatever variations mean!

[lihbr]

Slice variations are now a thing (since quite some time!) 🎉