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:
- CF Post Formats (go to theme admin)
- WP.com: standard, image, video, quote, link
- Tumblr: text (standard), image, quote, link, chat, audio, video
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:
lessbloat, 
Piet 6:52 am on January 18, 2013 Permalink
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.
Jose Castaneda 7:38 am on January 18, 2013 Permalink
That is actually how .com handles it. Or do you mean in the Dashboard with Quickpress?
Helen Hou-Sandi 1:29 pm on January 18, 2013 Permalink
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.
Mang_ 7:44 am on January 18, 2013 Permalink
I like a wp.com, also for continuity
Paolo
Shea Bunge 7:56 am on January 18, 2013 Permalink
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
htrex 9:56 am on January 18, 2013 Permalink
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/
Helen Hou-Sandi 1:39 pm on January 18, 2013 Permalink
You are talking about custom post (content) types, not post formats, and they can be submenu items rather than top level items.
Tom Lynch 3:07 pm on January 18, 2013 Permalink
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
Mike Schinkel 5:58 pm on January 18, 2013 Permalink
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.
Manny Fleurmond 4:58 am on January 19, 2013 Permalink
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.
Helen Hou-Sandi 5:24 am on January 19, 2013 Permalink
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.
lessbloat 2:04 pm on January 19, 2013 Permalink
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.
User #1
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.
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
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.
Observations/Thoughts
adamsilverstein 9:32 pm on January 19, 2013 Permalink
love these user tests, great way to get real feedback. thanks!
Helen Hou-Sandi 1:49 am on January 20, 2013 Permalink
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.
lessbloat 1:15 pm on January 21, 2013 Permalink
Let me know. I’m happy to run more users through with a modified script.
rachelbaker 1:17 am on January 21, 2013 Permalink
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.