In the last year or so, WordPress.com has been experimenting with a new post editor. As a user of WordPress.com, I clicked the add new post button and was shocked to discover an entirely different interface than what I’m used to. Continuously pushing improvements across the platform with little to no announcement and measuring feedback is WordPress.com’s signature development strategy.
Shortly after its release, users created support requests to offer feedback. Dealing with change is hard, but it’s even more difficult when it goes unannounced. After receiving a ton of feedback, the team eventually added the option for users to switch back to the classic editor. Since its launch, I’ve found myself getting used to the new editor, but there are a couple of quirks that need to be addressed.
Speed
Depending on when I create a new post, I’ll see a “beep beep, boop” loading message for a few seconds. The longest I’ve seen the message is around 10 seconds. The post editor is built on top of the WordPress.com REST API and depending on traffic, server resources, etc., the API calls take longer than normal to process.
If it takes more than a few seconds to load the editor, that’s too long. With all of the server resources that make up the WordPress.com infrastructure, I expect things to load quickly. In reality, I shouldn’t see a loading screen.
Creating Content
Since the visual editor inherits most of the features found in the self-hosted version of WordPress, writing content is generally the same experience. However, one thing I’ve noticed is that, more often than not, the text area doesn’t expand to the bottom of the page. As I fill the text area with content, it doesn’t automatically expand. A quick fix is to reload the entire page by clicking the save draft button. Once I do this, the text area expands to take up the full-height of the browser window.
Instead of having separate meta boxes for each task, some of them have been combined like categories and tags. The design of the publish meta box is a major improvement compared to the self-hosted version. It has a cleaner look and seems easier to use.
One of the things I like most about the new editor is that it’s distraction-free by default. The surrounding admin elements in the classic editor are gone, allowing me to concentrate on writing. Meta boxes are shown but I don’t see them as distractions. The new editor also doesn’t waste valuable screen real estate showing admin notices, that I still haven’t figured out how to dismiss.
API Driven Interfaces Need to be Fast
The new editor is a real world example of an alternative publishing interface built using the WordPress.com REST API. The biggest take away for me from using the new editor is how important speed is. As work continues on the REST API project for the self-hosted version of WordPress, which will likely lead to an explosion of alternative publishing interfaces, I think it’s important for developers to consider how to make things as fast as possible. It doesn’t matter how nice the interface is if the API isn’t fast enough and ruins the user experience.
After forcing myself to use the new editor for a few months, I rarely use the classic editor. It’s definitely not the ideal interface for everyone which is why I’m glad the team decided not to make it the only interface available. It has a few quirks, but for the most part, I don’t mind using it. If you use WordPress.com, let us know what you think of the new editor in the comments.
“If it takes more than a few seconds to load the editor, that’s too long.”
– heck, if it takes more than half a second it’s perhaps a bit too long for me! ;)