Going Gutenberg is an ongoing series about our process of integrating our products with the WordPress block editor. View all chapters in the series here, and be sure to follow us on Facebook or Twitter to never miss an update.
In Going Gutenberg: Chapter IV we talked about thinking of blocks as having distinct “preview” and “active” states, which helped us resolve a number of design challenges with our most intricate, data-heavy blocks.
But a number of design challenges still remain. As we dig deeper into building the Event Price block, for example, even the notion of preview and active states doesn’t fully resolve all design problems. We’ve had to pause, think, and iterate some more to come up with a third concept to help with designing complex blocks: the “dashboard.”
The Concept of Block Dashboards
We’re not talking about the WordPress dashboard. We’re talking about “block dashboards,” a term we came up with to refer to pieces of the user interface (UI) that allow for the active state of a block to essentially have its own distinct active and preview states.
Block Dashboards in Action
Visual examples make this more concrete, so let’s start with some examples where block dashboards are not needed.
Our Event Sharing block is so simple that it doesn’t need an active and preview state—the block closely resembles how it’ll look on the front end and requires such little configuration that the block is truly WYSIWYG:
In the example of our Event Price block, however, we see the value of having distinct active and preview states. Here’s the block’s preview state, which provides a close approximation of how it will appear on the front end:
Upon interacting with the block, it’s put into an active state—an expanded form UI that doesn’t look anything like the block’s front-end output, but allows for easier data entry:
Now let’s turn to the Date and Time block. Here you can see its unassuming preview state:
Upon interaction, you can see its active state:
Within the active state, we see the dashboard concept in action. When you choose multiple dates, for example, much of the “active state” of the block changes. In the following screenshot, you can see how the display of the start and end dates differs from the screenshot above:
The “dashboard” approach here means that aspects of the active state are only visible when necessary. This is a boon for usability because it lets us show elements of complicated forms only when they are essential, like the underlying active/preview state structure itself.
The Lifetime of Design Decisions
We shared in our previous chapter how thinking of blocks as having active and preview states helped us resolve a number of design challenges. In just a few short weeks or working down that path, we ran into the limitations of that concept and needed to expand on those ideas, arriving at the dashboard concept described here.
As we keep designing complex blocks—and as WordPress Core’s block editor itself changes—we’ll almost certainly have to come up with new design approaches and philosophies that build on (and possibly even replace) our existing ones.
To stay up to date on our Gutenberg journey, be sure to subscribe to this blog so you never miss an update.
🔔 Please Note: This is a blog series about active development and exploration. Anything we mention here is subject to change, and this blog series should be read as a tentative roadmap for our products—not an official release plan.