Post Formats UI Update, 3/14
As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UI/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help 
UI / Administration
Main ticket: #19570
@melchoyce refreshed the layout wireframes and we ran them by @jenmylo for a gut check. The wireframes linked are for reference to see progression – quite a bit will be different, notably that the collapsing content editor will not actually do that and we probably won’t be able to get so adventurous with the status format. We are going to do the following and should aim for a commit addressing a good portion of this in the next several days:
- Remove the separate meta and field display for the image and gallery formats. Though it’s nice to guide a user through via UI, the image format did not really pose any issues in the user testing, and the whole uncoupled multiple gallery shift in 3.5 makes a separate field less sensible. With good parsing, just the content area should be enough for both. Image also still has the featured image metabox, which is confusing. One thing that we should try doing is having the “Add Media” button open the modal in the “Create Gallery” panel by default if in the gallery format. Knowing about galleries at all was an issue in user testing, not related to the post format.
- @lessbloat proposed a dropdown selector, in these mockups placed by the title: http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/#comment-8182. Anything is better than tabs for this interaction, and I’m sorry that I used them even temporarily as they clearly became a distraction, so we are going to keep the dropdown idea, but try putting it where the screen icon is, per suggestion from Jen.
- @melchoyce is making some changes to the icons she’s been working on: http://core.trac.wordpress.org/ticket/19570#comment:78. The standard post icon will be the pin, the gallery icon will become the image icon (since images are not necessarily photos), and the gallery icon should be something like the image icon with a stack behind it.
- @lessbloat is going to experiment with what can be done to make TinyMCE less intrusive in some formats where it’s not as much of a focal point, such as quote, audio, and video. Have warned him about what it means to re-initialize TinyMCE, but teeny mode seems that it would be ideal, and perhaps hide the Add Media button / move it into the TinyMCE toolbar instead, especially for the audio/video formats, so it doesn’t confuse the user as to what they should be using for which.
- Title should be somehow de-emphasized for some formats: aside, status, and image come to mind. A toggle to edit comes to mind, maybe like the way permalink slugs are edited. Titles need to be filled in based on content for those formats, a la P2. Might be nice to try to do something smart with image, like detecting an alt or title attribute for the fill-in, but at the very least, something better than (no title) or Auto Draft. This is less important for a second commit, but needs a body.
- Audio and video should have inline previews, whether it’s of oEmbed response, rendered HTML (sanitized per user cap, of course), or a media library item. We should hook up the media modal if possible, especially with the insert from URL panel. Related: #15490 (see farther below for more details on the ticket). Needs a body or bodies.
- Screen option: no longer sure we actually need this with the less obtrusive dropdown for format selection, but if we keep it, it should just hide the switcher.
- No-JS: probably means a select dropdown (which should be the non-visible input that is changing with JS on) with a submit button next to it that saves a draft with that format, which will thereby change the screen once it loads again. Not sure what that means for a published post, though. Ideas about execution in that regard are very welcome. Needs a body or bodies.
- Accessibility: need to check on ordering when tabbing through fields and make sure things like labels are done correctly. Also should make sure the switcher is accessible. Needs a body or bodies.
Other tickets and tasks:
- #23198 – TinyMCE class. @azaozz said he will take a look and get it polished and committed. Looking for it to be there on init as well as dynamically changing with the format. Hooray for editor styles
- #16047 – list table display/filtering. Once we have icons, we should drop those into place next to the post title, with each icon linking to filter the list table down to that format, and lose the column that was added. “Standard” (the pin) should not show.
- #23539 – previewing. Format should be dealt with the way category is (taxonomy); formats with meta fields are trickier to deal with given that post meta is not stored separately for revisions. Not sure where this stands.
Bonus: @ryelle is working on a dashboard widget for one-click entry into writing a post in a given format, which should help with discoverability. Have suggested that work on this be done as a plugin for a couple reasons – so patches don’t go stale and so that if it doesn’t quite make it to core for one reason or another (whether that’s functionality or decision that it’s not for core), it’s available as something usable for those who want it and/or for user testing and data collection.
Data
- #23347 — Theme fallback output. We need to remove gallery and image fallbacks along with removing them as separate meta. This needs some more work regarding more/excerpts and probably pagination as well – see http://core.trac.wordpress.org/ticket/23347#comment:41 for more details. Seems that placement before/after needs to be different per different formats – link should default to after as it is now, but audio, video, and quote should probably be before the_content. Needs a body.
- #23282 – HTML5 audio / video and #23673 — video / audio metadata. These need to drop in together, and we should do it soon and let it soak. We can test patches all day, but nothing beats getting it into trunk for a wider audience and set of environments. There are concerns about needing jQuery on the front, but in the last dev chat we decided to at least drop it in and let it soak. Needs lead dev eye and blessing for commit ASAP, please.
- #23726 — Show Audio and Video previews on Edit Attachment screen. Pretty much comes with the above.
- Provided that the link and quote formats continue to use a separate field for URL, they should probably be added to the pingback URLs. See #18506.
- Meta doesn’t delete, because it’s not passed in $_POST if empty. Likely not a particularly complicated fix.
Parsing
Tracking ticket: #23725
So many thanks to @wonderboymusic for leading the charge here. These need a commit very soon so that Twenty Thirteen can move on with practical usage. The biggest use cases are going to be image and gallery formats, as well as new theme, old data. Parsing functions will be available for use by devs, and in core should be used as fallbacks in the get_post_format_meta() function.
- #22960 — Extract images from content, attached to post, gallery, or arbitrary string. Has unit tests and patch. Needs testing and a lead dev eye and blessing.
- #23570 — Extract a URL from an arbitrary string, HTML, or the current $post. Has unit tests and patch. Needs testing and a lead dev eye and blessing.
- #23572 — Parse Audio / Video data out of arbitrary content or a post. Has patch, needs unit tests. Needs #23282 to go in first.
- #23625 — Parse chat as structured data. Has patch and unit tests, but needs to be scaled back and just allow for added formats (regex patterns) via plugins. Suggest that it just be split by lines, ignoring empties, with anything before the first colon becoming the label for that line (screen name, speaker, whatever you want to call it).
Documentation
- Will need screen help text, possibly/probably its own panel. If we keep the screen option for post formats, would be smart to hide the panel if toggled off.
- Codex will need attention. I know of http://codex.wordpress.org/Post_Formats. Seems that user documentation needs to be separated from theme dev documentation.
Otherwise related
- #15490 – oEmbed preview for insert from URL in media modal. We found in user testing that users go back to this panel for all sorts of things, including YouTube URLs and the like. There’s a working patch from @jtsternberg that could use a little finessing. The Ajax action is probably going to be helpful with audio/video inline previews on the edit post screen.
jltallon, 
Luke Gedeon 3:32 pm on March 15, 2013 Permalink
“Add New Post: Status” in the refreshed layout wireframes shows permalink above status field (Hey User, what’s up?) and has no title. As a user, having the status field above permalink feels more natural.
As a dev, I wonder if we could use the Title field to capture the status instead of a custom field. This would allow normal processing to generate the permalink and put the order of fields into something closer to what a user might expect.
When generating output for a status it “might” be preferable to hide the title even in themes that don’t recognize post formats. If that is case, core could return an empty title and the status stored in title as content. My preference would be to receive the status as a title anyway, since that would look best in most themes I have looked at.
Helen Hou-Sandi 7:13 pm on March 18, 2013 Permalink
Status is not a custom field – it’s post_content. I don’t think we’re going to be able to get so adventurous with the status format edit screen layout – it’s quite likely that it’s going to just look the same as aside – title optional (toggle or otherwise), regular editor area. I also don’t think core should just turn titles off in a theme – that’s completely up to the theme to decide. A theme may very well use the_content in a way that looks like a title – 100% presentation layer, not data.
Dravel 5:27 pm on March 15, 2013 Permalink
As a regular “John Doe” user of WordPress I must say that the plan of ditching the tabs in favor for the drop down thingy from @lessbloat is a major disappointment. The tabs were a new fresh style (needed one to) to a stale design part of post area itself.
Reverting to a style that best described as 1995-ish when we are in fact roaming in the year 2013 is a huge step back, not to speak of the user unfriendliness the current iteration presents (http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/#comment-8182), that little blob before the “Enter title here” does in no way even hint that there’s option’s lurking there. As a blogger I want it easy and straight forward, not guessing around before I can actually start to write my things.
The tabs were ok and had a fresh thing to it, shoot even a vertical row of the icon’s made by @melchoyce with a sub title “Post Format” as a <h2> heading right under the “Enter title here” is way better than a obscure drop down thing, especially from a user friendly point of view.
Just 0.2 cent from a regular John Doe user
Helen Hou-Sandi 7:18 pm on March 18, 2013 Permalink
There are a lot of problems with the tabs interaction-wise. They are not adaptive to screen widths, especially smaller ones, incorrectly represent selecting a format as a primary action when in reality it is one that is performed once and then left alone, and they cause confusion among users, both “regular” and ones we tend to think of as knowing better (like the very people writing patches). Some users interpret the tabs as needing to fill out all of them rather than making a generally-one-time choice that sticks, and yet others saw ones like “Audio” and “Video” as being points for inserting media into their content. We have a lot of exploration to do, but tabs are definitely not it. Again, I regret having put them in even as temporary UI – the distraction caused has been a bit time-consuming to respond to.
WraithKenny 8:31 pm on March 18, 2013 Permalink
have you tried using the “button-group” styles? I make a quick plugin for showing what it’d look like: https://gist.github.com/WraithKenny/5190524
Helen Hou-Sandi 10:03 pm on March 19, 2013 Permalink
I don’t think buttons are the right interaction, either. The thing I want the most is for the selection/switching mechanism to get out of the way once a choice has been made. Interaction is what’s most important here; it’s not merely a matter of styling.
jltallon 1:00 pm on March 20, 2013 Permalink
From another “John Doe” user (+developer +project manager):
@lessbloat‘s proposal at the URL below is right on: discoverable, intuitive, unintrusive, practical… good.
Though I’m a bit wary of content parsing, I trust you to get it right, and the “teeny” mode will be of much help in guiding the users along the right way (input the “correct” content). Less meta is good for performance, too.
0.02€ from me
Hugh 9:25 pm on March 15, 2013 Permalink
I’m a lurker, but can someone point me to a post or discussion on the history of post formats? I am curious to know why the post formats for audio and video are not separate content types. – I’m sure there is some good thought behind this but being newish I’d just like to read why it is the way it is.
Helen Hou-Sandi 7:22 pm on March 18, 2013 Permalink
I suppose the Codex has some information about what post formats are: http://codex.wordpress.org/Post_Formats, notably “A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post.”. Separate content types (post types) would not show up in a blog archive by default and are not posts, whereas these are supposed to be posts that just happen to contain audio or video (or quote, image, gallery, chat transcript, or link). Think of post formats as a way for users to structure/think about the content of their blog posts and as a way for theme devs to be able to customize the presentation layer of a given format.
WraithKenny 8:38 pm on March 18, 2013 Permalink
“…what it means to re-initialize TinyMCE…” Is there a ticket or comment on which scenario would require TinyMCE to be reset?
Helen Hou-Sandi 10:02 pm on March 19, 2013 Permalink
Teeny mode may be more appropriate for some post formats, e.g. quote.
Scott Taylor 10:22 pm on March 18, 2013 Permalink
I am on a plane home from my Mexication – I am going to refresh my patches tonight, based on the fact that #23282 finally landed (editors note: woo hoo!). The patch on #23282 had some new functions (`has_shortcode()`, `shortcode_exists()`, `get_tag_regex()`, et al) that were present in ~5 different patches. Will also streamline any dupe’d code elsewhere among the patches that haven’t been committed. That being said , #23673 should be the next one to go in.