How can post formats be improved?

14 Comments

So far most of the criticism towards the post formats feature in WordPress 3.1 has been about the formats being a standardized list that cannot be customized. But from the perspectives of portability and usability, I would say a mere standardized list doesn’t go far enough.

The argument for sticking with a standard set of post formats is that a user should be able to switch themes without losing the formatting of their posts. There are nine new formats and these do seem to cover most uses: aside, gallery, link, image, quote, status, video, audio, and chat.

Making formats portable

But if each theme implements these formats differently does it really matter if the format terms are consistent? One theme developer might choose to take all the content for a quote post and format it as a quote. Simple for the end user, with no explanation required. The next developer might decide that doesn’t accommodate non-quote content and require the user to actually add a blockquote to their posts. What happens when a user switches between these two themes?

Image posts are even more of a conundrum. Here is what the codex says about this format:

A single image. The first <img /> tag in the post could be considered the image. Alternatively, if the post consists only of a URL, that will be the image URL and the title of the post (post_title) will be the title attribute for the image.

So the first image could, or should be considered the post’s image? As of WordPress 3.1 RC3, Twenty Ten doesn’t support this post format so I’m not sure how it would be handled in the core theme, but I can see developers implementing it in a number of ways. They could choose to simply style the image format differently, use the first image in the content, use the first post attachment, or use the featured image for that post.

For the sake of portability between themes, I think there should be some developer consensus as to how these formats should be handled functionally.

Making formats usable

Even with a set list of formats that function uniformly across all themes, is using the formats going to be obvious to end users or will they need specific instructions?

If a user wants to create a post with the image format, they aren’t going to know if they should be attaching an image, inserting an image into the content, or using a featured image. I think the usability of the post formats should be more intuitive than that!

I’m not a Tumblr user, but I did take two minutes to create an account and check out the user interface. It’s worth taking a look at, Tumblr did a great job on their UI. It is dead simple and doesn’t leave much room for user confusion. We could learn a thing or two from them.

Now I understand that post formats are just a custom taxonomy, but that doesn’t mean the formats UI couldn’t be enhanced with a bit of jQuery magic or other tricks.

Rather than trying to explain how the user interface could be improved, let me share an example that I mocked up that shows one possibility for the image format.

This interface isn’t drastically different than the standard layout, but I think more people would be able to use it instinctively without needing to guess or consult the documentation.

Let me break it down for you:

  1. Format Buttons: We don’t need big fancy buttons like Tumblr, but something with a little more click appeal than radio buttons wouldn’t hurt.
  2. Editor Title: A visual cue to the user that they have selected a new format would be a nice touch.
  3. Post Image: My first choice would be to use the featured image functionality to handle these images. This is how I am handling slide images in my plugin Meteor Slides and it has been working out very well. However this could just as easily be a file upload metabox, or instructions to attach an image to the post.
  4. Image Caption: Each format might be using the editor content differently, so clearly labeling what it is for could be useful.
  5. Streamlined Interface: Hiding or minimizing anything non-essential to a format might help reduce user confusion.

Improving post format usability is more of a long term idea for WordPress 3.2 or an ambitious plugin developer, but it’s worth thinking about at least.

Making formats more portable is something that could be be done right away though. Setting some standard best practices before developers diverge in all directions would help avoid a lot of headaches down the road.

These are my initial thoughts from trying to add post format support to a new theme I am working on. Has anyone else started implementing post formats in their themes? Please share your thoughts on how you are going to use post formats in your themes and how they could be made easier for the end user.

