Post Formats UI Update, 1/21
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.
- Standard/text: Add a blog post entitled X, with the following text. Publish and view the post.
- Aside: Add a brief blog post without a title, or what might be referred to as an “aside”. Publish and view.
- Status: Add a blog post that represents your current status as (provide text), the way you might on a site like Facebook or Twitter. Publish and view.
- Chat: Add a chat blog post where the content is a chat transcript (provide something to copy-paste). Publish and view.
- Quote: Add a quote blog post with X quote attributed to Y. Publish and view.
- Link: Add a link blog post with X text linking to [URL]. Publish and view.
- Image: Add an image blog post and insert X image into the content editor. Publish and view.
- Gallery: Add an image gallery blog post with X images (this probably needs step-by-step instructions for creating a gallery). Publish and view.
- Video: Add a video blog post with [something from YouTube]. Paste the URL on its own line without linking it. Publish and view.
- Audio: Add an audio blog post with [something from SoundCloud]. Paste the URL on its own line without linking it. Publish and view.
- View your site. (If they chose formats, it should show the differences pretty clearly in a post archive view, hence the importance of choosing an appropriate theme.)
Konstantin Kovshenin 5:54 am on January 22, 2013 Permalink
Sure!
Helen Hou-Sandi 2:36 pm on January 22, 2013 Permalink
You are wonderful.
F J Kaiser 7:35 am on January 22, 2013 Permalink
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
Helen Hou-Sandi 2:48 pm on January 22, 2013 Permalink
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.
ipears 4:56 pm on January 22, 2013 Permalink
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.)
lessbloat 6:49 pm on January 22, 2013 Permalink
Well… here’s one (fairly obvious) option:
sara cannon 11:36 pm on January 22, 2013 Permalink
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?
Beau Lebens 7:40 pm on January 23, 2013 Permalink
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.
Helen Hou-Sandi 9:17 pm on January 23, 2013 Permalink
Why do they need to be prevented from switching formats?
sara cannon 5:05 am on January 24, 2013 Permalink
@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)
Andy Peatling 11:46 pm on January 24, 2013 Permalink
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.
Isaac Keyet 3:42 pm on January 27, 2013 Permalink
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.
Andy Peatling 4:51 pm on January 27, 2013 Permalink
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.
Isaac Keyet 1:52 am on February 1, 2013 Permalink
@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.
Helen Hou-Sandi 9:16 pm on January 23, 2013 Permalink
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.
ipears 2:43 pm on January 24, 2013 Permalink
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.
Helen Hou-Sandi 3:33 pm on January 24, 2013 Permalink
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.
sara cannon 11:55 pm on January 22, 2013 Permalink
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
Helen Hou-Sandi 9:22 pm on January 23, 2013 Permalink
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.
sara cannon 4:54 am on January 24, 2013 Permalink
I feel the changing the titles make sense. I like how Mel Choice executed it below
Slobodan Manic 3:40 pm on January 24, 2013 Permalink
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.
Slobodan Manic 3:43 pm on January 24, 2013 Permalink
Of course, options would say “Add New Quote”, “Add New Aside” etc.
Isaac Keyet 3:43 pm on January 27, 2013 Permalink
-1, don’t think this is intuitive/discoverable enough. It’s also a very non-standard WP UI.
Edward Caissie 8:30 pm on January 22, 2013 Permalink
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.
Helen Hou-Sandi 12:45 am on January 24, 2013 Permalink
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:
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.
Justin Tadlock 10:13 pm on January 22, 2013 Permalink
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.
Helen Hou-Sandi 9:30 pm on January 23, 2013 Permalink
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.
Justin Tadlock 10:05 pm on January 25, 2013 Permalink
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).
Mel Choyce 3:42 am on January 23, 2013 Permalink
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
Helen Hou-Sandi 12:50 am on January 24, 2013 Permalink
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).
sara cannon 4:51 am on January 24, 2013 Permalink
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.
Helen Hou-Sandi 1:49 pm on January 24, 2013 Permalink
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.
Slobodan Manic 3:51 pm on January 24, 2013 Permalink
Also in the admin bar, New > Post > {List of supported formats} could be helpful.
sara cannon 4:40 am on January 24, 2013 Permalink
agree! very tumblr esque
cramdesign 9:26 pm on January 28, 2013 Permalink
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).
Helen Hou-Sandi 9:28 pm on January 28, 2013 Permalink
Please read further updates, especially http://make.wordpress.org/core/2013/01/27/post-formats-ui-update-124/:
cramdesign 1:05 am on January 29, 2013 Permalink
whoops… I guess I missed that. Well, sounds great then.
Scott Taylor 4:09 pm on January 23, 2013 Permalink
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?
Beau Lebens 7:41 pm on January 23, 2013 Permalink
Time for a native HTML5 player for audio/video formats maybe?
Scott Taylor 8:35 pm on January 23, 2013 Permalink
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.
Scott Taylor 8:35 pm on January 23, 2013 Permalink
or*
Scott Taylor 8:36 pm on January 23, 2013 Permalink
this one: http://mediaelementjs.com/ – skinnable, extensible, whatnot
Scott Taylor 8:36 pm on January 23, 2013 Permalink
or this: http://jplayer.org/
Helen Hou-Sandi 10:03 pm on January 23, 2013 Permalink
You’re my point man now. Bring it.
Scott Taylor 4:28 pm on January 24, 2013 Permalink
Brought http://core.trac.wordpress.org/ticket/23282
Helen Hou-Sandi 1:06 am on January 24, 2013 Permalink
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.
cramdesign 9:30 pm on January 28, 2013 Permalink
Better, rather than go into the modal, integrate the gallery options into the main ui.
unsalkorkmaz 10:15 pm on January 26, 2013 Permalink
Please consider this idea too then:
http://wordpress.org/extend/ideas/topic/custom-attachment-type
Helen Hou-Sandi 12:09 am on January 27, 2013 Permalink
Post types (what you are talking about) are not the same as post formats (the feature under discussion/development).