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
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.
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:
- If I add "[NEW!!!]" to the Post's title on the Blog page, does that change the title on the post itself?
- Similarly, what about the Post's title in the "Recent News" widget on the home page?
- Why is there a post above this one if it's the most recent post? (Answer: The post above it is sticky.)
Depending on the assumptions of the editor, a front end editing interface in this scenario will cause more confusion than it's worth.
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"
- Rather than build a new, parallel editing interface, expose the existing interface on the front end of the site (i.e. Help editors understand what is coming from where).
- Quickly allow editors to drill down to the various edit screens for the myriad web page types on a WordPress website, thereby simultaneously strengthening knowledge of the admin interface. (I'm almost tempted to say that the goal of this hypothetical feature is to make itself unnecessary!)
- Expand basic users' knowledge of WordPress's capabilities, hopefully encouraging use of more advanced features such as Taxonomy Archives, Attachment Pages, etc.
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:
- The "Info Bar" — Sister of the Admin Bar, provides contextual information about the page.
- Edit Mode Tool Tips — Label specific editable "chunks" of content when hovered.
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.
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.
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.
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.
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.
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.
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.
Category Archive, Part II
Scrolling farther down the Category Archive page… Clicking the post takes you to the "Images Test" post editing screen.
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.
Possible ideas for future mockups and prototypes:
- While I think it's important to represent posts as a single editable "chunk", I would be curious to see whether individual fields—Title, Body, Excerpt, and Featured Image in particular—could be labeled to further show how a web page is assembled. Something akin to the "Element Inspector" concept above may address this problem.
- Comparing widget-specific editing to sidebar-specific editing. The current mockup doesn't imply a choice and I'm not sure which is better or more consistent with the overall concept (I lean toward sidebars).
- Further development of the admin screens that proceed an editor clicking an editable element.
- Additional contexts and use cases (meta data, post type archives, highly-customized front page), handling of custom fields and site options.
- Because this feature has a strong educational component, it might prove a natural fit for use with the Pointers API. (Though that API has frustratingly never been explicitly blessed for use outside of Core.)
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.">
data-wp-edit— Denotes an HTML element that contains an editable piece of content.
data-wp-edit-screen— The Screen ID for the admin page on which the element is edited.
data-wp-edit-content-id— An element ID on the specified admin page that could be used to target/highlight the editable element (i.e. a specific widget or field).
data-wp-edit-message— Optional additional context message for the element's Edit Mode Tool Tip.
The Edit Mode Info Bar will need to be filter-able and hook-able in most parts of the interface. Examples:
- On the "Category Archive," a plugin could add additional post types and the Info Bar should reflect that.
- A theme author could add a description of a particular Page Template's purpose or output.
- The Jetpack Widget Visibility module could label widgets that are conditionally displayed.
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).
Got thoughts? Send them to [email protected] or post a comment on the blog post announcing this concept. I'm also @MRWweb on Twitter.
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.
- A new WordPress editing concept: Inline access," September 26, 2013. Post Status.
- "An Interesting Concept for Front-End Editing — Inline Access," October 3, 2013. WP Tavern. (WPTavern posts are included in the "WordPress Planet" feed which means the article shows up in the "Other News" Dashboard Widget on many WordPress sites.)
- "Another idea that will appeal to our customers: WP Inline Access," October 4, 2013. dev.wpzlecenia.pl. (In Polish, English title is from Google Translator.)
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.
Based on feedback and further thought, I'll make some changes to this page. Those changes are documented below.
- Sept 26, 2013 – MP6-ifying all screenshots. Because.
- Sept 26, 2013 – Added new "Widget Admin" mockup and made text changes to clarify behavior following clicking a widget.
- Oct 4, 2013 – Added "Other Implementations" section about Joomla 3.2.
- Oct 4, 2013 – Added "Mentions" section.
- Oct 4, 2013 – Added "Development" section.
- "WYSIWTFFTWOMG!" by Mark Boulton. September 3, 2013
- "WYSIWTF" by Karen McGrane, A List Apart. May 2, 2013.
- "Inline Editing and the Cost of Leaky Abstractions" by Jeff Eaton, Lullabot.com. December 11, 2012.
- "There is No Web Page" by Mark Root-Wiley. September 23, 2013.
- Front End Editor announcement post on make.wordpress.org/ui/. September 14, 2013.
More Stuff by Mark…
- Feature a Page Widget — Shows a summary of any Page in any sidebar.
- Post Status Menu Items — Adds post status links—e.g. "Draft" (7)—to post type admin menus.
- Advanced Custom Fields Repeater & Flexible Content Fields Collapser — Easier sorting for large repeated fields in the Advanced Custom Fields plugin.
- The MRW Web Design Blog — Posts about nonprofit websites, WordPress, and website best practices.