Back in June, I reviewed an experimental plugin by Christopher Finke called Inline Preview. Since that post was published, Christopher has made a number of improvements to the plugin. Now when you publish a post, the WP Admin slides to the left with a shadow bar in the middle, and the content on the right. There’s an X near the top right corner of the page that exits out of the preview window.
Christopher has now taken things one step further by creating a feature request using his inline preview plugin which falls in line with the new approach of features as plugins first. In the ticket, he lists pain points in previewing a post and suggests returning to the way in-page previewing used to work in WordPress but give it a facelift.
When I tested the new plugin version on my local install, I loved the way it worked. It’s quick and the bar to adjust the size of the preview pane is a nice touch. I think the adjuster could use a more defining image instead of a vertical shadow. Something like a little grey bar with arrows on each side telling the user that image can be moved left or right. As listed in the likely candidates for improvement, the X button could use some work although it works just fine as it is. Although the preview pane does not update in real-time with edits made on the Post Writing screen, each time an auto-save or revision occurs, the changes are automatically updated within the inline preview.
One of the biggest challenges to having something like this in core is making sure it’s compatible with as many themes as possible. While using it here on the Tavern, I noticed it shrinks the text on the website almost to the point where it’s hard to read. The other challenge is performance. Using the tavern theme as an example, there is a significant delay when trying to adjust the width of the inline preview box. It’s not as smooth of an experience as it could be. In fact, the type of delays and performance I’m seeing is similar to the widget administration page.
I reached out to Christopher Finke and asked him what his best argument was for including Inline Preview to the core of WordPress;
The best argument for adding inline preview to core is that it improves the current multi-step and disjoint processes of editing and previewing a post by combining them into a single seamless action of post creation. Users could switch from the mindset of “Edit, preview, edit, preview” to just “Write.”
However, when I submitted the ticket, I wasn’t aware of the possibility that front-end editing will be a feature in WordPress 3.8: http://make.wordpress.org/ui/2013/09/14/front-end-editor/ If that is the direction that WordPress is going, then radically changing the backend editing process may not be a priority.
If you’re interested in seeing something like this be added to the core of WordPress as I am, you should download the plugin, test it on your site with your design and give feedback in the Trac ticket.
Interesting plugin and I like your suggestions for improvements, Jeff.
I know I’m not the first to point this out, but it’s always worth remembering that these previews are still only a preview for a certain width/screen/device//browser/use/etc. That’s always a limitation plugins like this will hit.
For both this plugin and the Front End Editor plugin, I personally still wonder whether either would be as necessary if theme authors spent more time making accurate editor-style.css files. If the primary problem is that text is the wrong font/size/color, WordPress already has a way to handle it.
If this plugin is particularly good for something, it does solve the issue of previewing shortcodes.
It’d be interesting to see a similar plugin that tried putting the preview in a third tab of the editor (i.e. “Visual,” “Text,” “Preview) a la GitHub’s comments.