14 thoughts on “How can post formats be improved?

  1. Great ideas — if the point of post formats is to give authors an easy entry point to a set of common types, this kind of UI love goes a lot further toward answering “okay, but what am I supposed to do with this format thing?” than the current radio buttons.

    (But I still say the Chat format is just outright goofy…)

  2. I definately got the feeling of a Tumblr-esque feeling interface as well, but the more I play with it, the more it makes sense.

    This is going to be a big new play toy for the WordPress and theme comunity. I can’t wait to see how it’s going to be utilized.

  3. This was one of the first things I asked @nacin; if the UI changes when you select a specific post-type. Unfortunately it doesn’t and because of that I don’t see the advantages of using it just yet.

  4. This has been bothering me lately. I’ve been working on something that us meant to interact with the Post Formats API, but the lack of standardization has made it virtually impossible for my software to work 100% of the time, as different themes will probably end up on implementing it differently, and the UI is very lacking as well.

    I guess this is what happens when you design software by committee…

    • But, it’s not a UI, and it’s not intended to be a UI. It is a taxonomy that facilitates custom styling of Posts, based on the defined set of Post-content types.

      That’s not to say that, in the future, the Add Post UI couldn’t be updated so that it changes according to selected Post Format type. But, to some extent, such dynamic changes will depend on how the community settles on using the Post Format types. I think it’s unfair to blame to core devs for their inability to know the unknowable; namely, how the community will end up settling on consensus uses for the Post Format types.

  5. I’d like to see the idea of post formats extended to taxonomy formats to cover a much wider range of taxonomies.

    With WordPress now being more of a CMS there are several areas that could be improved by standardisation. I’d really like to be in a position to change themes or plugins and still make use of the data I have storted in my database without having to crack open phpadmin and alter a heap of data in my database if I switch themes.

    For instance standardisation for places and events would be useful.

    Many Premium theme shops are making good use of CPT’s in their themes. This is great for adding value for end users. It is also quite common to see these theme shops adding plugin functionality directly into their themes. This is great for endusers
    and I can see why they do it. However, it does mean that it is easy to get tied into a particular theme or plugin.

    With so many plugins/themes out there it is diffult to decide which one to pick and
    which ones are still going to be around in a few years. If some standards could be adopted for describing certain types of data then it would means you could switch between different events plugins/ themes more easily.

    I sort of see it as being similar to splitting your html and css. Here is my theme and here is my data.

    It would be useful to have somewhere in the Codex where you could look up a way of describing your data.

  6. I think these are great ideas, especially the shift in the Admin Interface. However, I was hoping/wondering if anyone actually have implemented these changes? I am currently developing a few themes for WordPress 3.1+, and would very much like to force the appearance suggested above to be used as the Admin Post Interface. If anyone has implemented this, I would very much like to see how they did it!

  7. It’s pretty easy to implement the Format buttons:
    http://i.imgur.com/d6IXo.png

    Insert this into your theme functions.php:
    function admin_register_head() {
    $url = get_bloginfo('template_url') . '/css/admin.css';
    echo "
    ";
    }
    add_action('admin_head', 'admin_register_head');

    Create admin.css and add this to it:

    // http://www.thecssninja.com/css/custom-inputs-using-css

    #post-formats-select {
    height: 150px;
    position: relative;
    }

    #formatdiv input {
    padding: 0;
    margin: 0;
    height: 16px;
    width: 16px;
    float: left;
    position: absolute;
    left: 0;
    opacity: 0;
    }

    #formatdiv input + label {
    position: absolute;
    background-repeat: no-repeat !important;
    background-position: 0 0;
    width: 50px;
    height: 5px;
    display: block;
    padding: 0px;
    padding-top: 45px;
    text-align: center;
    }

    #formatdiv input[type=radio]#post-format-0 { top: 35px; left: 28px; }
    #formatdiv input[type=radio]#post-format-aside { top: 35px; left: 93px; }
    #formatdiv input[type=radio]#post-format-image { top: 35px; left: 158px; }
    #formatdiv input[type=radio]#post-format-audio { top: 35px; left: 223px; }
    #formatdiv input[type=radio]#post-format-video { top: 110px; left: 28px; }
    #formatdiv input[type=radio]#post-format-quote { top: 110px; left: 93px; }
    #formatdiv input[type=radio]#post-format-link { top: 110px; left: 158px; }

    #formatdiv input[type=radio]#post-format-0 + label { background: url(icons/format-text.png); top: 10px; left: 10px; }
    #formatdiv input[type=radio]#post-format-aside + label { background: url(icons/format-status.png); top: 10px; left: 75px; }
    #formatdiv input[type=radio]#post-format-image + label { background: url(icons/format-image.png); top: 10px; left: 140px; }
    #formatdiv input[type=radio]#post-format-audio + label { background: url(icons/format-audio.png); top: 10px; left: 205px; }
    #formatdiv input[type=radio]#post-format-video + label { background: url(icons/format-video.png); top: 85px; left: 10px; }
    #formatdiv input[type=radio]#post-format-quote + label { background: url(icons/format-quote.png); top: 85px; left: 75px; }
    #formatdiv input[type=radio]#post-format-link + label { background: url(icons/format-link.png); top: 85px; left: 140px; }

    #formatdiv input[type=radio]:checked + label {
    background-position: -100px 0 !important;
    font-weight: bold;
    }

    #formatdiv input[type=radio]:hover:checked + label,
    #formatdiv input[type=radio]:focus:checked + label,
    #formatdiv input[type=radio]:checked + label:hover,
    #formatdiv input[type=radio]:focus:checked + label {
    background-position: -100px 0 !important;
    }

    #formatdiv input[type=radio]:hover + label,
    #formatdiv input[type=radio]:focus + label,
    #formatdiv input[type=radio] + label:hover {
    background-position: -50px 0 !important;
    }

    #formatdiv input[type=radio]:active + label,
    #formatdiv input[type=radio] + label:hover:active {
    background-position: -100px 0 !important;
    }

    And here’s the psd file for the format icons: http://www.mediafire.com/?1jhwhsuvtmmdcry

  8. I’m really hoping WordPress will create something like your mock-up..

    I could create something like that on my own.
    But i’m affraid at the moment.
    And just because of the fact that when i create it wordpress will update there core again and have build it diffrently.

    That’s also the reason why i’m not using post formats yet.

Comments are closed.