A different approach to interactive marquees/blocks

[matthewrayback]

For those who don't know me, I am the UX lead for Consonant. I am working with @Ruchika4 and @salonijain3 to find a more sustainable, scalable approach to build interactive blocks (like these: https://library--cc--adobecom.hlx.page/docs/library/kitchen-sink/interactive-marquee)

Quick context. Until now, requests for these have come from outside Consonant and the solution so far has been to build individual, bespoke new marquees to support each new individual use case. This is time and labor intensive and at odds with the philosophy of a design system. Now we are receiving additional requests and use cases that expand beyond marquees and we need to land on a more systematic approach.

If you break these requests down, they all contain two elements: 1) a container (which is very similar to our existing marquee or aside blocks) and 2) a set of "embellishments" that control the interactions (i.e.a prompt bar or a slider to affect hue and saturation, etc.) In some cases the embellishments are tied to a specific product API, but by an large today they are just mimicking product behavior (though there is desire in the future to connect more directly to the product.)

As I said, today we are trying to build all of this (container and embellishments) in a single block (i.e. a single table). This has a bunch of related drawbacks from a systems perspective:

• Each new request essentially calls for a new table to be engineered and maintained separately, even though many attributes of those blocks are the same. (By and larger, the container is the same. It's just the embellishments that change).
• Each new request is tied to a specific use case which means decoupling them for more general use is complicated.
• They are difficult to author.
• Any attempt to create a more scalable solution at the block level (i.e. cramming more embellishment features as options in a single table) seems to lead to an undesirable level of complexity that would ultimately lead us to make multiple similar blocks anyway.

From the design perspective, the ideal solution would be one that allowed us to decouple the container from the embellishments and develop and manage them separately.

Here's the approach I suggested to @Ruchika4 and @salonijain3 to demonstrate this idea:

What if instead of approaching these as a single block/table, we approached them as sections with a general container block (like a marquee or aside) and then each embellishment is itself a separate block/table and the placement and relationships of them are governed by the section metadata (or whatever). So an implementation in Word might look like this:

• Section table with metadata
• Table 1: Marquee or Aside (we'd have to decide which specific blocks could go in this section, but ideally they're ones we already have, i.e. large standard marquee, etc.)
• Table 2: Embellishment block 1 (i.e. the image selector, or slider, or whatever)
• Table 3: Embellishment block 2 (i.e. Enticement, or whatever)
• Section end

This approach, if it's possible, has several benefits to it.

• First, it's much easier to author.
• Second, it's much more scalable. If we want new embellishment blocks, we just have to focus on that, rather than building an entirely new marquee every time. Also, if we decide we want to apply an interaction to something other than a marquee or aside, we already have the framework to do that. Start with an existing block, then define how the embellishments should interact with it.
• Third it's closer to how I think we ultimately will do this in Figma.
• Fourth, it's much more of a system and easier to manage and govern. And hypothetically, it could help us set up for the future where we have real API calls from product. That seems like it would be much easier if we're doing that in an embellishment block/table rather than trying to figure out how to point a bunch of APIs at a marquee that has a bunch of other stuff going on.
• Fifth, it allows us to focus our efforts (and the efforts of our design partners) on what is actually different about these requests: the embellishments.

I will let @Ruchika4 speak in more detail to her concern, but while she generally liked this approach, it would require interactions between blocks (at the least by positioning the embellishment blocks within the container, but possibly by having interaction with an embellishment actually affect something in the container, like a slider changing an image or something). Apparently interactions between blocks are frowned upon.

So I'm opening up this for discussion. The approach I laid out may not be a viable solution in the end, but I'd like to put it out there in hopes that we can arrive at a better, more modular solution that decouples of the container and the embellishments.

Concerns about the approach I laid out? Solutions to make this suggestion better and more in like with Milo best practices? Alternative solutions that accomplish the same end goal in a better way?

Thanks in advance for the discussion.

[Ruchika4]

Tagging @chrischrischris @auniverseaway @rgclayton

[stereoke]

This approach seems similar to how we're nesting blocks to achieve the "quiz marquee" correct? @ryanmparrish

[ryanmparrish]

The quiz marquee is a single block/table, which has support for additional row(s) that get placed below the main marquee copy. Some of these rows have a key that can pull in dynamic fragments based on the quiz results. So it's similar in that there's a base w/ expected content and an authoring space for extending that content/view.

[ryanmparrish]

Quiz Marquee authoring docs - https://main--milo--adobecom.hlx.page/docs/library/kitchen-sink/quiz-marquee?primary=ps_indiv&quizKey=cc-quiz-en-US&debug=quiz-results

[matthewrayback]

Thanks. Do you think we could accomplish something similar here by making each of these embellishments a nested fragment as shown here? As I understand it there's little or no flexibility with fragments, correct? But maybe that's okay. @Ruchika4 @salonijain3 thoughts here?

This looks like it might be an approach that allows us to separate the container from the embellishments. Thoughts?

[ryanmparrish]

@matthewrayback - We would need to do a doc authoring exercise to determine these exact associations. This example is very fit for the quiz use case (content only, aka left copy. Asset always hidden on mobile/tablet) but we could potentially use a similar doc association w/ other blocks or dynamic fragments to allow for more isolated embellishments. LMK if I can help hash thru any of that. I think we could collectively come up w/ a solution that gives some consistency in an interactive marquee, but allows a lot of content associations while keeping reigns on the block standards.

[matthewrayback]

So @ryanmparrish and @rgclayton what are your thoughts about my approach above? If that won't, what other options do we have to take more modular approach to these so we don't have to build a new marquee or aside every single time we get a new request?

[matthewrayback]

I would love to agree on at least a high level approach. We have a working session with design next week to work through all the design pieces and I would love to go into that with a clear idea of how engineering wants to solve this problem.

[rgclayton]

If you break these requests down, they all contain two elements: 1) a container (which is very similar to our existing marquee or aside blocks) and 2) a set of "embellishments" that control the interactions (i.e.a prompt bar or a slider to affect hue and saturation, etc.) In some cases the embellishments are tied to a specific product API, but by an large today they are just mimicking product behavior (though there is desire in the future to connect more directly to the product.)

