Why the WordPress Front-End Editor is Going to be Amazing

WordPress front-end editor

I started this article in a reflective mood, looking back on 2014 and considering the state of WordPress. As I write the article itself, though, I’m pretty excited, and the way I’m writing it is a big part of that:

As I thought about it, I felt that the one thing WordPress still lacked was a halfway decent what-you-see-is-what-you-get (WYSIWYG) editor: something that lets you easily write and lay out posts and pages, and visualize what the result will be on the site itself.

In the process of fleshing out my thoughts on that gap, I checked back in on a WordPress project called the WordPress Front-end Editor—and discovered that the gap is already partly filled.

Before I gush about the front-end editor, let’s do a bit (edit: turned into a lot) of thinking about what WYSIWYG means, and how a good WordPress WYSIWYG editor would behave. (If you’d like to skip to the gushing, see you down there!)

Properties of a Good WYSIWYG Editor

In Microsoft Word, you’ve got almost total control over both content and presentation.

Microsoft Word is an example of a good WYSIWYG editor. Let’s look at a few things you may never have considered about Word.

First, Word is pretty easy to use. You can make things different fonts and different font sizes, put stuff in columns, drag images around, you name it—all with a simple interface that requires no knowledge of programming, or of what’s going on behind the scenes (a whole bunch of XML markup, with the Word software as the “browser” to understand and render it).

Secondly, Word is pretty consistent. When you place and format your columns, fonts, images, etc., they’ll generally stay put. And your Word document will continue to look and behave almost exactly the way it did when you wrote it, no matter who reads it (on what device) in the future.

Thirdly, when you write a Word document, the way it looks as you’re writing it is also the way the final product looks. In other words, the “Word Writer” and the “Word Viewer” are exactly the same thing.

So a good WYSIWYG editor—the kind you can build into a trillion-dollar software empire—has the following features:

  1. Intuitive interface
  2. Stable, predictable output
  3. Unified user experience: “writing” and “viewing” happen together

Clippy the Paperclip

To sum up, when you use Word, you’ve got almost total control over both content and presentation, all in one editor interface that is also the viewer you and others will use. Pretty cool, right?

Good Online WYSIWYG Editors, and Other Pleasant Dreams

What Word has done as a desktop application is very difficult to replicate online.

What Microsoft Word has done as a desktop application is very difficult to replicate online. Nothing is quite as full-featured and intuitive as Word, and the only thing that comes close—Google Docs—is only viewable in its own environment: like a Word doc, a Google Doc has to be viewed as such. What we want is a text editor that creates webpages, viewable in any browser.

That is a really difficult thing to make, for three main reasons:

  • Responsive design considerations. A page in Microsoft Word is of fixed dimensions, as determined by the creator. A webpage can be any size, as determined by the user. This means that you can’t give fixed spatial rules online—you have to think in terms of relationships between elements, which can change with shifts in the space they occur in.
  • Browser and device idiosyncrasies. There are numerous kinds of internet-capable devices, and numerous web browsers—and, although things are getting better, they still have very different behaviors and compatibilities. Every Word document is designed to be viewed in the controlled environment of Word itself; but when you make a webpage, you can never be completely sure that one device or another won’t refuse to play Flash, render fonts in its own sweet way, or even (if it’s IE) break the site layout entirely.
  • Irregularities in HTML/CSS. HTML/CSS is a markup paradigm that has developed to accommodate the types of idiosyncrasies we just described, and which carries a lot of baggage from decisions made when the web was much different than today. As a result, HTML/CSS is rife with compromises, irregularities, “hacks,” special cases, and rules-of-thumb—and that’s really hard to make WYSIWYG.

Text editors for making webpages are nowhere near as clean or powerful as Google Docs or Word.

As a result, what we’ve got in terms of text editors that generate webpages is nowhere near as clean, powerful, or easy-to-use as something like Google Docs or Word.

Instead, what we’ve got is software like…

TinyMCE (and its Discontents)

WordPress’s WYSIWYG editor is a third-party package called TinyMCE. Specifically, it’s the TinyMCE Visual editor; TinyMCE also has a Text editor that gives you access to the raw HTML that the Visual editor generates.

I’ve always been frustrated with the TinyMCE Visual editor, for two reasons. They’re the second and third criteria for a “good WYSIWYG editor” that we listed above. (TinyMCE is pretty intuitive, I’d say, so it gets a pass there.)

Error-Prone Output

The TinyMCE Visual editor often makes incorrect assumptions about the HTML markup you intend to generate.

As you write and format a post in Visual, TinyMCE starts making assumptions about the HTML markup you intend to generate, and these assumptions are often incorrect.

Worse, there’s no way to fix these wrong assumptions within the Visual editor itself. You’re just stuck with them. This is why I’ve advocated for a solid understanding of the Text editor—particularly for images and other elaborately formatted pieces of content.

Clunky Edit/View Cycles

The TinyMCE editor is completely divorced from its output.

