Exploration to enable better Developer and Visitor Experiences with blocks

In this post, we are using the following terms:

Visitor Experience: to refer to the UXUX User experience of a final user visiting a WordPress site.
Editor Experience: to refer to the UX of a user in the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.
Block Developer Experience: to refer to the experience developers have when working to create blocks.

Blocks have been a huge improvement for the Editor Experience. Now, editors can create complex content and customize their site designs with the same technique: by using blocks. But from a development perspective, there’s still room for improvement with regard to the level of interactivity that can be enabled with blocks for the visitors of a WordPress site (Visitor Experience) and the Development Experience of creating blocks. 

The general acceptance of blocks as the new WordPress data abstraction is the perfect moment to provide a standard solution to create interactive blocks. 

Wouldn’t it be nice (🎶) if we could…

  • Enable a much more powerful interactive and dynamic Visitor Experience with blocks? 
  • Have a much more delightful Developer Experience when building blocks? 
  • Offer a standard way to create interactive blocks so block developers don’t have to reinvent the wheel? 
  • Ensure the block editor takes care of performance optimizations for visitors?
  • Enable nice and faster page transitions with blocks? 

This post aims to start a conversation about these challenges and highlight them as some of the problems that need to be solved in order to achieve one of the big-picture goals for 2022: To improve the Block Developer Experience.

Table of Contents

A better interactive and dynamic Visitor Experience with blocks

What does it mean, to have better interactive and dynamic Visitor Experiences with blocks? Let’s take some use cases as examples of things that would be great if they could  be done just with blocks. Imagine (🎶) :

  • A form block that doesn’t trigger a page reload to display responses from the server. 
  • A pagination block that doesn’t reload the whole page when going to “next page” and loads only the portion needed.
  • A learning management system (LMS) where users can interact with the content in a more dynamic way enabling a better learning experience
  • Create with blocks a great e-commerce experience with carts, checkouts, and product galleries that dynamically respond to the visitor interaction
  • The ability to create just with blocks things such as Infinite Scroll, Swipe Navigation or any other experience in the frontend you can imagine.

Let’s work together to enable these kinds of delightful Visitor Experiences by using blocks!

By working together we can create  a standard way to develop blocks that enable complex and performant visitor experiences (perhaps by taking advantage of techniques such as frontend block hydration). 

A better Block Developer Experience

Blocks are amazing. They are a great mechanism for writing content. And now, with Full Site Editing, the power of Blocks has reached the world of Themes, so you don’t need to know how to code to create and customize your WordPress site. 

There are still challenges to solve though regarding the Block Developer Experience (“better block deprecation management” or “avoid duplication of code across JavascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher in order to properly render a block” are some examples of things that could be improved). It would be great if blocks could enable great Visitor experiences whilst also taking care of the complexity of modern tooling and strategies.

Let’s work together to define a standard way to create blocks that makes the development of blocks a pleasant experience.  

Get involved! 

Please share your thoughts, feedback, or ideas in the comments of this post or in the Developer Experience category of Github Discussions of the Gutenberg repo. There are already some conversations started by contributors there.

We’d love to hear your ideas regarding this:

  • Do you have some exploration you’d like to share with the community? 
  • How do you think blocks could enable more powerful Visitor Experiences? 
  • Is there any specific Visitor Experience (transitions between pages, partial hydration,…) that cannot be (easily) done with blocks that you think is missing? 
  • How do you think the Block Development Experience could be improved? 
  • What are the most important aspects of Block Development Experience you would like to improve?

Thank you (🎶) to @luisherranz, @priethor, @bph, @annezazu, @poliuk, @matweb, @mburridge for reviewing and helping shape this post!

#block-developer-experience, #interactivity-api, #visitor-experience