It’s been about a month since that initial release, and in that time we’ve continued to release updates with bug fixes and tweaks to improve the extension. Through this work, we’ve learned a ton about creating and maintaining events content in the block editor, and helped solidify our plans for future releases.
But what lies around the corner isn’t just a list of patches and smaller tweaks—we’re working on the next phase of the Events Gutenberg compatibility, which includes a whole new design of the event post type’s block editor.
Our goal for the extension was just to make a block editor for the event post type that worked. Now we’re working on making that editor stable and beautiful.
The Necessity of Excellent Design in the Block Editor
One of the core promises of the block editor is to replace the tabular, data-entry feel of WordPress’ existing editor (filling out a form) with a flexible, aesthetic experience—one in which you essentially build content with components that look just like they will on the front-end (page-building). This difference elevates the quality of design and attention to detail required for a good editing experience.
With the classic editor, you can achieve most of your content-creation needs by just using basic HTML form elements—a text area here, a radio button there—but this is no longer the case with the blocks editor. Each component of data entry in the blocks editor must itself be aesthetically pleasing and intentionally designed, because it must resemble the front-end version of itself as closely as possible.
This is sometimes easy, like with The Events Calendar’s single-event export buttons. They have one piece of data—the button text—so, they’re easy to render in the wp-admin block editor in a way that almost exactly matches their front-end appearance (see below):
It’s not always so simple. More often, making a beautiful and functional block is a huge challenge, so we’ve invested serious time with some of our best designers to craft the right user experience.
The Challenge of Excellent Design in the Block Editor
One block that we’ve put weeks of thought and work into—with more of both in store—is the most essential aspect of an event: the time and date.
If this doesn’t seem that complicated to you, our past selves might’ve agreed. “How hard can it be?” we initially asked. “Add some inputs for date and time, and put other options in the block editor’s sidebar options panel.”
But it’s not so simple. This block has to handle the entry and displaying of a lot of data:
- Event start time
- Event start date
- Event end time
- Event end date
- Date separator
- Time separator
- Time zone
It’s a short list, but it gets complicated fast. Each of these data points has its own set of design challenges. For example, while most events have a start and end time, some are all-day events. How can we make it easy for users to create all-day events while maintaining the default option, and how can we make the choice intuitive for different types of users?
More questions arise when we start thinking about multi-day events. Many events only need a single date input, but multi-day events have a different start and end date. Do we use two date fields from the start, making unnecessary clutter for single day events? Or should we turn on an additional field if the user specifically opts for a multi-day event, which could be confusing for the user?
The Events Calendar is flexible and we plan to keep it that way. But recreating that flexible user interface while presenting an accurate preview of the front end display has been a consistent challenge.
Solving For A Complicated Block
While you’ll have to wait to fully experience the solutions we came up with, here’s a screenshot which shows the current block design:
What these two screenshots show is a key to our approach for achieving beautiful, functional block designs: having distinct “active” and “preview” states.
Just because many pieces of data exist in relationship to a single block, the user doesn’t actually need to engage with all of those pieces of data unless they’re interacting with the block. In this active state, as seen in the second screenshot above, the block’s various input fields, datepickers, and options appear.
The preview state, on the other hand, is one explicitly focused on the aesthetics of the block. It’s in this state that we try to have our blocks match their front-end output as closely as possible, regardless of how many inputs we hide to make the design match.
This approach has helped us strike a balance of beauty and functionality in our block designs, which combine an accurate preview of the front end with an intuitive editing interface. Any additional settings are tucked away neatly in the sidebar.
Building Solutions Block-by-Block
While working through the sorts of problems described above has been difficult, it’s also been exciting! The coming of Gutenberg not only gives us a chance to revisit the user experience—it opens up new opportunities for improvement.
Some blocks are straightforward to design and develop, but we’ve learned that others will require some clever design and a significant investment of time to get right.
We can’t wait for you to try it out and let us know what you think! Be sure to subscribe to this blog and/or follow us on Facebook and Twitter so you don’t miss the announcement of when these new blocks are available.
🔔 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.