To me this still says bespoke. Even if there is a "container" there has to be a standard for the "embellishments" otherwise it's still a bespoke block tailored to fit a sites needs/wants. And this is the problem.

This approach, if it's possible, has several benefits to it.

First, it's much easier to author.

I'm not convinced of this. We already have a similar pattern. Carousel and tabs blocks. Both have a "container" block and then rely on sections with section-metadata to build the block. I don't know if i would say this is "easier to author" but it did allow us to work around the constraints of Word and not being able to nest blocks.

More blocks and moving parts typically results in being more difficult to author.

Second, it's much more scalable. If we want new embellishment blocks, we just have to focus on that, rather than building an entirely new marquee every time. Also, if we decide we want to apply an interaction to something other than a marquee or aside, we already have the framework to do that. Start with an existing block, then define how the embellishments should interact with it.

We still would have to sync the functionality to the container block for all the embellishments. Most likely any new embellishments would also require updates to the "container"

Third it's closer to how I think we ultimately will do this in Figma.

I think if you are having difficulties designing this system it will be equally if not more difficult for engineering. Have you started this process and created a POC in Figma?

Fifth, it allows us to focus our efforts (and the efforts of our design partners) on what is actually different about these requests: the embellishments.

Again, this makes me think it will continue to be bespoke based on partner needs.

I think at the end of the day for this to be a Milo core block there needs to be a base set of features. It would be good to get an outline of all the features and then figure out the best approach to author then engineer all these options.

[matthewrayback]

Thanks for the detailed response. What I am trying to get to is an approach where we can avoid having to create a new "bespoke" marquee for each new request (i.e., "Ps Change Saturation marquee," "Firefly generate image marquee," etc.). Instead, we can have a marquee container (ideally any marquee but even if we have to just have one "interactive marquee container") that can be populated by any future embellishments we come up with. This is why I suggested the section approach because it allows to develop them separately which is how I think we avoid a world where we have 50 marquees each devoted entirely a specific use case.

@ryanmparrish suggested taking a route like the quiz marquee which seems to be trying to solve a similar problem and I am open to that approach as well. We are having a design workshop on Wednesday to nail down all the design requirements and features we need to include, but I wanted to start the conversation now because we'll need to move fast to engineer this and the current approach is not systems-friendly or scalable.

If you have any additional ways we could approach this given the ideal I've outlined above, please share.

[rgclayton]

I think it really boils down to what the embellishments are. That's why I suggested taking inventory on all the requests and then sorting out what features everyone needs.

Instead, we can have a marquee container (ideally any marquee but even if we have to just have one "interactive marquee container") that can be populated by any future embellishments we come up with.

I don't know if this would ever be realistic. We need definition to create reusable patterns.

[matthewrayback]

Ok sounds good. I invited you to that call on Wednesday if you can join. I'd love to have your perspective in the mix post the design call and it might help for you to be involved in the design convo.