* A nod to Scott Berkun, author of The Year Without Pants, a tale of a man’s year of adventure in the WordPress jungle
We can’t solve problems by using the same kind of thinking we used when we created them
– Albert Einstein
One of the reasons why Ephox leads the web-based editing marketplace is because of its commitment to innovation. Our strength comes from the design-led approach we take to product development. Here at the Engineering and Design Lab in Brisbane, normal practice includes challenging ourselves to experiment with ground-breaking ideas, such as rethinking the editing experience on mobile devices.
Earlier this year, we officially joined forces with Automattic to work on the future editor for WordPress.org as part of “Project Gutenberg”. Finding a way to integrate and add value to a vibrant open source project is not an easy task. So, we did what we would normally do in these situations: we set up a 48-hour design challenge and jumped right into the deep end.
In this post, I tell the story of what we did and what we learned along the way.
The Design Challenge: Create a visual hierarchy for toolbars
[Gutenberg] will endeavor to create…an experience that makes writing rich posts effortless.
– Matt Mullenweg
The challenge we set for ourselves (super shout out to @jasmussen, @mtias, and team!) was to evaluate the Gutenberg designs and see if we could push the boundaries in any areas we thought could improve. The first place we looked was at existing designs, and how “effortless” the new editor experience could be to users.
These ideas led us to wonder how authors and bloggers would respond to menus that “popped-up” as they navigated through a long document during an editing phase.
Our hypothesis: Arranging block and selection level toolbars in the primary scan zone (red) in long documents will lead to visual fatigue for editors.
We proposed to test our hypothesis by creating a visual hierarchy that would reflect how often the toolbars were being used. As a result, less-frequently accessed toolbars would be moved to an area outside of the primary scan zone.
Our proposal was to move the less-frequently accessed toolbars into a less prominent scan zone (gray).
We ordered the toolbars based on how frequently we believed they would be accessed. We posited that:
- The selection toolbar (bold, italic, insert link, etc) is likely to be accessed quite frequently, so it should stay in the red zone.
- The block action toolbar (align left, center, right) is likely to be accessed only occasionally, so it should be moved to the gray zone.
- The block transformation toolbar (change paragraph to heading, etc.) is unlikely to be accessed often, so it should be moved to the gray zone.
We sketched a design for our brave developers to implement. Shortly after, we added the experiment into GitHub as Gutenberg issue #215, and set two of our lead developers @mimo84 and @intronic the task to implement them in Gutenberg…in the time of a single weekend.
The techy stuff: TL;DR It was sink or swim. We floated…
In order to implement our ideas, we needed to jump in and get familiar with the two prototypes in GitHub: TinyMCE-multi and TinyMCE-single.
TinyMCE-single
Our first idea was called “TinyMCE-single” (view the prototype here). It uses a single TinyMCE editor to manage all the content blocks. The key difference between the current editor in WordPress and the ‘TinyMCE-single’ prototype is the look and feel of the user interface. Only the block and inline formatting options relevant to the current active block are shown. This UI is created in the browser using the same JavaScript direct-DOM manipulation techniques used by TinyMCE in the current version of WordPress.
In TinyMCE-single, one instance of TinyMCE controls the entire user interface and content of all blocks. The UI actions and content state are directly connected, and direct manipulation of the browser DOM allows it to create the UI.
TinyMCE-multi
“TinyMCE-multi” (view the prototype here) uses a separate TinyMCE editor for each block of content on the page. Each TinyMCE editor has the same look and feel as the TinyMCE-single prototype, but there are differences how the UI gets implemented. In TinyMCE-multi, each block maintains its UI independently and is built using React.
A separate TinyMCE instance for each block of content. TinyMCE uses React to separate the concerns of issuing editor commands, changing the state of the editor content, and responding to those changes by triggering render functions to update the rendered UI.
What we did: TinyMCE-single + React
In addition to testing out alternative UI design, we took an opportunity to explore a technical approach that could splice together the strengths of both prototypes. We figured that finding the middle ground between the single-editor-instance of TinyMCE-single and the React UI components of TinyMCE-multi, would be our fastest way to deliver on the challenge we set for ourselves. To view the TinyMCE-single + React prototype, click here.
Reusing the editor component from TinyMCE-multi, we wrapped it in a new component which contained the React UI components and used React-redux to manage the UI state.
In TinyMCE-single + React, we use React to separate the concerns of editor actions, state transitions, and UI rendering. In contrast to TinyMCE-multi, we used a single TinyMCE editor instance to manage multiple block types.
We wired the TinyMCE event handlers to React-redux state-transition actions, and connected the rendering UI to the reflect the state transitions. We assigned the codename Turducken to reflect the ‘React-redux-inside-TinyMCE-inside-React’ architecture. Also, it was late and this made us laugh 🙂 Turducken abstracted the UI from the DOM events and mutations, making the code simpler to understand and quicker to iterate. We also used CSS Modules to isolate CSS styling, making it easier to integrate the styles with the code.
Our takeouts (…other than pizza)
From a technical perspective, we found React architecture to be highly suited for fast prototyping. It is important to note, when we started the challenge we were completely unfamiliar with the codebase. We based our experiment on TinyMCE-single (a shout out to @iseulde and team!) and were able to reuse a lot of code from TinyMCE-multi, including the React wrapper for TinyMCE (another shout out to @youknowriad and team!). We also reused many of the UI components from TinyMCE-multi, but composed them differently to meet the alternate UI design we were testing.
We did not get our experiment to prototype feature completion in the weekend, but are working towards that. Once complete, we will put TinyMCE-single + React through a battery of user tests using the master user test instructions (a shout to @karmatosed and team!).
We look forward to sharing the results. Maybe over a slice of pizza.
