Post Formats UI Update, 1/24
Apologies for the late update – helps if you actually publish the post! 
We were in #wordpress-ui due to a little scheduling conflict – we’ll hopefully be back in #wordpress-dev next week, and are sorry for any confusion.
Discussion point 1: format switcher, with an example from @lessbloat: http://f.cl.ly/items/1t09071U2v1E2x2s3X2i/post-formats.png (we would use “Standard” as opposed to “Text” for that label). We will not be blocking the current behavior/ability to just start writing a post when you enter the add new screen, i.e. no forced selection of a post format before you can start writing. There is some concern about user confusion in that one might think that you can/should specify data for multiple formats in a single post if the switcher is always viewable. A viable idea seems to be that all formats are shown when you load the add new post page, which then collapse into one item (the selected one) upon a specific selection. Editing an existing post, including drafts, will only show the one format selected. Clicking on the selected format would allow for switching of the format via a to-be-determined interaction. There’s also the idea that a screen option would be provided to turn off the switcher entirely should the user so desire, just as the “Format” metabox can be turned off now.
Action: Call for icons, one per post format. No dimensions determined yet; keep in mind that 2x versions will be needed.
Discussion point 2: data structure needs, based on this really great start on wireframes by @melchoyce: http://make.wordpress.org/core/2013/01/22/post-formats-ui-update-121/#comment-7674. Proposed:
- Media URL/embed code/shortcode (basically, text), to be shared between audio and video
- Link URL, to be shared between link and image
- Quote content
- Quote source
- Gallery, which would be a shortcode that likely needs to default to [gallery] for backcompat; would use shortcode with list of IDs for new style
- Image, which could be an attachment ID or URL (this is separate from featured image)
Sharing data fields (storage TBD, likely post meta) would mean that switching between formats that are similar in data needs would retain that field. Action: discuss proposed data structure in comments; pros/cons of sharing fields between formats, anything missed, etc. Also discuss anything related to the wireframes; @melchoyce was working on some discussed tweaks (although she may be understandably behind due to computer theft 
), and there will likely be more that we’ll want to do.
Finally, as a tightly-related item, @wonderboymusic started work on the possibility of an HTML5 audio/video player in core: #23282. Testing and feedback more than welcome.
Antonio, and 4 others are discussing. 
Marcus 3:24 pm on January 27, 2013 Permalink
imo shared data fields (and preferably stored in post meta!) is definitely the way to go whenever possible
easiest example… urls:
videos, audios, links and more formats have a url field. Much less work to grab a url and distinguish between what post format you’re dealing with rather than figuring out the post format and finding the particular post meta field to look up (assuming we’re hopefully dealing with post meta)
Daniel Bachhuber 5:32 pm on January 27, 2013 Permalink
Any talk of doing user testing with Crowd Favorite’s existing code?
Helen Hou-Sandi 6:50 pm on January 28, 2013 Permalink
Yep, I’ve asked @lessbloat to do a new round of user testing with the current interface (consisting of the radio button selection) and Crowd Favorite’s code, using a theme with all the post formats enabled. Going to test a subset, because 10 formats is time consuming.
Mike Schinkel 5:29 am on January 28, 2013 Permalink
Hi @Helen, Mockups look great. Curious though, where is URL slug field?
Helen Hou-Sandi 5:58 am on January 28, 2013 Permalink
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2013-01-24&sort=asc#m79323
Peter Westwood 4:58 pm on January 28, 2013 Permalink
Sorry about that, my fault – we have moved our Thursday slot an hour earlier so it won’t happen again!
Antonio 6:40 pm on January 29, 2013 Permalink
Talking about data structures, it is worth considering Scott Clark’s Pods plugin, an interesting example of how to build custom data structures starting from simple fields. Ok, ok, we’re talking about post formats and not post types, but when you decide to reserve certain fields to certain post formats (and, from my point of view, this is the question) maybe we’re talking about not only post formats but post types too. An idea could be to build a framework that permits the assembling of post formats starting from smaller chunks, as Pods does with content type. What do you think about it?
Helen Hou-Sandi 9:46 pm on January 29, 2013 Permalink
I don’t follow, although maybe somebody else does. These seem like simple post meta to me.
Scott Kingsley Clark 9:53 pm on January 29, 2013 Permalink
I think I understand what you mean, all I know is that as the developer of a plugin like Pods, I want to be able to hook into post formats, at least on the meta-box level to extend them. That’s a reply to the comment, this may or may not apply to the actual discussion at this stage.