Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outline for Block Behaviors #50029

Open
mtias opened this issue Apr 24, 2023 · 12 comments
Open

Outline for Block Behaviors #50029

mtias opened this issue Apr 24, 2023 · 12 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Interactivity API API to add frontend interactivity to blocks. [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues

Comments

@mtias
Copy link
Member

mtias commented Apr 24, 2023

This is a rough overview for exploring how we could connect the active proposal for frontend block interactivity with user configuration within the editor. (Read the proposal for more background on the interactivity API.)

Behaviors are meant to be reusable and composable interactive hooks that can be attached to blocks. The intended outcome is to alleviate the need for extending blocks themselves (or needing to create custom blocks) to provide augmented experiences across block types. It also aims to provide users visibility and control. These behaviors can range from simple things like lightboxes to other more sophisticated effects. The essence of it is that they don't exist in the blocks themselves but can be attached to them, either programatically or by users. It should be possible to define them at a block type level (all image blocks get a lightbox behaviour) and on a per-block instance (this specific image should not get a lightbox behaviour). Other types of behaviors are what we have in the navigation block (open in overlay modal) which should be applicable to other blocks.

What this issue focuses on is on how we could structure and present reusable declaratives (i.e. "behaviors") that can be registered and attached to blocks by a user using the editor UI. Allowing composition of these behaviours is an important consideration of the design.

How behaviors themselves are built is not covered here (that's part of the interactivity API), only the declaration and UI aspects.


Overview of implications on the interface:

  • Available behaviors should be selectable in a panel on the block inspector (probably under Advanced to start with).
  • Behaviors should not trigger on the editor (but they could trigger on preview states, like "browse mode").
  • Global styles should be aware of these on its block type specific pool.

Outstanding questions:

  • Initially behaviours could just be opaque (no configuration) but we might need to explore configuration aspects.
  • It should be clear if a block is inheriting behaviours from its block type.
  • Whether specific behaviors should be lifted up in the UI into more prominent block specifics settings (for example, if lightbox is important, that it can be accessed more easily than in an advanced panel). This rests on solving whether behaviors is a more consistent access point for other types of controls.

This is still exploratory in nature, with a focus on figuring out how single image lighboxes could work as a stand in use case.

@mtias mtias added the [Feature] Block API API that allows to express the block paradigm. label Apr 24, 2023
@gziolo gziolo added the [Feature] Interactivity API API to add frontend interactivity to blocks. label Apr 24, 2023
@gziolo gziolo mentioned this issue Apr 24, 2023
67 tasks
@michalczaplinski
Copy link
Contributor

michalczaplinski commented Apr 26, 2023

I have some questions and concerns to help us figure out the right UI for the Behaviors and make sure we’re solving the right problem.

  1. What is the problem that Behaviors are trying to solve? What are some use cases?
    We would benefit from a longer list of potential use cases for the Behaviors. The ones that I have seen mentioned so far are:

    1. Lightbox (PR)
    2. “Show in view” behavior
    3. Dynamic time difference

    I would like to have a longer list of use cases so that we can be confident that the Behaviors are the right abstraction and that we’re not building a general solution to only solve narrow use cases.

  2. Customizing behaviors

    1. Behaviors should work across block boundaries. As currently specified, a behavior attached to some block A has to be contained to this block A . The following behaviors would not be possible:

      • I want clicking a button to show/hide another block.
      • I want the lightbox behavior to be triggered when clicking an “Enlarge” button in addition to when clicking the image itself.

      The most interesting user interactions are not constrained to a single block but happen when the user “clicks somewhere” and then “something happens elsewhere on the page”.

    2. Customizing the “trigger” of the behavior, e.g:

      • I want to open the lightbox on hover instead of on click.
      • I want to trigger a popup to subscribe to my newsletter after scrolling X% of the page (an annoying but common pattern for sure 😅).
      • The same example as in point 1. above: I want the lightbox behavior to be triggered when clicking some “Enlarge” button in addition to when clicking the image itself.
    3. Configuring/parameterizing the behaviors

      Consider an “analytics” behavior that sends some data to an analytics endpoint whenever a performs an action. At a bare minimum it would require a way to configure that endpoint in the block editor and define on which action to send the event: click/hover/focus, etc.

  3. Reusability and composability
    I foresee that there will be ways in which behaviors will be subtly incompatible across different blocks unless they are made to be flexible from the very beginning. For simple interactions restricted to a single block like “lightbox”, there is probably no problem. However, as soon as we’re talking about Behaviors that can work across blocks (which I would argue are the most interesting and useful ones), we need ways to attach them to multiple blocks and define ways in which they’re connected, etc.

  4. Other CMSes and no-code builders like Bubble, Webflow and UIflow approach this problem in a different way: using triggers and actions. Is this approach something that was considered?

    (video to show you what I mean with triggers and actions)

Overall, my main concern is that only shipping “single-block”, “single-trigger”, and "predetermined" behaviors is of limited value, and we should think more broadly about the use cases and the capabilities that we want to unlock! I think it should be possible to first ship very restricted “single-block” & “single-trigger” behaviors but then gradually find ways to incorporate custom triggers and parameterize the behaviors.

(thanks @SantosGuillamot for pointing out to me that we can work on the Behaviors in a progressive, gradual way)

@artemiomorales
Copy link
Contributor

Related to #49972

@SantosGuillamot
Copy link
Contributor

I like the idea of differentiating between "Behaviors" and "Triggers" and exploring the possibility of triggering behaviors from different blocks. For example, showing a popup when clicking on a button. Apart from that, it'd be great if behaviors are extensible somehow, and external plugins can easily add a behavior to an image for example.

This seems to be the ideal scenario for me, providing users with a lot of flexibility and power. On the other hand, I feel it should be done cautiously, and it requires a lot of thought, especially in terms of UX and composability.

I believe we can start with just behaviors that have the trigger "hardcoded" in a single-block and look for ways of abstracting it later. We just have to make sure that whatever we do now, doesn't lock these possibilities.

What is the problem that Behaviors are trying to solve? What are some use cases?

Regarding this, some examples that come to my mind, although I haven't thought too much if behaviors is the right mechanism for them:

  • Infinite scroll in Query Loop block.
  • Typing text effect.
  • Instant search in the search block.
  • Dynamic progress bar.
  • Animations for modals or accordion block.

And I can imagine people being creative with behaviors. That's why I feel that providing mechanisms to let them add behaviors to existing blocks could be powerful.

@michalczaplinski
Copy link
Contributor

michalczaplinski commented May 4, 2023

I believe we can start with just behaviors that have the trigger "hardcoded" in a single-block and look for ways of abstracting it later. We just have to make sure that whatever we do now, doesn't lock these possibilities.

Agreed :)

It seems that it’s too early for the discussion about adding “triggers” and “targets”. 🙂 For now, we can just move ahead with the implementation that is needed to ship the Lightbox (#49621). Working on it in #49972.

  • Infinite scroll in Query Loop block.
  • Typing text effect.
  • Instant search in the search block.
  • Dynamic progress bar.
  • Animations for modals or accordion block.

Nice, thank you for this!

@michalczaplinski
Copy link
Contributor

It looks like there is a general consensus that we should first go ahead with a very minimal implementation of behaviors that is only scoped to the core/image block. The initial implementation should be (broadly speaking) only concerned with:

  • Integration with theme.json & block.json. Whether the UI for enabling behaviors should be present can be defined in the theme.json and is inherited but overridable in the block.json.
  • Basic UI to add/remove the behavior from the element. For the moment, there is only one behavior, "lightbox" that can only be added to the Image block.

Below are details provided earlier by @SantosGuillamot in a private discussion so that we can continue discussing them here in public:


Behaviors UI (excluding the Global Styles UI)

  • Setting: Themes can turn on or off support for the behavior UI in the theme.json under settings.blocks.core/image.behavior.lightbox.

    • By default it is turned on in the core theme.json file.
    • It can be overwritten by a theme's theme.json.
  • Behavior: Themes can add or remove the behavior functionality by default to all the image blocks under behaviors.blocks.core/image.lightbox.

    • By default it’s added in the core theme.json file.
    • It can be overwritten by a theme's theme.json.
  • Users can add or remove the behavior from a single image block.

    • Add the attribute to the block.json.
    • Save it in the block attributes: <!-- wp:image { “behaviors”: { “lightbox”: true } } -->

Read the blocks.core/image.behavior.lightbox setting with useSetting() hook. If enabled, add the UI in “Advanced” panel: dropdown with the list of behaviors (user could also select “none”).

  • Documentation:
    • User - Explain how to activate the behavior and what it does.
    • Theme.json - Explain how to activate the UI or not, and how to set a default value.

It's difficult to explain the difference between the setting that controls whether a site can use the behavior or not, and the default value of the behavior, so we tried using a drawing. We are not super happy with the outcome, but here it is:

image

Global Styles UI (not required at the beginning)

These are preliminary instructions based on how the Effects panel works, but it’s not exhaustive research of what needs to be done. This may not work for our use case, so you may need to do additional research and do some things differently.

Also, the Effects panel is enabled using block supports (shadow: true), but we won’t use block supports yet. So we have to figure out how to integrate that.

  • Add Behaviors panel to the block-editor package

    • Inside components/global-styles, create a behaviors-panel.js file (like the effects panel).
      • It reads and updates the settings.
      • It creates the layout to change the settings.
      • It exports the component.
      • It exports a useHasBehaviorPanel hook.
    • Export it in the index.js file (like in the effects file)
  • Add the Behaviors panel to the edit-site package

@cbravobernal
Copy link
Contributor

Also, the Effects panel is enabled using block supports (shadow: true), but we won’t use block supports yet. So we have to figure out how to integrate that.

Is there any reason that I could be missing of why not using block supports?
My first impression is that it would fit like colors, shadows, etc, allowing us to enable all behaviors or individual ones by block easily while maintaining coherence with the rest of features. Also, I think in that case, we may also not need a global option to enable or disable all of them at once.

@gziolo
Copy link
Member

gziolo commented May 10, 2023

Also, the Effects panel is enabled using block supports (shadow: true), but we won’t use block supports yet. So we have to figure out how to integrate that.

Is there any reason that I could be missing of why not using block supports? My first impression is that it would fit like colors, shadows, etc, allowing us to enable all behaviors or individual ones by block easily while maintaining coherence with the rest of features. Also, I think in that case, we may also not need a global option to enable or disable all of them at once.

The challenge here is that for design elements, there is everything in place to dynamically modify the block so the color, shadow, margin works out of the box. You would need to figure out how to modify the block externally so the lightbox seamlessly integrates.

@hanneslsm
Copy link

hanneslsm commented May 10, 2023

I just tried to get my head around this topic. I'm not a technical expert, so excuse the stupid questions.
But if I'm understanding it right, plainly said, the Block API basically gives the possibility to program stuff, right?

As a designer I'm thinking about how a good UI and UX for that could be created. What instantly comes in my mind is something like Scratch. This is a clean interface and we could also work with triggers and behaviours, but in a much more scalable and in a intuitive way than inserting this all in the editor like in Webflow. I'm not talking about the specific UI, but the way of thinking. Is this something that was considered? (And does this even make sense? lol)

@michalczaplinski
Copy link
Contributor

I've recorded a short video to clarify how I see the implementation going forward and how its mechanics are similar to the current dropCap feature of the Paragraph block.

@gziolo
Copy link
Member

gziolo commented May 12, 2023

Great summary, @michalczaplinski. It looks like a reasonable approach to start with as it covers both the aspect of controlling the UI and changing the default behavior by the theme/site. It would be also cool to be able to offer a UI control for users to optionally change the default behavior in the Site Editor in the Styles tab for all blocks or individual blocks. That would give maximum control and full flexibility.

@michalczaplinski
Copy link
Contributor

michalczaplinski commented May 25, 2023

The PR introducing the Behaviors UI has been merged.

Here are some outstanding tasks (other than Removing Interactivity API experimental flag):

@michalczaplinski
Copy link
Contributor

I've updated the task list. We are not currently pursuing the "nice-to-haves" from that list.

The tasks that are necessary to complete the MVP of Behaviors are tracked in #52292

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Interactivity API API to add frontend interactivity to blocks. [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Projects
Status: Next
Development

No branches or pull requests

8 participants