 | siobhyb on JSON REST API |
| siobhyb on OPW Introduction – Hello… |
 | Dan on JSON REST API |
 | tuyendart on JSON REST API |
| Tips Tuesday – Relea… on Summer of Code Revisions |
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 
First run commit, mostly for soaking of functionality, went into trunk on Monday. This includes fallback output for theme compat and fields in the admin. The admin UI does not represent anything final – especially of note is the tabs, which are essentially the way they are in order to reuse CSS and avoid adding temporary code to core.
Also of interest is #23282, which adds audio and video players to core to handle those post formats (and optionally be used anywhere else).
Good call, I keep forgetting to loop back to that.
Is it final that mediaelement would be used?
I’m hoping that other systems other than medialementjs will be considered. Another ‘top” Option is definitely mwEmbed by Kaltura https://github.com/kaltura/mwEmbed
Licensing?
All mwEmbed code is released under the AGPLv3 unless a different license for a particular library is specified in the applicable library path
*I’m sure it could be adjusted if necessary
Also, spend a few mins on the git site. Check the level of work put into this project over the years as one of the top active code sets on git. Then do a little digging into who kaltura is, (if you have watched a movie on an airplaine in the last few years, then odds are, it was built by kaltura). Bottom line, kaltura is one huge beast that would benefit both WP and Kaltura.
Just a question,
For the meta field Image, will only attachment ID work, or if in a theme we are saving URL of the image in the “_wp_format_image” field, once WP 3.6 is released, will it work?
A URL will work – the media modal just hasn’t had that panel added yet.
@helen,
Currently the URL field for formats such as Link, Image & Quote is saved as _wp_format_url. Is this approach final? Or there is still chance of this being changed?
It shouldn’t really matter to you if the meta key name changes or not – we’ve already introduced get_post_format_meta() as a helper retrieval function. It might be helpful if you could explain why you are asking these questions.
Hi Helen, since a year or more I have been using CF-Post-Format plugin which has different URL meta fields for Link & Quote format. I run a WordPress network and to avoid changes to my new themes in future, I am trying to follow the meta_key name based on WordPress 3.6. This will ensure I just have to remove the plugin when 3.6 is released.
I also wanted to make a suggestion about Gallery meta box. Can you please let me know the best place to make that suggestion?
We’re in active development – I would not change anything you are currently doing yet. You can make your suggestion here or on #19570.
Is there any planning to make filter and action hooks so we could be able to create our own new types of posts?
No, post formats are not extensible and we will not be changing that.
I added a bunch of related tickets to for the default themes:
Twenty Ten: gallery post format – #23617
Twenty Eleven: gallery post format – #22907
Twenty Eleven: link post format – #23618
Twenty Thirteen: link post format – #23619
Twenty Thirteen: video and image post formats – #23620
Twenty Thirteen: gallery post format – #23621
Seems like only Twenty Thirteen will need add_theme_support( 'structured-post-formats' ); at this time.
Played with another design for the post formats selector this morning.
Have a look:
On load 
Active 
Formats without a title 
I figured it would be fairly discoverable, much less in your face than tabs, and work well for accessibility.
Thoughts?
I’m a fan. Agreed, much less in your face than tabs. Discoverable but out of the way.
+1 from me for the cleaner interface. The tabs take way too much screen space and will surely just irritate bloggers who don’t use this aspect of WordPress.
I really like this a lot. It fits with the existing UI much more seamlessly and it’s discoverable enough while not completely taking over the post editor like the tabs.
Not a whole lot to discuss today – working away at patches on #19570 (edit form UI) and #23347 (theme compat). Could use a patch on #15490 (retrieval of oEmbed data and previewing, which I suspect will become relevant to the edit form UI) and testing of #23282 (audio/video shortcode and player) and #16047 (list table column).
Oops, also meant to mention round 3 of user testing: http://make.wordpress.org/ui/2013/02/04/round-3-of-post-format-ui-user-testing/
Had really good conversations in Wednesday’s dev chat and continued in today’s office hours. Seems like we’ve got a really good direction. All the UI will be available all the time and theme support for individual formats will shift to serving as a flag for whether or not the theme handles format-specific data for display. If a format is not explicitly supported by the theme, there should be simple, semantic fallback output that can be hooked on to the_content. This allows the admin UI to stay consistent and able to offer data fields that don’t just disappear into nothingness, and themes can actually support post formats with just styling rather than handling format-specific data themselves.
@beaulebens is working on the fallback output on #23347, and @sabreuse is joining @rachelbaker to work on the edit form and switcher on #19570. @melchoyce has updated wireframes she’ll be linking to in a comment here. TBD: no-JS treatment, will also need to be keeping an eye on accessibility.
Also, user testing was done with core as-is, and I’ve got videos to watch and analyze for post formats using Crowd Favorite’s UI and fallback code. These are extremely revealing and are really helping us identify pain points as well as setting a baseline for measuring any improvements we hope to make.
Will the post formats update include any work towards making post formats more usable via the front-end? I really love the idea of bbPress being able to use post formats to distinguish between normal posts and support posts for instance, as well as its own take on link posts and so forth.
The list of core-supported post formats will be (currently):
There are no plans to allow plugins/themes to modify that list
So I suppose that means we won’t be able to easily create a post format like, say, “Forum Link” to mimic the Facebook style link posts with autoembedding? Too bad, I was really excited about the possibilities there.
Post formats already exists as an enumerated list and that will not be changing. In your cited example, not sure why a “Link” format post wouldn’t work.
Updated wireframes: http://cl.ly/0p260s3U0L3p
As a user, I hope there’ll be an easy way (via plugin if need be) to continue using things like post titles for “asides” since this is the way I’ve been doing them for the past 6+ years. Some people use titles and some people don’t. Personally, I like to have the title shown on the singular view.
As a theme developer, I just want to ask that we make it easy to open any hidden fields back up without having to jump through hoops to do it, especially for those of us who have been using those fields in our themes. A simple filter hook or something like that would do it.
One of the things I’ve been thinking about suggesting (hadn’t gotten there yet) was that title always be editable, even if for some formats it’s more buried.
Can you elaborate on what you mean by hidden fields?
Any hidden fields that represent normal post_fieldname data such as the title field. I’m not sure if there are any others, but the title is the biggie.
I definitely agree that the title should always be editable, especially because it’s the <title> element on a page and is what’s used to populate the permalink field. I like the wireframe of the chat format where it says “Chat Title (optional)”. I think that’d be a good use for the aside and status formats too.
I was mucking about with the quote post format on my personal blog and ended up writing some thoughts about usage that may be of interest to the team. Here are the links:
http://synapticism.com/working-with-wordpress-post-formats-and-quotations/
http://synapticism.com/marking-up-quotations-with-html5/
My main point: adding a third field, “source title”, to the quote post format will encourage HTML5 best practices.
I’m no expert in these things so there might be something really terrible about this idea that I wouldn’t have thought of
Great research and post, thanks.
@lessbloat has started new rounds of user testing – one with core as-is, and one using the Crowd Favorite code and San Kloud for the theme so that all formats are enabled. Will be reviewing and posting those when they come in.
We’re going to go ahead and get patching so we can test and iterate, and still looking for somebody interested in creating icons. @rachelbaker will be working on the form itself and switching. Would love a volunteer or two on data retrieval and theme usage functions, but will likely be looking at that myself in the next couple of days.
Helen, Which Trac ticket should I use for the forms & format switching?
#19570 is fine
Plated around with some more concepts tonight, based on some ideas @lessbloat had in UI chat:
Default
Hovering over a different icon
I kinda love these concepts Mel!
Just as a heads up, we’re looking at changing the icons in admin. Ben Dunkel is working on some flatter ones that will scale better. I like the idea of these matching those, but we’ll probably want to match the new ones.
Hell yeah, that sounds fabulous. If I can get a copy of any of his new icons, I’d be more than happy to design some new post format icons.
Also — does @empireoflight have vector versions of the admin icons? Those would be very helpful for creating new post format icons.
Continuing with the thought of modeling after the Crowd Favorite plugin, could the data retrieval code be similarly inspired?
I’m unclear on what in the CF code would inspire it.
I was thinking of the function naming…If we are talking about supporting a standard custom post format functionality, we could model the data retrieval functions on the Crowd Favorite plugin.
The icons are all in psd format, made of shape layers, so they’re kinda in vector format. You can download theme here: http://bendunkle.com/wp-admin-icons.zip
FYI, I’m designing some new icons in a more flat style, that I hope to post as a patch on trac in a few days…I’ll post a preview later today.
That sounds great! I’m really looking forward to seeing the new icons.
Hey check out http://core.trac.wordpress.org/ticket/23333 and chime in
That was a pretty good conversation. Looking forward for more updates on this!
User testing, round 2: http://make.wordpress.org/ui/2013/01/31/have-made-it-through-the-second-round-of/
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:
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.
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)
Any talk of doing user testing with Crowd Favorite’s existing code?
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.
Hi @Helen, Mockups look great. Curious though, where is URL slug field?
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.
Sorry about that, my fault – we have moved our Thursday slot an hour earlier so it won’t happen again!
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?
I don’t follow, although maybe somebody else does. These seem like simple post meta to me.
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.
Still looking for wireframes/storyboards for possible UI ideas for each post format. To put it succinctly, we are looking to address discoverability, value, and usability, approximately in that order. We will at some point need to talk about how users get there in the first place, but again, for now let’s focus on the add/edit post screen. We briefly touched on what would happen to the UI if the theme doesn’t support the post format – there seems to be early consensus that the UI itself stay altered (e.g. if there were a separate input for a link URL) but there would be a warning of some sort about the lack of theme support.
A large portion of our office hour today was spent discussing a script for user testing that we can use throughout this process to help us evaluate the changes proposed. We need to use a theme that includes all ten formats, doesn’t do anything to the admin UI, and preferably does something to the front end display for each. One that I know of is San Kloud, although it has some deprecated function usage (hey @kovshenin – want to fix that? ); other suggestions welcome.
Since the first part of the issue here is discoverability, the script needs to not hand-hold the format selection or entry process. Here’s a rough outline of what it might look like – discuss any changes in the comments, and @lessbloat will help us get testing. Some of these are particularly difficult to describe in a non-leading manner. Through each of these, it would be good to have the user narrate what they want or expect will happen for each of these formats. A little fuzzy since we’re not going to point them at the format picker and a given tester may not be used to blogging, but the more narration of thinking/expectations, the better.
Hey @kovshenin – want to fix that?
You are wonderful.
Status: Add a blog post that represents your current status as (provide text), the way you might on a site like Facebook or Twitter.
The most difficult/unclear are imho Aside and Status. In my imagination, the difference between them would be two things: The profile image of the author and “time since published” as post date. Just my 2cents
I think many of us would agree about “Aside” and “Status” being less clear-cut. I think in the end it’s still up to the theme as to how it’s displayed on the front, and I imagine that in terms of the admin they’ll probably have the same UI because there isn’t anything really different about what type of data they need/represent. However, for user testing, we need to represent some sort of difference and see if they spring for choosing a post format.
In an early version of @kovshenin’s Publish theme (on github), the status used to be a status on another platform… showing a tweet for instance. This is something that still is interesting from a point of view in which referencing and/or cross-posting weighs in.
Perhaps status should be linked to a (geo-)location or mood, whereas an aside gives more flexibility on the contents, just with less emphasis as full-blown article.
(side-note: for all afore-mentioned post-types, it would come in handy when the Press-This bookmarklet would be more content aware and sensitive, saving much time editing.)
Well… here’s one (fairly obvious) option:
I know this is a bit out of the box, but I the the post format option should be chosen before going to the post screen. tabs and icons in the post screen will make a user think that they can toggle between the types easily and possibly even include multiple types in one post. why not choose before you even get here?
For format-heavy sites, I agree that this workflow makes sense. Unfortunately for folks who’s site doesn’t make use of them (even if registered by the theme), this introduces a pretty horrible, extra barrier to publishing.
I like the idea of an additional drop-down from the Posts > Add New menu, that’s a nice shortcut (although it’s a model not used anywhere else in the menu).
I think whatever we need to do, needs to handle/prevent users from trying to switch between formats (once they’ve entered something in one specific format). I guess we could have an “Are you sure?”, like when you leave the post editor with unsaved content.
Why do they need to be prevented from switching formats?
@beaulebens I can see how this can be a huge hurdle to people who dont want formats. I guess the question is: do we want to commit to this concept in a big way or have it be a subtle option? I feel that committing to formats and optimizing the workflow in that area is a good idea.
If we do use a more aggressive workflow like above, we should have an option for a user who dose not want formats (even though their theme enables them, and no matter if you switch themes) to turn them off in core.
If we’re not completely all-in with this concept, then I understand why we would want it to be more subtle, non-intrusive of a workflow. (“dont make me choose what format before I post, I just want to post” kind of thing)
I agree with Beau about handing format switching.
Originally on WordPress.com it was simple to switch between post formats while writing a post. The issue we found with this is that users would get confused between uploading a photo and the actual photo post format. They’d go to upload a photo to their standard post, switch formats to the photo format, upload, and then publish. They’d then lose the post content they had written on the previously selected format.
We fixed this issue by first asking them to select a post format, but that’s tougher to change in core for reasons you’ve mentioned, it puts a decision in the way of posting that didn’t exist before.
We also now tell them that they will lose their existing post content if they decide to select a different post format (if it hasn’t been saved as a draft). This helped a whole bunch, it dropped the number of tickets for this issue to near zero.
…it puts a decision in the way of posting that didn’t exist before.
The decision has already been made. I don’t think many users just go to the post screen to just see what comes out of typing randomly for a while.
Even if a decision has not been made when you go to post, don’t you want to know that you can post different types of posts? We’re not committing to the idea by having post formats if it’s not front and center.
The sidebar menu should have “Add New” items for each of the post formats along with a full post editor.
This is also the direction that the vast majority of personal publishing platforms has taken on mobile, and one that we’re dabbling with too. In fact, these items don’t even belong in a “Posts” menu group since that makes them less action-centric.
Just my thought on the subject.
The decision to post has been made, yes, but the decision of which format to use has not. It might be tough to sell asking users to make that extra decision every time when they never had to before. As we have found on dot com the vast majority of users are still going to use the standard format.
@apeatling: even if they haven’t made the decision the ability to just start a regular post from scratch would still be there. That’s not changing.
That is definitely a part of what we need to consider outside of the context of the add/edit screen. @beaulebens is also correct – we must not block the way current workflows are for just plain posting without formats, only provide a different point of entry that includes pre-selecting a format.
Without wanting to refer too much to tumblr, the “Press This” bookmarklet could be of importance for this: content awareness could suggest or decide the format.
That same content awareness could transmogrify (yes, I like C&H) your post(-format) while editing, as you add certain media/content.
There’s a slightly-separate initiative to improve Press This as a whole, and we will definitely at least keep parity with whatever we do to post formats in the regular admin.
I like icons but here is words for concept:
list posts: http://s.sar.ac/image/0a203Q3E391e
post edit customized to format: http://s.sar.ac/image/3n1i1I1O3n2V
menu: http://s.sar.ac/image/052U1C0y1R0s
For the list table, we’ve got #16047 for adding a column for the format, and #15323 for a filter, which should probably be a dropdown like the others, not extra tabs.
For post editing, I don’t think we should be changing the title like that. It then gets completely mixed up with a custom post type, and isn’t necessarily accurate, either. It’s “just” opting in to a theme-driven special format for a regular old blog post.
I feel the changing the titles make sense. I like how Mel Choice executed it below
Another obvious option, similar to this one would be to have a dropdown where “Add New post” is now:
A pointer could be used to make sure users don’t miss it.
Of course, options would say “Add New Quote”, “Add New Aside” etc.
-1, don’t think this is intuitive/discoverable enough. It’s also a very non-standard WP UI.
I’m still not clear on this … is the intent to dictate what each and every Post-Format will be used for and look like? IF that is the case, then why not simply make them all part of core rather than at the Theme Author / End-User’s discretion on how they will be used and / or implemented.
Don’t get me wrong, a better UX would be more than welcomed but deciding on that interface under the assumption a specific Post Format will *only* be used in a specific fashion is not a good place to start from when whether or not the Post-Format is available is left to the Theme Author’s discretion.
Post formats are meant to be standardized and portable across themes, hence the lock on which ones are available. As @nacin put so well in his post:
The idea behind the feature is this standardization and portability for a segment of bloggers. Many designers of themes used for microblogging wanted this ability to offer structured, well-defined content, beyond what could be done with categories and tags.
However, without anything actually standardized or structured in the admin, it’s ended up being completely up to the theme to determine both display AND data. Of course a theme will still be in control of the display, but given that formats are about standardization and portability, the feature itself is half-baked until we actually do something to the admin and corresponding data structure. As far as what’s available, I actually am not a huge fan of the whole opting in to a subset thing, but rest assured that a theme will continue to function like it does now if it doesn’t support a post format. After all, as it stands, a user could have created a post with a post format before switching to one that doesn’t support it, and nothing breaks.
I know it’s been mentioned before, but I have a PHP script for handling post formats on the front end:
https://github.com/justintadlock/hybrid-core/blob/master/extensions/post-format-tools.php
If you need to see it in use in an actual theme, here’s one I’m working on:
https://github.com/justintadlock/chun/tree/0.1
All of this is based off how my users at Theme Hybrid are using post formats. Most of it was developed over the course of the last year based on feedback and seeing how individual components worked in various projects.
The biggest thing I’d welcome as a theme developer is some metadata saved for embeds in audio and video posts. I can pull embeds from posts with a regex (what I’m doing now), but there should be an easier method.
Yep, your post format tools is on the list of examples for regex pulling of data. Thanks for the reminder What you’re saying about metadata is exactly why we’re working on this, although from the workflow/UI end first to really make it useful and valuable for users, which in turn will make it useful for theme authors.
Thanks for getting back to me on that. I just wanted y’all to be aware of how several theme companies are using post formats at the moment (it’s baked into my dev framework).
I actually agree with sara cannon and think users should chose a post format before being able to enter any content. I’ve thrown together some wireframes to show how that would work. I’ve leaned heavily on wp.com’s post format UI, but have organized formats by text vs. media:
Add New Post: http://cl.ly/image/0N04382M2L1u
**Text**
Status: http://cl.ly/image/170O1N0L062U
Quote: http://cl.ly/image/1V0h3O211K2T
Chat: http://cl.ly/image/2T1X2I0f2R0z
Aside: http://cl.ly/image/3v3T3b3L2s1o
Link: http://cl.ly/image/2l213j3i2625
**Media**
Image: http://cl.ly/image/2X0S2u2f053c
Gallery: http://cl.ly/image/032J3l2w1t10
Video: http://cl.ly/image/3J2v2v0j0o37
Audio: http://cl.ly/image/2y2x382v362Z
All wireframes in pdf: http://cl.ly/3G2k2R01010q
I like this direction – will make a point to discuss these in tomorrow’s office hours. The one thing I want to avoid is blocking access to posting a regular post without specifically selecting the standard format. Would rather keep a switcher on this screen, and have a one-click point of entry elsewhere (e.g. Dashboard).
I kind of think “choose your format initially” will ease content switching confusion. because, If someone switches from audio to gallery after uploading their audio, wouldn’t their audio get dropped? I can see the case for not getting locked in.. but it seems like these formats are really specific that they are a very intentional choice. People who post to tumblr do this constantly.
I agree that it would be good to have “choose your format” initially BUT I don’t think it should block the current way of directly going into creating a post, so in my eyes it should be a different point of entry, not an extra step on the add new screen.
I don’t really know it means by “their audio would get dropped” – an upload would stay uploaded.
Also in the admin bar, New > Post > {List of supported formats} could be helpful.
agree! very tumblr esque
I disagree, I do not think it is a good idea to force users to select a format before entering any content. Choosing a post format should determine what admin ui gets presented and what data the theme calls to format a particular way. All of the data gets saved as part of the post anyway.
We should force the choice initially only if it is an absolute necessity, and I am not convinced that it is. If I start with an audio format and change to image format I would expect that the audio data no longer gets presented by the theme. No confusion. What harm would it be if a post has both image and audio meta after my change?
Something I would like to throw into the mix however is for some way for theme developers to specify the default format for new posts. So if my theme focuses on galleries, that is the first ui that is displayed (or maybe only depending on my theme intent).
Please read further updates, especially http://make.wordpress.org/core/2013/01/27/post-formats-ui-update-124/:
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.
whoops… I guess I missed that. Well, sounds great then.
I am starting to think that encouraging Audio and Video posting without a native way to play it is going to be super lame. *Yes I realize scope etc etc* But for instance: “Hey I’m posting Audio!” but what you’re really posting is a YouTube?
Time for a native HTML5 player for audio/video formats maybe?
that’d do it – I am going to throw MediaElement out there as a path forward, whenever it’s in scope. Our WP.com can toss down their code into the .org wilderness.
or*
this one: http://mediaelementjs.com/ – skinnable, extensible, whatnot
or this: http://jplayer.org/
You’re my point man now. Bring it.
Idea: for gallery format, we could have the modal view go straight into creating a gallery. Selecting a bunch of images should create the gallery and close the modal rather than having a second “insert” step. Going back into the modal should go into adding images to the gallery. The preview of all images in that gallery would appear on the edit screen.
Better, rather than go into the modal, integrate the gallery options into the main ui.
Please consider this idea too then:
http://wordpress.org/extend/ideas/topic/custom-attachment-type
Post types (what you are talking about) are not the same as post formats (the feature under discussion/development).
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:
Thinking out loud without having put too much thought in it, I think it would be user friendly that before a user starts writing a post, he/she can already choose the format.
Upon choosing this format, the backend changes with the relevant fields. Sort of like different templates for the backend.
Not sure though how feasible that would be.
That is actually how .com handles it. Or do you mean in the Dashboard with Quickpress?
There is much more to think about when it comes to the UI, but as requested, let’s please focus on the add/edit post screen as the first step.
I like a wp.com, also for continuity
Paolo
I was working make a plugin a bit like this – very incomplete, but contains some regex and implementation. Most of the snippets are by @Justin Tadlock. https://github.com/bungeshea/post-formats
http://schema.org/docs/schemas.html
Google,Yahoo and Bing converged on schema.org during 2011 and recently started to use it in serps displaying special snippets, that’s the effective beginning of a radical change named Web 3.0.
Schema.org involves a radical change in how users produce content and requires structuring data far more than we do today, there are currently more than 400 standard entities and no space for interpretation: search engines expect “things” to be described in that way.
To handle this WP backend UI needs to change and probably stop showing every custom post format at the root menu level, in the near future we may need to use post formats much more and evidently there’s no room for 400 first level menu slots.
Schema.org entities allow inheritance with every entity as a child of “Thing”, and 8 basic direct childs:
but there’s multiple inheritance level (eg: Thing > Organization > LocalBusiness > GovernmentOffice > PostOffice) where each subsequent child can add more fields…. in some types there are literally hundreds of fields, too much for us humans.
How to handle all this stuff?
The most promising idea and implementation seems to be http://decoupledcms.org/ http://bergie.iki.fi/blog/decoupling_content_management/
You are talking about custom post (content) types, not post formats, and they can be submenu items rather than top level items.
Just thought I would share my current solution for a network of blogs we run called GDNM.org…
On image and video posts there is a URL box where you can enter a URL and when you tab out it will fetch the image or embed the video using oembed:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:07.%20oembed.png
The box sits just above the first post, as it’s for quick posting in the theme but either way it works well!
No post format selected:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:01.%20closed.png
Blog post format:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:02.%20blog.png
Image post format:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:03.%20image.png
Video post format:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:04.%20video.png
Link post format:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:05.%20link.png
Quote post format:
https://www.dropbox.com/sh/xhc5vkzhbytt06q/MuUl0Eh7ZH#f:06.%20quote.png
Hi @Helen, I’m not a UI person so don’t have any relevant comments there. However whatever get’s implemented it would be great if it can be controlled via hooks and/or if a class was introduced.
As you know there’s a lack of flexibility for the plugin developer around the top of the post edit page and it would seem this type of UI change would require flexibility; I hope that flexibility can make it’s way into being addressable by plugin developers.
Just riffing for a bit: I hope people get what I’m trying to convey:
So when I look at a post, I see the content data (the title and content), ie the meat and potatoes of a post and I see meta data/ taxonomies that add to the main data to categorize/tag/describe it. The content has is own area and meta data/ taxonomies/ etc are relegated to meta boxes. Looking at the different post format examples from other CMS’s, you are basically changing the type of content and therefore are changing the type of content fields you are using. Video posts may need a title and description, but they also need a video source url. An aside doesn’t even need a title. Post formats are just presets of custom content fields.
In order to beef up post formats, I think we need to add hooks and an API that allows developers to change the content area of a post; to basically upgrade a few custom fields to content status. Not only should developers be able to add fields that are important enough to be content alongside the post title and post content fields, they should be able to replace those fields entirely, if they so wish. I have a side project where I disabled the title and content, to be replaced by a URL field and it always felt weird to me that I had to put that field in a meta box when it should have been considered the main content. A new post format UI would basically just be picking out a preset of fields that best fits the format of content. As Mike Schinkel suggested, flexibility is key as it would open some nice functionality for plugin developers as well as make WP a lot more robust.
The point is to create a core UI for the post formats, not leave it up to themes and plugins. Implementation details will come after a UI the supports good workflows is decided upon.
I thought I’d run a couple users through some post format tasks to give us a baseline comparison for improvements/patches. Here are the videos from user 1 & user 2.
Step 1: Log in
No issues.
Step 2: Go to add post screen
No issues.
Step 3: Add text post
No issues.
Step 4: Add image post
No issues.
Step 5: Add video post
4:34 – He tries to add the video URL through the media modal (Insert from URL screen), it inserts a link to the video instead of embedding it.
6:55 – He finally gives up on trying to get the video to embed, “I’m assuming it just want’s me to insert this link”, he says as he moves on to the next task.
Step 6: Add link post
7:55 – since adding a link worked for the other two tasks, he actually used the media modal to add a link this time as well, and it worked.
Step 7: Add quote post
9:07 – He clicked the “text” tab thinking that is where he would add the quote.
Step 8: Preview site
No issues.
Step 1: Log in
No issues.
Step 2: Go to add post screen
No issues.
Step 3: Add text post
No issues.
Step 4: Add image post
4:10 – She wonders if she needs a title for the image she’s posting.
Step 5: Add video post
5:20 – She tried using the media modal (Insert from URL) as well.
6:30 – She’s still searching for a way to add the video, “Not quite sure how to add the video”
12:25 – She gives up and moves on to the next task, after making multiple attempts to embed the video.
Step 6: Add link post
No issues.
Step 7: Add quote post
14:55 – She selected the “quote” post format radio option wondering if something would happen.
Step 8: Preview site
No issues.
love these user tests, great way to get real feedback. thanks!
It’s possible I missed a task (I was clicking through the videos a bit), but it doesn’t seem like they were directed to the actual post formats, not all of which are turned on in all themes. Maybe we can talk about an alternate task script to try.
Definitely agree we could do something to pull in oEmbed data for a preview where it exists, though. Doing it in the media library also means a TinyMCE view and is probably a general thing, but what WordPress.com does is pretty neat.
Let me know. I’m happy to run more users through with a modified script.
My favorite example of an existing WordPress UI for adding a new “post format” post would be the P2 theme. Only the relevant fields are displayed for each post format.
Screenshot: http://cl.ly/image/2p1H290d1T2B
The status and link post formats only display a content textarea (no title).
The quote format displays the content textarea and citation text input fields.
The blog post format displays the standard title and content fields.
We’ll be having our first feature team meeting in IRC tomorrow (Thursday, January 17) at 11AM Eastern/16:00 UTC. Please join us if you’re interested in participating in development of this feature, which does involve more than “just” UI, as we’re going to hit the ground running. We’ll keep that time every week, along with Mondays at 2PM Eastern/19:00 UTC. Updates will be posted here on Make/Core after each meeting. Pete Mall will be my backup lead.
I’ll keep an eye out for the updates here and read the IRC logs, as 16:00 UTC is 03:00 my time, and 19:00 UTC is 06:00 my time.
While perhaps not often used, the same interface in the now-old upload/insert media modal was available as an admin screen by going to the Media Library and then clicking on Edit for an item. With the move away from that interface in the modal, we thought it’d be a good time to treat attachments as what they are: a post type. Some changes users will see are the ability to turn on discussion/comment meta boxes as well as being able to edit the slug for attached items; that is, items that have a post_parent.
What this means for developers is that you can now do familiar things like adding meta boxes or perhaps even utilize those fancy new edit screen hooks for editing media library items. There’s also the attachment_submitbox_misc_actions hook for the Publish meta box. Taxonomies will now come with their native meta box UIs if you so choose – for built-in taxonomies, it’s as easy as:
register_taxonomy_for_object_type( 'category', 'attachment' );
Seriously: that’s it. The screenshot above shows just that.
One thing you may notice is that what’s known as the “Description”, which in reality is the post_content, uses a textarea with quicktags enabled. The decision was made to go this route in core for a couple reasons: to keep it lightweight while still making it a bit better (after all, it was just a plain textarea before), and to prevent attachment-ception as a default possibility. If you as a developer want to enable attachments in your attachments, have at it.
attachment_fields_to_edit comes with backwards compatibility and will continue to work – fields added that way will appear below the Description field. However, you may very well find that it makes sense to change the placement of those fields on this screen for sensible editing and structure. There are JS methods for adding to the modal moving forward, but while those guides are worked on and you’ve got some already-existing things to support, the following will help you through.
Previously, you may have done something like checking the IFRAME_REQUEST constant to determine whether or not something should show on the attachment edit screen or in the Thickbox. Since the new media modal is not an iframe, that won’t work anymore. To help with that, we’ve added some new arguments, or flags if you will, to allow you to specify whether or not an added field should appear on this edit screen or in the new media modal: #22759.
This example shows how to add a field that appears in the modal but not in the edit screen. For the other way around, you would set show_in_modal to false. Both args default to true, and there’s no real reason to set both to false, so you’ll only use one or no flags for a given field.
jltallon, 
Anointed, 
Antonio, and 4 others are discussing. 
lessbloat, 
add_filter( 'attachment_fields_to_edit', 'myprefix_attachment_fields_to_edit', 10, 2 );
function myprefix_attachment_fields_to_edit( $fields, $post ) {
$fields['test-media-item'] = array(
'label' => 'More Media Management',
'input' => 'html',
'html' => '<a href="#">Link One</a>
<a href="#">Link Two</a>',
'show_in_edit' => false,
);
return $fields;
}
For the low-down on how this came together over the course of 3.5, check out #21391. The possibilities are exciting! Document/asset management with taxonomies, adding that method for detaching or reassigning the post parent for a media item – what else might you come up with?
This… is amazing. And will totally change a workflow I have on a current project. Wow… literally without words.
Finally media as media and no more CPTs to act as a faux media management system.
Awesome!! Exactly what I was waiting for! Thanks
killer!
Sweetness! I can’t wait to start experimenting/
Luke Gedeon 3:32 pm on March 15, 2013 Permalink | Log in to Reply
“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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
“…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 | Log in to Reply
Teeny mode may be more appropriate for some post formats, e.g. quote.
Scott Taylor 10:22 pm on March 18, 2013 Permalink | Log in to Reply
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.