About two months ago, I posted a proposal and mockups for something I dubbed “WP Inline Access.” It received some coverage on Post Status and WP Tavern and I presented on the idea at both the Seattle WordPress Meetup and InfoCamp Seattle 2013.
I built a functioning prototype plugin, WP Inline Access that’s now available on GitHub and the WordPress.org Plugin Repository (Link fixed. Sorry ’bout that.). Work has continued on the plugin, now at version 0.5.0, and it’s time to pause for a moment, review what I’ve learned, and look to the future.
Quick Review
If you haven’t read the original post, I’d recommend it. Here’s the short summary of the proposed feature for WordPress (or any other CMS):
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.
The best way I found to explain this is with this diagram:
The goals for the feature I wanted to build were:
- 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[…]
- Expand basic users’ knowledge of WordPress’s capabilities, hopefully encouraging use of more advanced features such as Taxonomy Archives, Attachment Pages, etc.
And the key features to do that are:
- An “edit mode” that houses all these new features.
- The “Info Bar” that tells logged-in editors meta information about the page they’re on.
- Tooltips on various editable elements of a page identifying what WordPress component they are (e.g. “Menus,” “Widgets,” etc.)
- Clickable elements on the screen that take the user to the Admin screen where they can edit that element.
Lessons Learned So Far
Having spent more time writing, talking, presenting, and building the idea, I’ve learned some good lessons (or at least clarified my thoughts).
Intended Audience
I’ve come to realize that this primarily serves new WordPress users with the “administrator” roles who have access to all the editable elements on a page. It’s doubly useful on sites that use some of the more advanced “Content Management” features of WordPress like Custom Post Type or Custom Taxonomy Archives.
The click-to-edit feature shines brightest with widgets and menus, something that only administrators have access to. ((So it’s probably no surprise that Joomla implemented this feature for “Modules” (kind of like widgets) and menus in Joomla 3.2.))
The information in the Info Bar can help all users, but I fear that without any other reason to enter “Edit Mode,” low-permission users may not take the time to use the Info Bar’s contextual information.
Even for more experienced users, I wonder if this feature can still be a time saver. No matter what, it seems that a broad swath of users could genuinely benefit from the feature, but I’m still trying to figure out exactly who gets the most value from it.
Finally, so long as the feature can be extended by plugins, themes, and custom functions (it can), the potential audience remains broad.
Flexibility in Design
One thing I overlooked in the early phases was making a design for “editable elements” that would work with any theme. This is partly an issue of building flexible and sturdy CSS, but is mostly about coming up with a design that can handle two big requirements:
- Dark and light color schemes (and everything in between)
- Large block elements and small inline elements.
What I’ve built works fabulously with Twenty Twelve and has recently come to handle inline elements, but with other themes, I suspect there are many so-far-undiscovered problems.
Lessons from Building Out the Plugin
In some ways the plugin was easier to build than I thought. After putting together a few quick helper functions to add information to the Info Bar and wrap HTML in an “editable element wrapper,” it was just a matter of filtering existing WordPress functions like the_content, wp_nav_menu, and the_tags to make them editable.
However, certain WordPress functions for outputting content are either used in too many nonstandard ways (get_bloginfo) or don’t have appropriate filters or actions to make them editable (term_description).
It also seems that some hooks before and after each post in a loop would be incredibly useful for this plugin and others.
Is there any reason #WordPress couldn't have 'before_loop_post' and 'after_loop_post' actions that run after each instance of the_post()?
— Mark Root-Wiley (@MRWweb) November 13, 2013
To-Dos
At this point, the plugin is mostly feature complete—at least as an alpha-prototype—but there are a few issues that could use addressing:
- Most importantly, the existing plugin offers no way to return to viewing the most recent front-end page after editing something in Edit Mode. I still haven’t settled on how this should work even, so building it has been on hold. All I know is that the Back button alone is insufficient.
- Grant Landram reminded me that not all users have the Admin Bar active by default. Should the plugin turn the Admin Bar on for all users when the plugin is enabled or notify them in some other way? The feature doesn’t work without it.
- Right now, there’s no handling for nested editable elements. However, a solution would be helpful. For instance, a plugin that outputs content with a shortcode could set up click-to-edit functionality in Edit Mode. A specific example of this would be forms made by Gravity Forms linking straight to the appropriate form editor.
Moving Forward
This has been fun and exciting to build. That being said, for this to be useful at all for a wider-audience I need your help. I’m at the point where I need to decide whether this was a fun experiment or something that has a future. If it has a future, is it as a plugin or something I should push for inclusion in WordPress itself? Should I jettison some features and focus on a smaller set of big value features?
Feedback
I got a lot of positive responses that were great for motivating me to initially push forward. However, “looks great!” and “go for it!” only get you so far. At this point, I need more in-depth feedback and criticism. Please take the survey below to help me get some of that feedback!
Code Review
I consider myself a good theme developer and have made small plugins, but it would be great to get other people into the code. The plugin is up on GitHub for review, pull requests, and bug reports. I know I must be overlooking things at this point. I’m at a good point to get some new eyes on what I’ve built.
User, Browser, & Theme Testing
The plugin needs to be put through the paces. That means running it in lots of browsers, in front of lots of users, and on sites with different themes. Problems can be reported on GitHub or the Plugin’s support forum.
Survey
In hopes of getting some initial answers to these questions, I’ve put together a brief survey. I think it should only take 2-4 minutes.
