Last week, there was a bit of a stir regarding WordPress’s upcoming 4.0 release. Raelene Wilson started it off with a post about the “underwhelming” nature of the newest release, especially when looked at from the point of view of an average user. Pippin Williamson rebutted with a post on the importance of refinement in WordPress development, getting features 100% of the way there. Then came a sort of response from Chris Knowles outlining a roadmap of potentially more ambitious features.
Many oft-cited questions came up again. Should WordPress remain backwards compatible? Does WordPress need a more refined vision? Is WordPress moving quick enough? I have opinions about all of these (yes, yes, no) but what really struck me was how wide the developer-user gap is growing.
WordPress 4.0 was truly a huge push in terms of bug gardening, security enhancements, and of course, refinement. The backbone of WordPress is shifting to a full-fledged application platform, but many users won’t be able to see it as much more than a blogging platform or CMS. When you boot up a fresh install of WordPress, you’re greeted with Posts, Pages, Categories and Settings. Rather than structure data from scratch, users find themselves shoehorning existing content into old post types. The problem, to me, is how WordPress approaches content modeling. And if we want to address the concerns of our users (and not just its outspoken critics) this is a problem we’re going to have to solve.
Content Modeling Today
At the moment, the most flexible tool WordPress developers have is custom post types. That, plus some custom field data, allows any developer to completely remake the way content is modeled on the back-end, remaking the admin in the process to better suit user needs. For a lot of sites, this means getting rid of “posts” and “pages,” and creating meaningful taxonomy types, spawning many-to-many and one-to-many relationships between data types.
The key word here is “developer.” Users without at least a cursory (and lets be honest, more like intermediate) knowledge of the WordPress API will be left staring at an admin with Posts, Pages and a WYSIWYG editor. They’ll cram one or several kinds of content into Posts, another into Pages, and put all of their data into the post editor. Even if they use a plugin to more intelligently abstract content types within posts and pages, content from a macro view will still be organized haphazardly. I’ve done it myself. I’m sure we all have.
I think we have to start with the onboarding experience for users so that meaningful content types can be built from scratch. A sort of enhanced UI layer for custom post types. But how this is actually structured is an ongoing challenge.
Taking a Look at Our Neighbors
WordPress may be the biggest house on the block, but it’s certainly not the only dominant force in the CMS world. We may be able to take a cue from some our competitors.
Drupal, for instance, takes a slightly different approach to scaffolding content. Drupal tries to keep things modular, allowing users to create nodes which can be plugged into pages in any order, and extended from page to page. That being said, Drupal’s built-in content types are fairly similar to WordPress. “Article” and “Basic Page” are the two default page types, and creating new content nodes is a bit of an effort. As such, Drupal’s more modular approach is often at the expense of a steeper learning curve and a harder to understand user experience.
ExpressionEngine takes a completely different approach. EE allows users to set up “channels” of content, basically storage containers for content groups. Within channels, you can add rows of fields—similar to WordPress custom fields—and then fill that field with different content types. On top of that is a hierarchical system for adding categories, statuses, etc. By grouping content into channels instead of binding it to an individual page, content can be output anywhere, and multiple channels can be added to different pages. The approach here is to decouple content and its presentation entirely.
Craft, which is an offshoot of EE, takes this even further with their Matrix fields. Matrix allows you to easily combine content blocks, quotes, text, or images (with the ability to expand), into various pages. So each kind of content is grouped together and then added, block by block, by the user. With no WYSIWYG editor. After that, the content can be output on the front-end using a templating language. Again, a modular approach to content modeling allows for a more methodical experience for the user, and less of a chance of simply jamming in content wherever it will fit.
A New Content Modeling Approach
Here’s the thing. WordPress already has the ability to structure modular data a la ExpressionEngine or Craft. And plugins like Advanced Custom Fields have paved the way for content blocks. But this process is almost completely abstracted out in the WordPress API and remains less than accessible for the average user.
What I’m proposing is a new way for users to approach their content, starting in the admin. When a user creates a site, why don’t we allow them to choose how they want to organize their content right from the start, instead of thrusting two post types and a blog taxonomy upon them. Imagine, after the 5 minute install, you’re brought to a new screen. You can choose from a list of created content types you want to add to your site (events, slideshows, posts, etc.) or you can create your own. From there, you can optionally create a taxonomy for this content type. Think about the way Rails structure data. Certain models are described as “has many,” while others are described as “belongs to.” Events, for example, have many Venues, and Venues belong to Events. Using language like this, we can allow users to easily create the content types they want, without needing any code.
And once a site is already created, it should be easy to access this menu, and create new content types and taxonomies on the fly.
On the back-end, all we would be doing is creating new custom post types and custom taxonomies based on users input, hooking into the existing WordPress API early on to do so. That way, everything remains backwards compatible. For existing sites that are upgrading, posts and pages are left exactly how they are. And more robust content types should be handled by plugins, as they are right now.
The biggest change for a feature like this would be thinking about how the user flow is effected, and making appropriate changes to the admin base. For instance, it’s not simply about writing your first post anymore. Before any content is created, it needs to be organized, and the admin should follow. Custom taxonomies and custom post types may have to be coupled or grouped more tightly in the back-end to indicate their relation.
Maybe I’m completely off base here. This is just one man’s imagination. Maybe this is too much of a shift, and maybe it’s nowhere near where we need to be. But if WordPress is going to sustain itself as an application framework, it’s going to need to try things no one else has. It’s going to need to start thinking about users differently. WordPress democratized publishing for the entire world when it was released. It has the power to do the same thing for applications. At the moment, that power is hidden behind a wall of API hooks and functions, invisible to most users. How are we supposed to create robust applications if we’re still thinking Posts and Pages. We need to start tearing down that wall, and I think content modeling is our first bold step.
Can This Be a Plugin?
Since a few releases ago, WordPress has taken a feature-as-plugins approach to core development. If we’re going to tackle this problem, we’ll need to start there. A plugin that adds an appropriate UI layer to the existing content modeling hooks. One that provides a guided experience for new users to create structured content with just a few clicks.
Right now, I just want to test the waters, see if anyone else is seeing the same problems I am. I’d like to discuss it more with anyone who wants to join the conversation, to see if we can come up with a reasonable solution. If it fits, we could build out a plugin and test a few use cases. Maybe this is what WordPress needs. But we at least need to talk about it.
So let me hear you sound off in the comments. What do you think?
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.