Johannes Gutenberg’s invention of the printing press had an amazing impact on the world. His introduction of moveable type began the Printing Revolution. I could go on about Johannes, but I wanted to focus on another Gutenberg today – the new editor in WordPress.
While Gutenberg, the Johannes kind, created a new paradigm of thinking by enabling the spread of mass communication, any change in WordPress directly effects a third of all websites in the world – also effecting mass communication to the millions of humans who read, peruse, and learn from those sites. As the world became literate and acquired published information, individual freedoms grew. No longer did the people rely on the hierarchy to interpret the text and dictate doctrine. No, the people could do it themselves now. Without sounding too grand, I’d argue that Gutenberg, the editor, is providing a near equal shift by enabling technologically-challenged people to sever their reliance on the tech hierarchy to build the internet for them.
I’ll admit, Gutenberg, the WordPress kind, didn’t invent publishing on the internet, it just revolutionized the paradigm. Similarly, Johannes didn’t invent publishing, he too just revolutionized the paradigm. Today we live in a post-Gutenberg world – two times over. WordPress, the software that democratized publishing for anyone with an internet connection, just propelled itself into the future with an adoption of modern technology that opens up the door for so many people to create under the new paradigm of blocks.
People are now creating more than just written texts to be published on the internet – they’re building layouts and stacking blocks in ways that were earlier limited for 33% of the web. Johannes may have invented moveable type, but the new editor for WordPress has given us moveable layouts!
Perhaps I’m being too extreme. Perhaps I’m reaching to make this comparison. But with this connection I’m hoping to communicate the huge paradigm shift that WordPress is exposing through the new editor. Software as old as WordPress rarely gets another chance in a world full of modern and exciting new technology. Often times, open source projects get stuck in the era from which they began. It takes courageous people to innovate for the future.
Innovation
Innovation has to happen, in all sorts of ways; good ways, defunct ways, ways that will never see the light of day, and in ways that might even be too far down the road to consider. But how does this happen?
Innovation is taking two things that already exist and putting them together in a new way.
Tom Freston
The open sourceness of WordPress is key to future growth. Anyone can download it, change it, and distribute their versions of it. It begs for innovation. The extensibility that WordPress offers through plugins is equally beneficial. If you innovate on WordPress and want to share it with others, plugins can make that happen.
In light of the Freston quote above, WordPress inherited existing, more modern software (React) and married it to the editing experience. This resulted in Gutenberg which opened up more control for movable layouts, at least within post_content, while surfacing some of the more hidden and abstract features of WordPress like shortcodes and embeds.
Innovation happened is happening. But like all innovation, there’s bumps in the road, there’s resistance along the path, and there’s course corrections and alignment opportunities to be aware of. With all this in mind, Matt Mullenweg suggested that we “Tighten Up” for Phase 2 in 2019. This doesn’t mean no new advancements, it just means we’re going to be working on key elements in Gutenberg to continue the vision. Certainly, some of the tightening up areas will be iterating upon existing UI and flows, but we’re also looking to build out core pieces of WordPress that are to become natural parts of Gutenberg. These include widgets, navigation, and theme integration.
Widgets-to-blocks. This is pretty straightforward. Just like purple is the new green from Web 2.0, blocks are the new widget. Of course blocks are more than just widgets, but every widget is really just a block waiting to blossom. The term “widgets” was quite abstract and left most of us wondering about their purpose and how they might be identified on the front-end. As blocks, widgets become much more clear in their purpose. They can extend beyond the predefined locations and as the entire site becomes a layout of blocks, widgets new blocks can integrate anywhere.
How this comes about is going to require some explorations. Will they still have their own page in wp-admin? Or will they simply be integrated into the block inserter? How will this effect the Customizer?
I’d love to see widgets completely port over to blocks, and the term “widgets” to vanish from WordPress vocabulary. It’s all about blocks now. But don’t panic, the process of widgets-to-blocks will happen slowly in stages.
Menus-to-blocks. Another term that’s causing ambiguity is “menus” which will most likely be changing over to “navigation” in Phase 2. As Gutenberg extends to become more of a site-editor, navigation blocks become a clear evolution. Currently editing menus is a disconnected experience that is cumbersome to get right. As a block, navigation can be edited visually in context to the site.
Navigation blocks are also being explored in further detail. How much of this block is controlled by the theme, and how much control is offered through the block itself? Is it a parent block with child blocks?
Like widgets, there must be stages to this implementation and much of it will rely on the evolution of themes. It’s a conversation that depends greatly on where we see themes in a Gutenberg future.
Themes integration. Themes, for WordPress users and site-builders, can provide the greatest sense of accomplishment or completely destroy the building experience. Their innovation will begin in Phase 2, but likely continue into the future. As outlined in the State of the Word by Matt, we’ll need to explore a way in which themes can register other areas of the site for Gutenberg editing.
The technical challenge here is how to bring themes (or the entire site) into Gutenberg while still remaining backwards compatible. Can a theme register only certain areas of the site for Gutenberg (ie. the post_content and sidebar) while other themes can register the entire site including the header and footer? Do themes still control a large portion of layout? Do they dictate the responsiveness of the layout?
I’d love to see themes become styles libraries and relinquish layout control to Gutenberg. This is a far away hope, but something to consider. Surely, themes can provide block templates which are pages that include block placeholders to define layout. But ultimately these block templates can be customized by the user. I can imagine Gutenberg including a block template library as well to help users get a jump start on page layout.
Bonus thoughts on Gutenberg innovation
As Gutenberg grows into a mature site building tool, new challenges appear.
Responsive layouts. Right now Gutenberg doesn’t provide a clear way to visualize and edit one’s layout in a smaller screen view. Most browsers today offer a responsive view for pages, and several website builders provide responsive viewing. Recent user research, which will be posted soon, has revealed a need for this. Several interviewees were concerned about how their site looked on mobile devices. Some expressed happiness with their theme, but felt the mobile version failed, and wished they had more control over the mobile appearance. Blocks are struggling to find solutions by offering responsive controls within the block itself. But this becomes tedious when blocks require responsive adjustments individually. It requires too many steps to adjust several blocks.
So can Gutenberg provide responsive views itself? A view that narrows the edit screen so one can see the entire page (all blocks) as if seen on a mobile device? This would allow the user to go through and make the corrections necessary, somehow, for the blocks that need adjustments. But how would this work? What sort of features do the blocks allow for in mobile views?
I’d like to see us explore responsive layouts and figure out how blocks might react and adhere to some common responsive patterns.
Grids. To maintain any sort of semblance between mobile and desktop views, there should exist a core structure for which blocks can be built upon – hey, grids. Implementing a grid structure within Gutenberg core would allow blocks to align with each other purposefully. Any user adjustments, like scaling a photo, wouldn’t be done haphazardly as it is now, the scaling would adhere to a predefined grid. Or maybe while moving a navigation block, I might see the grid appear to help guide my dragging and snap the block to another point on the grid.
This grid system, from which all blocks are aligned, could have a default in core, but allow themes to update it with their own. This would require themes registering their grid system within Gutenberg. As Gutenberg expands to site layout, grid systems can help ensure a structured appearance and provide more confidence in layout patterns. Naturally, the grid would change with responsive layouts, but still provide the purposeful alignment for blocks.
Tightening up
As mentioned above, tightening up is a big focus for Phase 2. This assumes the work of Phase 1 while iterating for improvements.
Accessibility. One thing we need to get right is a11y. The only way this happens is by including people with strong a11y knowledge into the kickoffs for each of the focus areas. This means tighter team collaborations among the WordPress community.
Pattern documentation. We want people to keep innovating with Gutenberg, but we don’t want hundreds of interface solutions that cause Gutenberg to look more like a collage of scrap material than a unified interface. The way to avoid this is to get pattern documentation published as soon as we can. Pull requests are happening for this!
Gutenberg styles. While designing Jetpack blocks for Gutenberg, I often experienced the need for styling certain HTML elements to match Gutenberg’s default appearance. Most of these were form elements. It would be great if Gutenberg provided a a clear robust, and possibly opinionated, style guide that included default styling for all HTML elements. Plugin developers and block builders could then focus more on their block’s functionality than on getting it to align with Gutenberg’s styling.
Tips improvements. There’s some tips that appear when someone fires up Gutenberg for the first time. Some user research showed that people wouldn’t necessarily read or comprehend these tips at the time of viewing them. Can there be more done here to engage the user? Maybe tips that appear in the moment of a specified action?
Microinteractions. That’s a long word for very small details that express delight and enjoyment to the user. While initial conversations have happened, it requires much more explorations. These little interactions can impact the user’s enjoyment of the product immensely.
Interface improvements. As with all software, interface iterations are always needed. Gutenberg is no different. While Phase 2 expands Gutenberg into other areas of the site, the initial UI of Phase 1 still requires adjustments to improve the experience.
Phase 2 hopes
None of what I’m saying may have a direct impact on the future of Gutenberg Phase 2, but they’re thoughts bustling around in my head. And as such I wanted to get them out and share them. I imagine great things for Phase 2 and will contribute a great deal of my time to the future of this project. Read more about the Phase 2 scope discussion. We need all sorts of help with it. If you’re interested in contributing to the project, please do so here! https://github.com/WordPress/gutenberg