Post formats are slowly dying, and that’s okay

pretty-post-format-iconsPost formats were introduced in WordPress 3.1. They were, and still are, little more than an organizational feature that allows themes to support ten custom content formats such as asides, links, quotes, video, and audio. They are just a taxonomy — similar to categories and tags — and are restricted to whatever the active theme supports.

The concept for post formats made sense at the time, though even then it was a topic of intense debate. Post formats in 3.1 were supposed to be an introduction of the feature, to be iterated on once themes began to show how they would use them. In WordPress 3.6 there was an effort to establish a consistent UI, which failed to land in core. I believe they’ve been dying a slow death ever since.

Were we just chasing a competitor?

When post formats were discussed and launched, they felt like an attempt to mimic what Tumblr was doing so well — to make it easy for end users and bloggers to create nicely formatted content for specific content structures.

post-format-meta-boxThe problem with post formats is that they have no standard user interface and there is no intuitive standard for how themes should implement storage for post format data, beyond a general recommendation that everything should be stored in the post_content. Additionally, support for post formats is primarily reliant on the active theme, and keeping post format consistency when switching themes is difficult.

With these struggles combined, post formats have faced issues on nearly all fronts: users hardly understand how to utilize them, theme authors can offer very little consistency for supporting them, and without mass adoption core developers have a hard time investing their efforts to improve the features.

There have been some impressive efforts to standardize post formats

cf-post-format-ui

Alex King’s post format UI

Alex King and Crowd Favorite created a tabbed UI not long after the feature came out, and it was the basis for the discussion for including post formats into core. But this UI required inclusion either as a drop-in to a theme — which is a bit heavy handed for a theme — or to be included a a plugin.

Under that structure, the post format UI was reliable and sufficient for client work, where a developer set it up for the client; but it’s not an effective route for mass adoption amongst users and those that want to use it with whatever theme they have.

Furthermore, it used custom fields for storage of things like link addresses and video URLs, which then would not transfer to another system or if the user decided to abandon post formats altogether.

Core post format UI during beta

Core post format UI during beta

Therefore, WordPress 3.6 post format UI faced battles on many fronts: data storage, user interface, fallback mechanisms, and battles with altogether different concepts (like content blocks, for instance).

Eventually, after much debate — and very late in the game, during the Release Candidate stage — a post format UI was removed from WordPress 3.6, with many amongst the core team basically expressing that a much more low level content problem needed to be solved.

I fought hard for it, and a lot of people put a lot of effort into it. But the result just isn’t compelling, or obvious, or any of the things that it should be. It’s not just a matter of polish, it seems to be a fundamental issue with the concept.

There were some pretty great things in that 3.6 code that would’ve been tremendous for post format support, even without a consistent UI. However, most new code was meant for that UI and was removed as a part of the revert. This included methods for automatically separating content within the UI so it can be called by themes as separate functions.

I don’t think it’s a bad thing that post formats are dying

I tend to think, looking back, that perhaps we were too strongly responding to alternative content entry methods with post formats, versus creating our own strong ideas for how WordPress can better support rich media and custom content structures.

Now, conversations are more often centered around creating intuitive UI and then worry about putting things back into the content; themes like Make and plugins like Velocity Page are good examples of these structures. Before, we were trying to extract stuff from the main content so we could use it how we want on the presentation side of things.

Additionally, I question whether the right decisions were made about structure for post formats themselves. Did we really need to restrict post formats to ten standard ones, with no supported methods for extendability? And what is the difference between asides and status? And we included formats like chat, which seems like an edge case at best. There’s little use crying over spilled milk, but perhaps in hindsight some things up front could’ve helped the feature long term.

Finally, when we can create much more unique content structures with custom post types, or simply with custom meta boxes within posts, did we really need post formats? What were we achieving by making these organizational standards?

Custom post types for things like links, videos, and audio make a lot of sense to me, and issues like including those in primary RSS feeds, in home screen feeds, and other post-esque things are pretty easy.

Alternatively, the definition of a post itself is evolving. Today we often read posts that include all types of media that is not always easy to reproduce within the confines of the_content; consider “story” style content that’s become so popular in many journalism organizations.

Post formats weren’t a failure. Investing more in them may be though.

Post formats weren’t a failure. There were some excellent theme experiments done with them; Collections comes to mind, as does Twenty Thirteen. They had promise, but it just doesn’t seem the best way forward anymore for highlighting non-standard content. I think the concept gives too little credit to content in the first place; for instance, what if a post has video, audio, and quotes? How does that fit in a post format organizational schema?

I don’t think people have to start ignoring alternative display methods for things they may currently identify as “post format material.” Creativity will and should survive with displaying post content in themes; but I don’t believe that doing it through post formats is the best way.

And if we do double down on post formats (I really don’t think we will), then there will need to be some really serious iterations on the presentation, because since inception the UI has been in no-mans-land.

I’m glad WordPress had this experiment with post formats. I think it helped evolve our collective thinking about content and the many shapes of it.

I also don’t think we should just go and deprecate the feature; I think deprecation can happen naturally, as fewer themes support post formats out of the box.

I’d rather see themes and plugins create more creative, intuitive, and eventually standard methods for highlighting all kinds of content, in a way that allows site owners to manage and access that content whether those methods are active or not.