Post Formats UI Update, 1/17

The post formats UI feature encompasses a couple things: the add/edit UI itself, and also what this means in terms of structured data and theme usage and expectations of data. Our goal is to make post formats meaningful and usable, because let’s face it: they’re not. What can we do in the admin to help a user understand what a given post format means and how it behaves in use, and what can we do to give themes something standardized and portable when it comes to data available for display?

Had our first office hours chat today to get started – great discussion happening on a lot of fronts, especially theme compat. We identified two distinct tasks to get us through the weekend.

The first, and most crucial piece, is thinking about/identifying what users are doing when creating a post using a post format and turning that into (likely annotated) wireframes/storyboards. That is to say – what sort of UI might we want want to see on the add/edit post screen? We’ll want to think about things like what makes it easy for a user to select a format, what a user might expect to see on the edit screen for a given format (no title, or the title is de-emphasized, or what images show in that gallery, etc.), and what happens when switching between formats. Some existing examples are CF Post Formats and WordPress.com. We also shouldn’t ignore what Tumblr does for its various formats. @alexkingorg gave us a demo link for CF and @beaulebens was kind enough to take some screenshots:

Please post in a comment here with anything you come up with. Don’t worry about anything beyond the add/edit post screen for the moment. Also don’t worry about what data exactly is or is not represented – base your ideas on user workflows. The workflows and UI will heavily influence any structured data. There are also some other things to keep in the back of your mind as possible influences for anything core UI-related: how might a layout you’re imagining adapt to various screen sizes and devices, and are there pieces that can be used as the basis for more generalized core UI components.

The second piece for now is functions (probably using regex, and I know) for pulling out relevant data for post formats as appropriate, e.g. the first URL in the content for the link format, oEmbed URL or appropriate HTML element for audio/video formats, etc. What might or might not be done with the data hasn’t been determined yet, but we can at least start here. Some existing examples are the twentyeleven_url_grabber() function and what they use on WordPress.com. Nobody has claimed this task. For now, go ahead and upload any patches to the main ticket, #19570.

There are also some related existing tickets that could use testing/+1’s or patches:

  • #16047 – separate column for post format in the list table
  • #23198 – pass the post format as a class to TinyMCE
  • #15323 – list table filter by post format
  • #15514 – add to the cat-tag convertor plugin

Read the full IRC log here.