A New WordPress Editing Concept: Inline Access

September 24, 2013. Mark Root-Wiley. MRW Web Design. @MRWweb. Leave a comment.

Jump to Changelog

tl;dr – Rather than editing content "inline" on the front end, let users click editable chunks of content to drill down to the appropriate admin edit page. To be clear, this is explicitly and intentionally not front end editing. Jump to Mockups

Background

This concept has been floating around my head for a while and was pushed to fruition by the Front End Editor "Feature as a Plugin" for WordPress and two amusingly-titled articles: "WYSIWTF" by Karen McGrane and "WYSIWTFFTWOMG!" by Mark Boulton.

In my work with clients, I've thought about ways to expose and explain where information comes from in WordPress on a particular web page. I had a vague idea for a concept that was finally given a name by Mark Boulton: "inline access."

Inline-access, not inline-editing

One of the other pain points of a complex dynamic website, where "pages" are created with bits of content from all over the place is "where the hell do I go to find that bit of content to edit it?"

…

Instead of inline editing of the content, why not just make the start of that journey a little easier? Why not provide a way of quickly getting to exactly that bit of content with a link?

"WYSIWTFFTWOMG!"

Too Much Focus on the Visuals

Front end editing distracts editors from the content and pushes the focus to the visual: fonts, colors, etc.

Inline editing encourages content creators to focus on the visual presentation of the desktop interface. Just at the moment when we need content creators to think about the underlying structure, we're investing in tools that obscure the "connective tissue."

"WYSIWTF"

An Existing Solution

Furthermore, WordPress already supports the editor-style.css stylesheet. While many themes don't implement or poorly implement that feature, it can address the issue of the content in the text editor matching the front end formatting when implemented correctly.

Obscuring Reality

I remain open to the possibility that small WordPress sites and minimal blogs might greatly benefit from a front end editing experience as proposed by the plugin, but I fear that it would cause more confusion than clarity for most large sites that use WordPress as a true Content Management System. Linked from Karen McGrane's "WYSIWTF" article, Jeff Eaton in "The Cost of Leaky Abstractions" nails this:

If the primary editing interface we present is also the visual design seen by site visitors, we are saying: "This page is what you manage! The things you see on it are the true form of your content."

"The Cost of Leaky Abstractions"

An Example of Front End Editing Ambiguity

Here's an example of the dangers of front end editing. Consider a website that has an inline WYSIWYG editor. An editor has just created a new Post and goes to look at their Blog (aka "page for posts"). Not wanting anyone to miss their amazing new work they're faced by a series of questions:

Depending on the assumptions of the editor, a front end editing interface in this scenario will cause more confusion than it's worth.

Primary Goals

So I've set out to propose a way to expose this complexity in a user-friendly way. My goals are pretty much summarized by something I wrote recently on my blog:

[T]here is no web page. When you look at a page in a browser, there appears to be a singular web page, but to fully control what you see you have to abandon that idea and learn to think about many sources of information flowing together to create what you see on your monitor.

"There is No Web Page"

Mockups (or: Pictures! Finally!)

The following is a first attempt at an interface for inline access in WordPress, mocked up with a site using the Twenty Twelve theme. Two new elements drive the interface:

Entering Edit Mode

"Edit Mode" replaces "Edit Page." It could possibly coexist with "Edit Page," though that functionality feels subsumed by Edit Mode to me.

The baseline state of a logged in page.

Exposing & Explaining Editable Content

All editable regions are highlighted with a dashed border. Particularly important to this concept, the post title and body are not separately outlined because they are edited on the same screen and represent a single "chunk" of content, the "A Page" Page.

With 'Edit Mode' toggled, an editor sees editable regions and basic information about the web page.

Note: My partner pointed out that it reminds her of the MailChimp interface. The interface is indeed visually-similar though the fundamental concept behind it differs in a few key ways.

Drilling Down

Hovering over a sidebar, an editor learns that it's a "Sidebar" containing editable "Widgets." (Sidenote: I think "Widget Region" is much more descriptive and appropriately location-agnostic.) Clicking the sidebar would take editors straight to the Appearance > Widgets screen. Ideally with the specific Widget Region (and Widget?) expanded.

An editor hovers over the sidebar editable region.

Edit that Widget! (Added Sept 26)

This is where many editors will have either an "Aha!" or "Oh yeah…" moment as they're taken to the Widgets admin with the widget they clicked highlighted.

The widgets admin screen with the widget ready for editing.

Return to Front End

One issue I'm less sure of is how to help people return to the screen they were on when they left the front end of the site. (Particularly, I suspect this is a thorny technical issue.) Even in this simple example in which the editor has clicked the body of the previous page, having saved a post, the Back button would require two clicks to return to the previous front-end page and could confuse editors.

An editor returns to the front end of the site.

Category Archive, Part I

The beauty of "inline access" is that it scales to more complex page types such as a Category Archive page. Clicking that block of text would take you to the "Aciform" category editing page. A plugin like CPT Descriptions could similarly extend a Custom Post Type Archive page.

An editor edits the Category Term, Slub, and Descriptions

Category Archive, Part II

Scrolling farther down the Category Archive page… Clicking the post takes you to the "Images Test" post editing screen.

Further down the Category Archive page, the editor can zoom to a post.

Alternate Concept: Element Inspector

Though I'm less drawn to it right now, the idea of an "Element Inspector"—familiar to anyone who uses a browser's Developer Tools (or Firebug!)—is another interesting way to attack this problem.

An editor hovers over the site tagline to learn where it's managed.

Moving Forward

Future Iterations

Possible ideas for future mockups and prototypes:

Implementation

Note: I realize it's a bit early to think about implementation, but here are some early thoughts for the code-inclined.

Implementation of this could be tricky and would almost certainly rely on theme and plugin authors, at least when it comes to drilling down to theme options and custom fields. If the entire concept requires theme support, a new add_theme_support( 'inline-access' ); might be needed. (Should Front End Editing enter WordPress Core, I hope it will be similarly opt-in.)

However, the actual markup used to identify editable regions and their targets could be quite simple seeing that the WordPress admin has relatively clear screen IDs. I would propose using data- attributes for it:

<div id="…" class="…" data-wp-edit="true" data-wp-edit-screen="widgets" data-wp-edit-content-id="#widget-my_widget-2" data-wp-edit-message="This widget shows the 5 most recent posts.">

The Edit Mode Info Bar will need to be filter-able and hook-able in most parts of the interface. Examples:

Other Implementations

Thanks to commenter @donnacha on WPTavern, I recently learned that Joomla 3.2 is adding inline access for Menu Items and Modules (think "Widgets"). Here's a video of their implementation (though I think it has since evolved).

Feedback

Got thoughts? Send them to info@mrwweb.com or post a comment on the blog post announcing this concept. I'm also @MRWweb on Twitter.

Mentions

I've been honored to have had this idea generate a bit of attention thanks to mentions across the web. Here are the ones I know of.

Development

I've opened a public GitHub repository for development of the prototype. Once it's mildly usable, I'll submit it to the Plugin Repository for easy installation and updates.

Changelog

Based on feedback and further thought, I'll make some changes to this page. Those changes are documented below.

References

More Stuff by Mark…

Fork me on GitHub