I think it’s safe to say that Gutenberg has been a fairly controversial product. There has been plenty of friction and anxiety surrounding one of the biggest fundamental changes to WordPress, and as the release nears, those worries are starting to surface. Regardless of the technology, I think everyone understands the core need for something like Gutenberg, which is a more intuitive and modern content creation experience.
There have been plenty of disruptions in this space. I remember first using Medium and being thoroughly impressed by how it easy it was to compose and publish beautiful content. I know there have long been desires to create layout tools similar to Wix or Squarespace that achieved the same goal. Medium was able to break the WYSIWYG paradigm that so many content management systems and blogging platforms subscribe to, which mostly revolved around their broken or hacky implementation of TinyMCE.
We’ve been happy with replicating the Microsoft Word experience for a very long time. It’s a well-established creation model that is virtually ubiquitous in document creation. The challenge has always been with the translation from creation to publication; it was always tightly controlled with Word (or Notepad, or Acrobat). With the web, we were now working with CSS, and with responsive design, fluid layouts that didn’t quite map to the Word model. There was a disconnect between what was being shown in an editor versus what was being shown on an actual webpage.
To bring some predictability to content creation, the new school of thinking revolved around the concept of blocks, or segregated pieces of content that have more predictability when rescaled or moved. Gutenberg follows in the path of its competitors by breaking out of the traditional experience and introducing an editor that allows for block layouts. But somewhere in that transition, the desire to meet the technical goal missed the overall outcome, which was to make it easier to create gorgeous content.
What does intuitive actually mean?
I truly believe that everyone wants to create a product that is easy to use. It’s much more difficult, though, to articulate what that actually means. In this context, an intuitive editor should allow a content creator to produce content with as little friction as possible. To do this (and measure it), we need to consider the following:
- What they know: a person’s previous experience using similar tools to reach this outcome impacts how they will interact with a new editor. If there are established norms and expectations of a product, those can be leveraged to reduce the time-to-outcome and control the perception of the experience.
- The context(s) in which it will be used: how and where the content will be created throughout the entire production process, which will vary tremendously. There’s a lot of complexity to this, including the phases and milestones of content creation. For example, someone may start a draft of their content on Apple Notes before transferring it to the editor. The process for creating and publishing a static page would vary even more. While it would be impossible to map and meet every context and use case, flexibility for a number of different needs, milestones, processes, and technology would be preferred to creating a specific method or pattern to meet the outcome.
In short, upon first interaction, I would want a product to feel familiar. As a product manager, I can draw on tons of user research and testing to establish how to make a familiar experience, beyond the interface alone and into the entire experience. There are reasons that Medium, Squarespace, and Wix work, but simply copying them won’t ever put a product in a position to adapt to changing user needs. Let me be clear: I don’t think Gutenberg plagiarizes these designs, but there is definitely an influence from these products. And why not? Users love them because the product solves their problems.
I’d like to note that codifying this process will always be a challenge in open source, especially with distributed volunteers. I’m not sure what product management was done internally at Automattic, but having a lead that is armed with this information aligning development and priorities would have gone a long way in ensuring that the product focused on those outcomes. Not just the position, but having transparency and optics into design materials, research, and roadmapping would have gone a long way to ensuring that everyone who contributed was keeping user outcomes and UX in mind.
Why Gutenberg falls short in UX
Gutenberg falls short in UX because it doesn’t leverage what users know. I think it is safe to assume that there is a baseline expectation for users with regards to how we edit text across devices. When we work in something like Word, it’s a freeform document that allows us to create workflows and edit or manipulate content fairly freely. This is something that is the norm on other devices with similar content, such as the aforementioned Apple Notes. You can create a perfectly formatted and semantic document with headings, lists, and paragraph text (which, for accessibility, you totally should–that’s another blog post). Or you can draft an outline and expand from there. The lack of rigidity around the workflow allows someone to make it work for them. It doesn’t force you to create content in any particular way.
With Gutenberg, you’re creating blocks with content within them. This is your workflow. Even this simple paragraph is a block. When I try to select the text within this paragraph and the previous one, I actually select the blocks themselves, not the content within. So, because this content is forced into that pattern, what I know about simply selecting text is broken and changed. It is no longer intuitive.
Unfortunately, this pattern also has some dire unintended consequences, especially for those using assistive technologies. There are standards and norms that apply to those technologies that users expect; when the choice is made to adhere to a fairly rigid content creation process, the product risks being unintuitive or unusable if it doesn’t consider those cases. There are also edge cases such as NUI, where the interface maybe doesn’t target something like voice dictation specifically, but it should behave like other similar products. If you haven’t already, you should watch Eric Wright’s user test with Gutenberg while using Dragon.
Aside: I ran into a perfect example of this when drafting this post. I tried to create a sublist in the bulleted list above, but when I hit tab, it actually switched block focus. That’s definitely not leveraging my previous experience with lists in content editors.
Why Gutenberg falls short on interface
The decision to think blocks first and content second has led to a needlessly complex interface. Each block has a massive amount of controls that are fairly overwhelming; there are controls to position the block, change the block to another block, adjust the formatting of text within, and entire sidebar section dedicated to even more block-level options. The UI controls themselves are mostly good: they work as expected, they are responsive, and they’re mostly inline with most controls that we use on other platforms or products.
But… it’s a lot of UI noise, and in my experience, having so many controls available at once leads to them being ignored in cognition. We’re looking for simple and familiar controls, and superfluous or extraneous ones will be ignored completely.
That’s also assuming that we are sighted users perceiving the interface visually. Going back to assistive technologies, all of these interface elements along with their various phases need to be relayed to users as well, which made for a frustrating experience when testing with VoiceOver.
How to fix it
This is a core product design issue that can be boiled down to this: you’re creating content, not blocks. The focus of Gutenberg should always support content creation, and blocks should be a tool to assist in that goal. When I add a cover to my post, I’m adding a gorgeous visual element as part of my story–not a block that contains that content.
The biggest change to improve the UI and UX would be to restore the freeform text behavior. Keyword: behavior. Paragraphs can be blocks, lists can be blocks as well, but that shouldn’t be something that a content creator needs to think about. The interface certainly shouldn’t make visually representing the block meta information a priority, which would cut through some of the excess controls. This would also make the mobile experience slightly less intimidating.
Does it create user outcomes?
If someone wants to use Gutenberg to publish, they’re going to find a way to make it work (albeit, with varying degrees of frustration). There are plenty of examples of misaligned design not getting in the way of determined users, but as an open source community, we should strive to collectively create a great product. WordPress is an incredibly important tool for social change, one that is relied upon by many groups that may not have the resources to create content on paid platforms. It’s imperative that we lower the barrier to entry for the maximum amount of users as possible, and I’m hoping that it can be improved with that goal in mind.