The TinyMCE editor is completely divorced from its output: You write in one place, and you see what you’ve written in a completely separate place. (The Visual editor is a “previewer” of sorts, but it does a really poor job of predicting what your post is going to look like. I don’t even bother with it, and always view drafts to see how my posts are looking.)

Not only that, but everything’s run through PHP scripts that write to and read from the database—so checking your changes involves two full page refreshes: one of the editing window, and one of the page you’re editing. If you’re trying to see, say, how an image would look 15px narrower, or how a given word looks on the page relative to its synonym, this is an awful lot to go through.

The Overall Effect

Writing posts and pages in WordPress has always felt manageable but clunky.

TinyMCE isn’t to blame for the difficult environment it’s in: even very carefully built in-house text editors like Mailchimp’s campaign editor or Ghost’s Markdown-based post writer have many of the same problems—and even some problems TinyMCE doesn’t have. But TinyMCE does add to the pile with its Visual editor’s erratic interpretation of text content, and with its awkward, backend-based edit/view cycle.

The overall effect: writing posts and pages in WordPress (something I spend probably 20 hours per week doing) has always felt manageable but clunky, like those old cars you have to wind up to drive.

Crank car

The Absolutely Amazing WordPress Front-End Editor

I was thinking about all this stuff as I started today’s post, and I decided to check back in on a project that I knew was designed for eventual inclusion in core: The WordPress Front-End Editor plugin, under development principally by WordPress contributor Janneke Van Dorpe.

I’d tried the plugin six months ago and found it pretty completely broken; and I’ve tried other front-end editors in the past as well. Without saying that I’ve tried them all, I will say that none I’m aware of really work well enough to improve on the default WordPress editing experience.

But This Time…

But this time it was amazing. Here’s a video of me giddily writing and editing things—you can see just how easy the Front-End Editor is to use.

The WordPress Front-End Editor has made writing in WordPress fun, for the first time ever.

I’m aware that silent screencasts aren’t always the most gripping, so let me talk a little bit about my personal experience. Despite its errors and shortcomings (more on those in a minute), using the Front-end Editor to write this post has felt, at times, like writing a webpage as effortlessly as writing in Word. In other words, I can write webpages—rich, hypermedia content viewable by any web-capable device in the world—with the fluidity of a word processor.

To put it even more forcefully: the WordPress front-end editor has made writing in WordPress fun, for the first time ever. The length of this post testifies to the power of that experience.

What Can The WordPress Front-End Editor Do for WYSIWYG in WordPress?

Let’s look back at the three goals I proposed for a WYSIWYG editor:

  1. Intuitive interface
  2. Stable, predictable output
  3. Unified user experience: “writing” and “viewing” happen together

I think it’s pretty easy to see how the WordPress Front-End Editor can impact each of these three goals.

First, what could be more intuitive than writing directly to the page? Separately, the plugin in its current state has some really sweet interface decisions backing it, like its media adder popup menu:

WordPress Front-End Editor

For stable output, we have the assurance that whatever we see on the page is… what we see on the page. There are still cross-browser considerations, but there’s a lot less uncertainty than when posts are written in an interface completely divorced from their output.

The Ajax-based saving is another enormous selling point over TinyMCE.

Speaking of that, the plugin is truly beautiful in blending “read a webpage” and “write to a webpage.” Adding to the fluidity of the experience is the Ajax-based saving—another enormous selling point over TinyMCE. As we’ve covered, Ajax generally means that you can change data with no need for page refreshes: you can add and remove content, post categories, and everything else on the fly, much like quicksaving a Word doc. In long and heavily edited posts (like this one), the aggravation and time this saves is tremendous.

What It Needs

Getting the Bugs Out

That’s not to say the WordPress Front-end Editor is perfect in its current state. It’s got lots of bugs when you try to step outside the core functionalities of “adding text and images.” Embedded videos get lost; copy-and-paste sometimes doesn’t work; adding a featured image causes the page to reload (preventing it from working); changing the post title usually follows the link instead; and there’s plenty else.

As a result, I found myself keeping a “Text” editing window open; when I hit a bug I couldn’t fix on the frontend, I’d solve it in the editing window, then save and reload the draft page—certainly a flow-breaker.

An HTML Editor

The plugin’s major missing feature is an HTML editor.

The plugin’s major missing feature is an HTML editor: something that can edit HTML markup directly and serve as a usable analogue to the TinyMCE Text editor.

As we’ve discussed, the only way to fully control your post content is through an HTML editor. Without that, you can’t manage HTML classes (meaning you can’t use your CSS stylesheet); and you can’t, in general, see exactly what’s going on in your post, or make it behave exactly as you want.

All the fancy blockquote formatting in this post, for example, is CSS class-based and required the TinyMCE Text editor. The post’s numbered and unnumbered lists don’t exist anywhere in the current Front-end Editor, and had to be done in Text as well.

Moreover, even very simple things like emdashes (—) and ellipses (…) are rather difficult to add to a WordPress post without HTML control.

This is a clear need if the plugin is ever to function anything like a standalone alternative to the backend editor—which it should!

Love!

