Custom Post Types, Jetpack, Standardization, and Testimonials

Update: I was wrong about a lot of this. What follows deals more with implementation, not standardization. The standardization was much easier than I thought it’d be.

Both Brian and Justin recently wrote compelling posts about custom post type standardization in WordPress, which will become more important as the platform moves further in the direction of becoming less bloggy and more websitey.

I agree with Justin that creating standardized custom post type names is easy. He’s taken the lead on an “open set of standards for the WordPress developer community on how to name custom post types as well as related taxonomies and metadata”, which I fully endorse and encourage plugin developers and theme developers alike to look over. Naming here is not difficult, and the initial CPT list-Testimonials, Portfolios, Recipes, FAQs, and Events-is something that Jetpack and others have already started tackling.

My concern lies mostly with how users will interact with these custom post types and if they serve real needs. I’d prefer to spend less time on the ones that don’t matter right now (FAQs) and more time on the ones that do (Events). Which custom post types are most important is a matter of choice, to be sure, but if we’re able to identify one easy custom post type, standardize it, and then use that process as a precedent on which to standardize all other custom post types, I think we’ll be in a good place. The alternative is to spread our attention too thin and end up in a situation where two years down the road we’re still without some really useful tools as both themers and plugin developers.

Testimonials are the easiest to address immediately, not only because their usage is hard to misinterpret but also because they already exist on and need improvement. I do not know that Automattic has either the manpower or the want to lead the way on every custom post type, and the ones that are in Jetpack were born out of necessity in the moment. All of them are stuck on V1 because they’re hasn’t appeared to be a great need to V2 them.

We can have a very quick win with Testimonials. This is what would need to happen:

  1. Install Jetpack
  2. Install and activate the Motif theme.
  3. Go to the Customizer and stare at Testimonials in confusion.

I kid with point 3, but it does underscore my belief that we should start thinking about standardization from either within the Customizer itself first or the post and page edit screen first. The moment we bog ourselves down in the data we lose focus of how we want users actually interacting with these custom post types. I think that with Testimonials we can hammer away on the version that Automattic has built, make it better, standardize everything about it (including the experience around it), and then yell from the rooftops at Automattic to either incorporate these standards via pull requests or push back with their own ideas.

Data and naming standardization will be easy here; the experience side of this will likely require discussion.

  1. What should be included in a Testimonial? Customer Name? Customer Website? Company Name? The actual Testimonial? You get the idea.
  2. What default descriptions should we give to the Customizer controls for Testimonials? Having nothing on a Customizer screen but a section titled “Testimonials” with blank boxes is scary and confusing.
  3. Should customers be customers or clients? Or visitors? Or supporters? You get the idea.
  4. What should adding a Testimonial on a post edit screen look like?

These are the types of questions I’d like to focus on when talking about standardization. The data part will be easy if we can nail down the “How will users actually use these?” part. We can start with something already done and V2 the heck out of it to make Testimonials better for all of users and also set a precedent for how the .org world should go about implementing its custom post types.

I don’t care as much about “theme territory” and “plugin territory” discussion as others; I think the lines will always be blurred and that’s okay. But I can’t wait to see a CPT-supporting default theme in WordPress, which I briefly mentioned several weeks ago on an Apply Filters podcast. The sooner we can hop on standardizing just one custom post type, the sooner we may see that happen.

Discuss Testimonials on GitHub.

Author: Philip Arthur Moore

CEO at We Cobble. We build digital products for people.™