A Case for Revisiting Post Formats UI
Post Formats were almost a big deal in WordPress, until they weren’t. But Custom Fields and Custom Post Types continue to be highly useful and used. I think it’s time to discuss a Core solution to bridge this gap.
I know, I know… this is a dead horse. But let me quote the last thing that was said about the now forgotten Post Formats UI plugin which almost got merged into Core in WordPress version 3.6:
Post Formats UI is not ready for WordPress core… We’re going to pull it out, and let it continue development as a plugin.
Source
Except it isn’t live on the Plugin Directory any longer, and its never been maintained since then.
A Little Background is In Order
Let’s back up a bit so you understand the context of this conversation. Post Formats is supported in WordPress Core. It has to be supported in your theme. If your theme supports them, you’ll see this additional Meta Box in your Post Edit screen:
Theme authors can disable this completely, or enable individual formats, or create their own formats. Lots of possibilities.
But the trick is next supporting that information in the post. Minimally, you could indicate the format just as if it was a tag or category. Alternatively, a theme author could go hog wild and support completely unique post layouts based on the Post Format. Many likened this concept to the Tumblr formats.
The trouble with how they are implemented in Core at the moment, is that they do absolutely nothing to the presentation of the content unless the Theme author takes great pains to customize them. Then additionally, if your theme took that effort and made each format look excellent, you might in a couple years switch to a new theme and if your new theme didn’t support those formats you’d lose all that effect.
Post Formats even have a slug. Like “tags” or “categories”, you can organize your sitemap around the Post Format with it’s “type” slug. For example, what if you wanted to write some posts about some Podcasts you like. You could automatically have a built-in way to display all your “Podcast” Post Formats:
https://example.com/type/podcasts
Again, if your new theme doesn’t support Post Types, then that URL would become virtually useless.
The #wpdrama
Despite the fallbacks and pitfalls, some in the WordPress community saw the potential that Post Formats had (me included). Crowd Favorite in particular had client use-cases that called for Post Formats. In this post, founder Alex King (recently deceased, a beloved member of the WordPress community) explains how they developed a unique solution to Post Formats which allows users to add Format-specific information and makes the ability to choose your Post Format much more obvious.
That original plugin exists today only on Github. It still works as expected.
As you can see, the concept predates today’s “MP6” flat admin style. But from the screenshot you can see the tabs, and in the case of the Gallery Post Format it adds a metabox before the main content area to highlight the content of the Format you are choosing.
The drama happens though when this idea gets taken up by some prominent WordPress Core contributors, specifically Aaron Campbell and Helen Hou-Sandi. Helen ended up being the Project Lead for the Post Format UI and it was all pitched as inspired by Alex King’s original plugin and concept.
The first UI mock-up of the idea was a deviation from King’s tabs to more icon-based action buttons:
In that post, Jen Mylo expressed the concerns many users had with Post Formats UI at that time. They included:
- The icons look like things you might add into the post, rather than formats to choose from
- The icons disappear when a format is chosen and a “Change Format” link appears instead adding to the confusion.
- Clicking the “Change Format” link adds the row of icons back — which adds to the confusion.
It was these kinds of confusing user experience issues which killed this feature. Well-respected plugin developers and WordPress “power users” chimed in on that post to agree that it was all a bit “confusing” and not useful.
That is what eventually led to the sad conclusion, announced by Core 3.6 Lead, Mark Jaquith:
“… the result [of Post Formats UI] 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. The release can’t be held up any longer for this. It needs to come out.
Progress Since Then
A lot has happened related to Post Formats since all of that #wpdrama. Here’s a few things that I think are directly relevant to Post Formats which changes the nature of the conversation:
- MP6 is in Core. For the uninitiated, MP6 was the “code name” for the new WordPress Admin UI that started as a plugin, and eventually became part of the whole Admin experience that we all enjoy today. I believe it’s a FAR superior Admin experience and that it lends itself to a better UI for Post Formats than what the Core devs had to work with at the time of Core 3.6.
- Advanced Custom Fields and CMB2 have illustrated how powerful and necessary custom fields are. The real power of Post Formats that Alex King proposed was how it conditionally presented you with additional custom fields to add new and relevant data for your Post Format. ACF and CMB2 have become wildly popular methods for adding custom fields to Post Types. ACF in particular even has an excellent method for conditionally display custom fields based on selections within the Page or Post edit screen. Any developer wanting more complex layouts that they can control to pixel-perfect perfection is going to lean on ACF or CMB2.
- Nick Halsey. You might not know him, but he’s a young developer who is doing some amazing work behind the scenes for the WordPress Customizer (among other things). He’s one of the Core developers who helped create the ability to customize widgets in the Customizer. Recently, he released a plugin called “Featured Audio.” The idea is simple. If you want a post to be about a certain audio clip, upload the clip and it will be added to the top of the post in a similar fashion to the featured image. Sounds A LOT like Post Formats, right!? I expect that this will soon be a “Feature Plugin;” meaning a plugin which is considered to be included in Core rather than just a plugin. That is UNLESS, we can revive Post Formats.
- Customize Posts. One of the criticisms people had of Post Formats was they just didn’t know what a post was going to look like when it was published. Well, a current “Feature Plugin” called Customize Posts is working to resolve that issue with finality. It basically allows you to customize your post directly from the Customizer. Some of you are asking “Why in the world would I ever want to do that!?” Well, because you want to see what your post looks like live without having to publish it and go “Oh crap! That’s not what I wanted!” Now imagine changing your post content AND changing it to a Video format instead of a Standard format, and seeing that happen with Live Reload. That’s hot.
Time to Revisit Post Formats
Now that we’re all caught up, all I’m really advocating for here is to revive Alex King’s original concept for Post Formats. What’s amazing is you can install that plugin today, customize your theme a little, and it works incredibly well and has a much better UI/UX than what was proposed for WordPress 3.6.
For example, here’s an audio Post Format in the Admin UI using Crowd Favorite’s original plugin.
And here’s a potential view of what the Audio Post Format could look like using Twenty Sixteen (and one of my custom color schemes I’m adding into Beyond 2016).
I believe this has huge potential for WordPress Core and the way that users everywhere publish their content.
I don’t think I’m alone either. I suspect that Matt Mullenweg agrees. Conspicuously, Mullenweg has been using the Twenty Thirteen theme on his own personal website since WordPress Core 3.6 launched and uses the Post Format feature extensively and effectively.
Additionally, Helen Hou-Sandi — who led the failed Post Formats UI Project for 3.6 — is also the Core Release Lead for WordPress Core version 4.7. She recently wrote this post saying that she really wants to take the backend/frontend cognitive dissonance seriously and take steps to resolve that for users. She doesn’t mention Post Formats by name at all, but I believe this is a compatible feature for the goals she lays out to resolve in 4.7 for the “disconnect” that users currently experience when publishing via the WordPress backend.
In summary:
- There’s still great usefulness in the Post Formats concept, as most developers who worked on it recognized.
- The problems that arose during Core 3.6 are virtually removed by just sticking to Alex King’s original concept by leaning more on tabs rather than icon buttons.
- The new Admin UI (MP6) is much more aesthetically pleasing and suits this feature much better than the previous.
- Use-cases like what Crowd Favorite had at the time, and Matt Mullenweg’s personal blog show there’s still great ways in which this can be implemented.
- Helen Hou-Sandi wants version 4.7 to help bridge this cognitive dissonance, and this can help enhance it.
- The new Customize Posts feature plugin could be a boon for Post Formats as well, allowing them to be live previewed directly in the Customizer.
All of this together suggests to me that the time is ripe to revisit the Post Formats discussion.
Post Formats is a great feature! We build themes with heavy orientation on post formats and we use ACF with conditional logic. I support the idea of redesign the formats UI though.
I 100% agree we should revisit Post Formats in general. The way they are implemented now is problematic. However, there are valid reasons why the Post Formats UI was scrapped, mainly that end-users found the design and functionality profoundly confusing. We did some independent user testing and had UX experts look at it. The resounding response was “this is neither communicative nor functional.”
The issue with Post Formats goes further back than the UI: The formats themselves are somewhat arbitrary (how often have you felt a burning desire to post a “chat” post?), and their implementation in the UI was a clear attempt to compete with Tumblr – a then competitor to WordPress.com. I think if we are to move forward with this project, we first have to go back and look at the idea of Post Formats – what are they, who and what are they for, and what do they do – before we restart the UI process (which is at the very end of the chain). Here are three main issues I think need to be part of that discussion:
1. The purpose and functionality of Post Formats
Right now, Post Formats is a rigid list of somewhat arbitrary types, many of which seem irrelevant to most users, some of which have ambiguous definitions (in particular, the Image format). We should revisit the list, find out what types of formats are needed to serve the end-user, and exactly what these formats should do so they behave consistently across all sites where they are used. In short, we need different formats, and firm and unambiguous definitions of what each of the formats should do and how they are implemented in themes. In that process, we also should have a conversation about whether Post Formats should be extensible. Right now, they are not. What were the reasons for this? Have those reasons changed? Should they be? What would that mean for implementation and support?
2. Post Formats theme support as progressive enhancement
One of the major UX issues with Post Formats UI (apart from the actual UI, which had serious problems) was the fallback functionality. When a theme did not support Post Formats, added field data like videos, images, etc, was appended at the bottom of the post. This is what’s called “unexpected behavior” that causes confusion for the end user, and it is also a problematic implementation in terms of content hierarchy as one would assume specifically featured content like images, video, etc would be at the top of the priority list. I think this particular problem arose because the lack of Post Format support in themes was treated as a graceful degradation issue: When they are not supported, WordPress gracefully degrades by placing the content on the bottom of the post. Moving forward, I would urge Post Formats implementation to be a first level citizen in WordPress core, with standardized implementation regardless of theme support. Advanced theme support should be a progressive enhancement to extend and improve that functionality. This, combined with clear and unambiguous guidelines for implementation, will ensure consistent behavior across themes.
3. Extensive end-user testing and consultation with UX experts on implementation
The final nail in the original Post Formats UI experiment was user testing. The implementation was confusing, communicated its intentions badly, and broke a long list of UX and UI conventions. Furthermore there was not enough user testing during the build process – something that may have solved the problems before they became big enough to warrant the removal of the entire project. Moving forward with this project would require extensive outreach and testing with the end-user of WordPress – the people who use WP every day but don’t participate in forums, dev chats, events, and so on. They are the ones who would use the formats the most and be most impacted by their inclusion. In that process we should also consult with UX experts to ensure the implementation is in line with modern standards. This extension of WordPress’ UI and functionality is non-trivial and requires a significant shift in the mental model of the people who use WordPress. For it to be successful we need a solid foundation of understanding of these people; how they understand the concept of a “post” and what a “post format” should do, what their expectations are for this feature in terms of behavior and display, and how they would implement such a feature in their process.
So, by all means, let’s press the Reset button. But let’s reset all the way back so we provide a tool that works for the people who use WordPress, not just a tool that brings us up to competitive parity with a service we are not competing with.
I may not have a burning desire to use the chat post format, but I use the status post format extensively as part of backing up and displaying my tweets on my own site. Own your own data FTW. I also use the link post format extensively as part of an internal application that allows me to have an instapaper-like experience, since standard Instapaper, Pocket, ETC., are inaccessible, and I need something to act as a catch-all for notes/links when a plain text editor won’t do. Because post formats exist, I didn’t need to create a custom post type to hold this data.
Agreed with all that. I’ve always had post formats in the back of my head.
One of the reasons is that some themes do use it. Some themes use it really well (front-end wise), but the back-end part sucks really, really hard.
I actually have a site for which I’m locked with the current theme because of post formats. I change the theme, I end up with my format-specific content unusable, hidden in arbitrary post meta.
Also, as I said above, some themes really shine with post formats. Posting a simple video or a photo gallery can look absolutely gorgeous. Something that can’t be done with one “do it all” format.
I’d be very much interested in working with post formats.
A small set of standard post formats (with accompanying UI) along with the ability to create your own format (and accompanying UI) would be ideal, in my opinion.