I’ve written enough software to know where these bugs and feature needs are coming from: the project needs volunteers. What Janneke is trying to do is fantastically tricky; and given how many conflicting browsers, devices, themes, plugins, and content types the WordPress post creation process touches, errors are going to crop up at the speed of light, if not faster.

There are indications that the project is on partial hold or running out of steam.

There are also indications that the project is on partial hold or running out of steam. An earlier series of weekly chats about the project hasn’t been held since September, although the plugin has been updated within the month.

It’s pretty clear that some smart, energized developers could help this project get the last way over the hump to revolutionizing WordPress, and online publishing in general. I’m going to write Janneke myself as soon as I can tear myself away from this post; if you have a tech soul and some free time, you should do the same!

Whew!

Thanks for reading! I got really excited about the WordPress Front-End Editor, and then I got really excited to actually use it, and the result seems to have been quite a lot of words. But I think this could really be a game-changer for WordPress as a whole; it certainly is for how I personally interact with WordPress, and for how enthusiastically I view the job of content creation.

Do you have thoughts about front-end editing in general, or about this project in particular? I’d love to hear them in the comments below!


12 Comments
Most Voted
Newest Oldest
Inline Feedbacks
View all comments
daslicht
September 23, 2015 5:26 am

Not working at all here :/

fee.min.js?ver=1.0.4:1 Uncaught TypeError: Cannot read property ‘getBoundingClientRect’ of undefined

???

WA_Fronted | WPShout
August 3, 2015 9:01 am

[…] editing has long been a passion of mine. I got an email from Jesper, who’s developing a new solution called WA_Fronted. One way it […]

5 Best WordPress Front End Editor Plugins to consider - 85ideas.com
July 6, 2015 7:57 am

[…] a few days ago, WPShout, a premium WordPress tutorial website discussed the future of WP Front End Editor, and I guess Fred Meyer nailed the future of front-end editor and what we are looking […]

A Prayer for the Soul of the WordPress Front-End Editor | WPShout.com
March 3, 2015 3:55 pm

[…] slow to every party, I first tested out the Front-End Editor in mid-December 2014, and wrote one of my most excited articles ever about (and with) it. However, by the time of that article, progress on the plugin had been halted; […]

Diego Rojas
January 14, 2015 3:08 pm

Hello World 🙂

Just wanted to add to the debate FrontKit, for its flexibility, I was quite impressed with the presentation by its creator Adrian Zumbrunnen in #WCEU last year. Watch the video: http://2014.europe.wordcamp.org/2014/10/23/video-adrian-zumbrunnen-rethinking-content-creation-wceu-2014/ and access http://azumbrunnen.me/frontkit/.

Regards from Brasil!

Diego Rojas
January 17, 2015 8:09 am
Reply to  Fred Meyer

Cool! Glad you added up!

David Skarjune
January 13, 2015 2:12 pm

Insightful post Fred. Over the years, we’ve been deluged with methodology for the web from User Experience to Content Strategy to Content Marketing. Nobody talks much about the Author Experience, but it does matter. Even though WordPress is the leading CMS, novices prefer a streamlined interface that includes in-context editing. However, platforms claiming that feature, like Squarespace and Concrete5, require clicking into edit mode, selecting blocks, and working with popup editors. The experience is still clicky and geeky. We say WordPress offers ease of use, but it’s a rather clicky and geeky experience, especially with custom content types and fields or proprietary theme frameworks or odd fill-in-the-form approaches via plugins and developers. Yes, these techniques can provide powerful web features, but they can frustrate users who may end up posting more timely content on their Facebook page rather than their WordPress website. The WP Front-end Editor changes all that. Van Dorpe has done a fantastic job showing how this could work. I only wish that Mullenweg and team would give this project some priority. Instead, with version 4.1 they claimed adding “a new distraction-free writing mode,” which simply streamlined the old distraction-free feature that is not in-context and never caught… Read more »

Kristin Aus
January 29, 2015 9:10 pm
Reply to  David Skarjune

Very well said, David! Since for me, those Authors who are struggling are also my clients who pay my bills, I can’t imagine anything could be more important! And yet, this plugin is listed as inactive.

I’d love some behind the scenes insight into why this isn’t a priority. What can those of us who understand the importance of this do to push it?

Fred, this is a great article! Thanks to you, I think I’ll have the nerve to try this for a couple of clients and hope I can use it for all of them. Really appreciate you starting the discussion on something that SHOULD be the hottest topic in WordPress. Ok, that’s from my perspective . . . but still. 🙂

Michael
January 6, 2015 3:25 am

I’m rather excited about this new version of the front-end editor as well. Have you seen the new Unyson Framework by the brilliant lads over at ThemeFuse? I have no affiliation with them, just a huge fan. It may be that the FEE (especially when included in core) replaces the need for such a Framework, and many of it’s features should probably be plugins. But I’ll tell ya, it’s pretty amazing.

I believe they were VERY inspired by Kriesi’s Avia Framework (Enfold Theme) and just took the ball and ran with it.

Very excited to see how these open source projects will affect the WordPress ecosystem in the coming year.

Cheeers!