I sent a user through the new page on front flow, as well as a few steps in the customizer (including the new color picker). I sort of cheated on this one by telling him exactly where to click at times, but the purpose of this test was not to test if he could get there, but once he got there if the changes we’ve made make sense.
Here’s the video, and my notes:
Step One notes – Log in
No problems.
Step Two notes – Add static front page
No problems.
Step Three notes – Preview your blog
2:19 – “So people can leave a comment on my homepage?” (see my note below)
Step Four notes – Go to customizer
No problems.
Step Five notes – Change your tagline
No problems.
Step Six notes – Change your background color
4:23 – Unfortunately, the new color picker failed again, even with the new “current color” tooltip. User simply clicked the right hue selector, and assumed that the color had been changed to blue.
5:55 – “Ah, I have to drag this, oh. Well that was a little bit confusing”, as he goes back to the customizer color selector and discovers that he has to move the puck in the left-side box.
Step Seven notes – Edit your home page
7:31 – Makes it to the home page to edit it, but then says, “Alright I’m confused”.
8:30 – Goes back to dashboard, “How come this doesn’t look the same as what I was just messing around with”, referring to the customizer.
9:09 – He’s getting confused from my instructions, I said “Change the title” but he’s thinking about the site title, which he saw in the customizer. I’ll have to fix my wording here.
Recap
- He pointed out that comments are turned on for his static home page. Should we consider turning comments off by default when a static home page is enabled?
- Having to click twice to select a color is still confusing.
- Having the static auto-generated “home” page be blank might be a bit confusing. Perhaps we could pre-fill the page description with a bit of helper text. Something like, “This is your new default home page, you can edit the content of this page via the pages section of your dashboard.”.
Terry Sutton 3:59 pm on April 11, 2013 Permalink | Log in to Reply
The modal doesn’t feel quite right to me. A) So many sites are adding those ultra-annoying modals, and It would feel a little like that to me, and B) with the exception of the Media modal, i feel like it doesn’t fit with the current UI direction. It’s very well done, so I don’t want to sound too critical, but it doesn’t feel quite right to me.
Mark Jaquith 4:00 pm on April 11, 2013 Permalink | Log in to Reply
The one I mentioned wasn’t the modal. I agree that the modal is too much of a departure.
Terry Sutton 4:06 pm on April 11, 2013 Permalink | Log in to Reply
I’ll be back when I learn to read.
Mark Jaquith 4:09 pm on April 11, 2013 Permalink | Log in to Reply
I added a screenshot of the one I was talking about, just to make it clear.
Mel Choyce 4:01 pm on April 11, 2013 Permalink | Log in to Reply
Was just about to post this below, but I guess it belongs here now:
I love these explorations! I know we don’t want increase the barrier between thought and post, but I do think that by choosing to write a post, you’re already making a decision. I like that we’re prompting users into action by making them decide on a post format. I wish we could test this with a selection of .org users, who might have different goals and behaviors than .com and tumblr users.
Going on to the individual exploration, I’m not a huge fan of modals — especially since they never seem to act correctly on a small screen — but I can see them being a handy solution here. What would happen if someone automatically closes the modal, though?
Overall, I agree with Mark — I definitely think #2 is the right direction. It makes a lot of sense to me, especially since it’s bringing you to the right screen and prompting you for action without the distraction a modal window might have. It helps directly reinforces how your decision effects what you’re posting. With a modal, there’s a little bit of a disconnect between what you choose and how that changes what you see.
Building on this, I can also envision a setting that allows you to set your default post format, which would highlight your default when you land on the new post page and have the others greyed out. Alternately, we could do the selected/default icon in color and leave the others b+w. Power users, people who just post one type of content, or even professionals creating sites for clients could set defaults or disable formats entirely, and I think #2s method would make any of those changes easier.
Mark Jaquith 4:08 pm on April 11, 2013 Permalink | Log in to Reply
So I was thinking that if you clicked into the post editor or title, it’d select Standard and let you go on your way. Just like before. And we could give focus to the post title, and select standard if you just started typing a title. Again, just like before. So this way you can’t miss the new UI, but you can also just skip past it when you just want to start composing.
sara cannon 4:09 pm on April 11, 2013 Permalink | Log in to Reply
Love this!
Mel Choyce 4:28 pm on April 11, 2013 Permalink | Log in to Reply
Can you focus into a disabled element? Otherwise, sounds like a great plan.
Mel Choyce 4:29 pm on April 11, 2013 Permalink | Log in to Reply
Actually, I’m dumb — you can’t do anything to a disabled element, so the fields would have to just be greyed out, not disabled. Nevermind.
Tevya 4:59 pm on April 11, 2013 Permalink | Log in to Reply
I think this sounds awesome.
esmi 4:09 pm on April 11, 2013 Permalink | Log in to Reply
The perennial issue with modal windows is ensuring that they are fully accessible to those using screen reading software or those who don’t use a mouse. Ensuring this level of accessibility can put a lot of additional strain on the UI devs. Is that really something you want to impose at this stage of the game?
Mark Jaquith 4:13 pm on April 11, 2013 Permalink | Log in to Reply
I’m not advocating that we use a modal. I agree with your concerns (and have more of my own). See above comments. Updated post with screenshot to be clear about the approach I was talking about.
sara cannon 4:13 pm on April 11, 2013 Permalink | Log in to Reply
The greyed out area can also surface and choose “standard” as a format when clicked / tapped
Ipstenu (Mika Epstein) 4:17 pm on April 11, 2013 Permalink | Log in to Reply
Oh… So my question below is ‘Yes’ ;D
Ipstenu (Mika Epstein) 4:17 pm on April 11, 2013 Permalink | Log in to Reply
Would it still be possible to switch between? Sometimes I change my mind, and one thing I HATE about how Tumblr does it is that I have to totally start over :/ I Even if there was a warning that any standard specific content would be lost, the main part of the post below I’d like to keep.
Chip Bennett 4:19 pm on April 11, 2013 Permalink | Log in to Reply
Looks like the sidebar meta box is retained – or, is rolled into the Publish meta box, as a dropdown or radio select.
sara cannon 4:20 pm on April 11, 2013 Permalink | Log in to Reply
Yes, in the publish meta box there will be a switcher. I also think this is essential
Terry Sutton 4:53 pm on April 11, 2013 Permalink | Log in to Reply
So I’m clear — the switcher won’t stay above the post title as it is now in Beta1? IE: the icon bar will go away after you’ve made your choice?
Mark Jaquith 4:59 pm on April 11, 2013 Permalink | Log in to Reply
That’s the idea. Big and up top on first load. Tucked away once you’ve chosen (either explicitly or implicitly). Addresses the two big issues we’re having in beta 1: not obvious enough before choosing, in the way after choosing.
sara cannon 5:00 pm on April 11, 2013 Permalink
and resolves any potential confusion for users that might think they can use all the buttons/formats on one post
Terry Sutton 5:06 pm on April 11, 2013 Permalink
Ok. In that case, I’m split on the idea of it going away to a metabox, or staying above the post title as it does in Beta1. So after you’ve chosen which post type, here’s what you see: http://cl.ly/image/2g1f3o2D3m1U
Brian Richards 5:36 pm on April 11, 2013 Permalink
I can’t decide whether or not I’d like for the UI to disappear completely after choosing my post format. I do like the notion of “putting it out of the way”, but what happens if I’ve accidentally clicked/tapped the wrong format and wanted to quickly click/tap on a different one — is the UI only removed after I begin entering content?
I know from the explanation that the UI just gets moved into the Publish metabox, but it’s unlikely I would know or expect this behavior otherwise.
The alternative of keeping it in place (and dimming the unselected choices) doesn’t sound like a great solution either because, as already discussed, it stays in the way and could lead to later confusion about the purpose of the buttons (e.g. “is this how I add a link to my post?”).
Tough call…
Chip Bennett 4:17 pm on April 11, 2013 Permalink | Log in to Reply
+1 to “In Page decision with post editor greyed out. Icons will go away and the “switching” will be in the sidebar like above.” It looks great, and appears to be a huge improvement to what we have now (3.5.1 and 3.6 beta 1).
-(Eleventy Frillion) to a modal.
Robert Dall 5:06 pm on April 11, 2013 Permalink | Log in to Reply
OMG you are awesome @saracannon I loved how you covered all the bases here… A couple comments.
The Modal system as @AndyPeatling put it on twitter. “Not sure forcing the UX would be well received for dot org though. Most don’t care or use them.”
The Post format switching as a radio button would to far to long leading pushing the category, tags, feature image to push them lower in the window.
Icons with Text +10,000 looks awesome!
One comment regarding the icons getting greyed out on the hover is it is opposite of the hover state in the admin menu on the left. We should keep the standard hover over icons the same through out the admin section of the site.
Can we choose icons only or text only or both like Apple offers in there mail application? It seems that would suite the best of both worlds.
Tom Auger 5:08 pm on April 11, 2013 Permalink | Log in to Reply
Really love this new direction. The in-your-face visual icons really bring this often-underused part of the post to the front.
My only comment is – does the editor really need to be greyed out? Should we not just default to “Standard” and then let the user switch it up from there. I can just see a ton of bloggers who don’t currently use post formats get really annoyed when we add another click to the process.
Robert Dall 5:15 pm on April 11, 2013 Permalink | Log in to Reply
I see your point most bloggers will choose the standard post… It beta1 it already chooses standard by default and I think we should keep it that
sara cannon 5:19 pm on April 11, 2013 Permalink | Log in to Reply
Mark pointed out above that we will still have the title field focused like normal – so start typing like normal and there is no extra “click” and standard is chosen for you
Ryan Cowles 5:38 pm on April 11, 2013 Permalink | Log in to Reply
Awesome work, Sara! These concepts look rad.
While I don’t have much to say in regards to the UI itself, I think this part is important: “you can turn all post formats off from within core settings to override what your theme set. ”
If a new step in the post creation flow is introduced that forces the user to select a post format, I think the user should be allowed to disable it. Therefore users that only use one post format aren’t forced to go through an unnecessary step each time a new post is created. Just my $0.02.
Helen Hou-Sandi 6:04 pm on April 11, 2013 Permalink | Log in to Reply
I think this is a good compromise between representing the “choose once” part and not blocking users from just writing a new post as they currently can. What’s currently in trunk definitely does not reflect that it’s (generally) a one-time format selection before you get started. I think with smart wording in the feature pointer letting the user know that they can turn this off in screen options in addition to the filter that’s already been committed, it will work out okay.
Question about the “just start typing to make a standard post” interaction, though – what happens to the switcher? Does it disappear and cause everything to shift up while the user is typing? That seems less than ideal to me.
Mark Jaquith 6:25 pm on April 11, 2013 Permalink | Log in to Reply
I would animate it, so it’s not jarring.
https://medium.com/design-ux/926eb80d64e3
sara cannon 6:31 pm on April 11, 2013 Permalink | Log in to Reply
wow neat article
Chip Bennett 6:09 pm on April 11, 2013 Permalink | Log in to Reply
Crazy thought: what if the big ol’ post format icons were stacked vertically, to the left of the post editor (i.e. a third column on the post-edit screen)?
Still have the everything-grayed-out-before-selection UI, but then let the icons remain where they are after selection.
That would allow for easy switching, and would not cause the UI to jump around with appearing-then-disappearing icons above the post editor.
thirzah 6:13 pm on April 11, 2013 Permalink | Log in to Reply
(random person chips in) Love it – but minor thought – if they are at the top, and (what looks likely to be) more meta boxes pushing post/data entry ever downwards, would it be possible to make the ‘publish’ box pinnable, or copied at the bottom, or something? – Yours, Lazy Scroller
Mark Jaquith 6:25 pm on April 11, 2013 Permalink | Log in to Reply
The idea is that the picker would slide up after you’ve chosen.
sara cannon 6:19 pm on April 11, 2013 Permalink | Log in to Reply
For responsive screens, we can wrap the icons. because they will be eliminated after choice – we don’t have to worry about real estate
980: http://s.sar.ac/image/3B2H2v0P1841
768 Option 1: http://s.sar.ac/image/1D1e002x2i0X (5 across slightly spread out)
768 Option 2: http://s.sar.ac/image/2a3u3v3E3p03 (5 across slightly spread out & centered)
nathanrice 6:30 pm on April 11, 2013 Permalink | Log in to Reply
I have some deeper issues with the new Post Formats, but first let me say that I like the idea of a “decision first” approach with the ability to change in the publish box. Makes a lot of sense to me, and doesn’t clutter the post UI with buttons. It’s a little out of the way, which may have UX implications, but the initial decision path more than makes up for that.
As for the Post Formats strategy itself, I’m troubled by the decision to turn this feature on by default. From reading through a few trac tickets, I can see the logic behind why this decision was made, but it still seems like it’s going to be a bit of a shock, especially to theme developers who may not see this coming, and certainly to users who will now have a UI that their theme isn’t at all prepared for.
If this is the wrong place for this discussion, please tell me where I can go to bring this up with the powers that be. I’d like to understand the rationale if there was no other alternative, but otherwise, I’d like to see if there isn’t a better alternative than what we’ve got currently. And if my initial assumption is incorrect, I apologize.
Chip Bennett 6:34 pm on April 11, 2013 Permalink | Log in to Reply
I like it, for no other reason that it ensures data portability and consistency from Theme to Theme.
Think of it this way: the UI merely directs the way that certain data get added/saved – such as attaching a video and referencing it as post meta data. Those sorts of things really do need to be standardized, and this approach goes a long way in that regard.
nathanrice 6:43 pm on April 11, 2013 Permalink | Log in to Reply
You may like it, but I’m trying to consider what the reaction might be from hundreds of thousands of users who have themes that aren’t prepared to do anything special with these post formats.
But I’ll move the discussion to http://core.trac.wordpress.org/ticket/23930 as this doesn’t seem to be the place to best flush it out.
John Blackbourn (johnbillion) 8:11 pm on April 11, 2013 Permalink | Log in to Reply
WordPress now filters the post content of unsupported post formatsto provide structured output: http://core.trac.wordpress.org/ticket/23347
sara cannon 6:37 pm on April 11, 2013 Permalink | Log in to Reply
to my knowledge, if your theme does not register post formats and if you do not have any posts already using formats – the UI does not show up.
Mark Jaquith 6:39 pm on April 11, 2013 Permalink | Log in to Reply
That’s what is proposed here. Not yet implemented.
http://core.trac.wordpress.org/ticket/23930
Mark Jaquith 6:39 pm on April 11, 2013 Permalink | Log in to Reply
http://core.trac.wordpress.org/ticket/23930
Hal Gatewood 6:39 pm on April 11, 2013 Permalink | Log in to Reply
Rough potential tabbed idea… http://goo.gl/143Zu
Mark Jaquith 6:40 pm on April 11, 2013 Permalink | Log in to Reply
What’s the upside of enclosing them all?
Hal Gatewood 6:41 pm on April 11, 2013 Permalink | Log in to Reply
I guess the idea is more about the arrow next to the ‘Add New Post’ that could slide down the options.
Mark Jaquith 6:43 pm on April 11, 2013 Permalink | Log in to Reply
After the fact? Don’t think that would be very discoverable. But we could explore a __Change_format__ link to the right of “Edit Video Post”.
Hal Gatewood 6:55 pm on April 11, 2013 Permalink
Yeah don’t think my idea works in an Add/Edit workflow.
The format switcher like sara had is probably the way to go: http://s1.ran.ge/content/uploads/2013/04/Screen-Shot-2013-04-11-at-1.59.19-AM.png
Drew Jaynes (DrewAPicture) 7:40 pm on April 11, 2013 Permalink | Log in to Reply
I really like this concept a lot better. Plus, there’s parity with the hide/show overlays we used in the menus UI refresh.
The thing I’ve consistently heard from talking to people about the new formats UI is that an intermediary choice step would solve a lot of the headaches and I think take this approach over what we have now will be a big step in the right direction.
Archetyped 4:18 am on April 12, 2013 Permalink | Log in to Reply
“In Page decision with post editor greyed out” seems like the best option as others have noted.
I agree with @markjaquith that clicking the title/description fields should automatically select the default post format and close the selection UI, however, I would suggest it be even a bit more flexible than that. I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format (e.g. standard post) and close the post format selection bar just as if someone had selected the format itself. This allows for a much larger hit target for the user to get to the editor and start creating content without much delay.
I think it was also suggested that the post format selection UI go away immediately if the user starts typing in the title field (focused by default). I like this as well.
In addition, how about an option in WP’s settings to allow the user/author to set the default post format. The editor fields for the selected post format’s would be displayed by default when creating new posts and the appropriate button would be highlighted in the post format selection UI.
This would be a productivity boost for users who post mostly videos, or mostly links, or mostly status messages, etc.
sara cannon 4:53 am on April 12, 2013 Permalink | Log in to Reply
“I would suggest that clicking anywhere outside of the “post format selection UI” should automatically select the default post format ” — yes! I’m not sure if this was mentioned in the above threads but this is definitely something that should be included.
@melchoyce also has mentioned the idea of setting a default post format in a comment above. I think that idea should definitely be explored further and is a logical next step. Part of why I think this is – we have ten formats with no hierarchy for preference.
Grant Palin 6:48 am on April 12, 2013 Permalink | Log in to Reply
I generally dislike popups, modal or otherwise, when they are not really necessary. I could have made an exception in this case since the choice it would provide would determine the appropriate UI. It’s something that kinda needs to be done up-front.
That said, it’s still a jarring change, and the better option may be the row of icons above the editor, which maybe shrinks or fades when a choice is made in order to stay out of the way. At least it’s top and center that way.
Avryl 11:24 am on April 12, 2013 Permalink | Log in to Reply
I don’t really get the concept of selecting a post format. All post formats do more or less the same, you can add media, add a title, add a description/content. Why not just have one and detect what’s posted?
Or maybe, have two buttons in the media uploader, one “insert in post” and one “make an image post”, same for a gallery, video and audio. When the user adds a link to the content, give the option to make a link post. Maybe this would be more obvious if there’s an “add link” button next the “add media” button or by somehow integrating them both in TinyMCE. A status post can be created if there’s no title.
I’m just wondering, but what happens when a user inserts an image into the content of a standard post format and nothing else? Then that would be an image post right? Maybe it’s possible to detect if the user assigns the “wrong” post format, as in the UI test?
jrbeilke 2:45 pm on April 12, 2013 Permalink | Log in to Reply
Nicely done Sara. I also prefer the in-page decision for post formats and think it stands out more than the current beta UI without being too obtrusive.
I am concerned about all of the new decisions that a writer will be faced with when adding a new post. At a minimum the screen options/theme support should help to control the available post formats. Defaulting to a standard post when no selection is made would also streamline the process for those that want to stick with their current workflow.
Another issue that I’ve run into while testing is the admin Posts screen, and posts without a title. It would be nice to tweak the Posts screen to show a snippet from the post if no title has been set. Maybe it’s just me, but with some of these new post formats (ie Aside and Status) a title isn’t necessary, but makes administration difficult without it.
Posts without titles – http://i.imgur.com/M40SwIR.jpg
Mockup Posts with snippets – http://i.imgur.com/WtwfSnt.jpg
Konstantin Kovshenin 2:46 pm on April 12, 2013 Permalink | Log in to Reply
Related/possible solution: #24011
jrbeilke 3:09 pm on April 12, 2013 Permalink | Log in to Reply
Thanks, didn’t see that ticket.
Looks like it might work, but if it’s tied into save_post then what if there are already existing posts without titles? Will the user have to go through and re-save all of the posts that are missing a title?
Matt Mullenweg 8:10 pm on April 14, 2013 Permalink | Log in to Reply
Also as food for thought: we’re supporting too many formats. Anything where you’re giving a user 10 choices before they get started is going to be rough from a usability and design perspective, especially given it’s not really obvious what that choice does not just to the form, but to the post when it’s published.
There is some direct and indirect data about which formats are most used, perhaps we could apply our 80/20 principle to just supporting the 3-4 formats that would make the biggest difference to users.
Ipstenu (Mika Epstein) 3:49 am on April 15, 2013 Permalink | Log in to Reply
What if you consolidate?
Image and Gallery – Make it one, and if someone puts in an image, it shows just one. If it’s a gallery code, or they attach mulitple images, then use a gallery? To steal a page from Tumblr, that’s how they do it.
You could do the same for audio/video maybe. Though that would be harder to theme in both cases.
sara cannon 10:51 pm on April 16, 2013 Permalink | Log in to Reply
^ I really like this solution – we just use the format “image” in the UI, but then when a user attaches more than one, it automatically makes it the “gallery” format in the background (no need to manually switch). It solves a UX problem where someone might decide to upload more than one after-the fact. (image->gallery is really one of the main use cases for decision-changing that I foresee)
Mark Jaquith 12:46 pm on April 15, 2013 Permalink | Log in to Reply
The formats have been defined in code and in the codex for a while, so dropping some formats would result in data loss for some.
One thing that has been considered is hiding less-used formats, so that instead of 10 options, you might have 5 options and a “more” button.
sara cannon 10:46 pm on April 16, 2013 Permalink | Log in to Reply
Another +1 for hiding seldom used ones
Ian Stewart 3:21 pm on April 15, 2013 Permalink | Log in to Reply
+1 for hiding seldom used formats.
sara cannon 11:28 pm on April 16, 2013 Permalink | Log in to Reply
I don’t know which formats are the least used – but from a visual perspective, it is kind of a game changer. http://s.sar.ac/image/2B2B1t2r3N2l thoughts?
Andy Peatling 5:09 pm on April 18, 2013 Permalink | Log in to Reply
I posted usage stats for frontend WordPress.com posting here: http://core.trac.wordpress.org/ticket/19570#comment:154
chabis 10:32 pm on April 17, 2013 Permalink | Log in to Reply
There needs to be some careful rethinking about the post formats. two assumptions:
A. many users want to create a post with a single content (gallery, audio, image, etc) and a post format is fine for that.
B. many other user want to create a post that contains an image, a text, another image, then a video, etc.
Now how do you make clear to the user that A. is not equal to B.? A. is a complete view change from a Post to a Gallery whereas B. is a Post with multiple content elements.
In my point of view, and as mentioned before, the user gets confused by post-formats and the icons. Especially the icons can me users think that they need to click on the format to insert a media. And at the same time the decision hurdle is too high, maybe a user changes its mind during the editing process, what do you do then?
Maybe we need to think about the editor in a slightly different way. It should be intelligent enough to make assumptions with the added and future content. The text-editor of koken.me is just a wonderful inspiration for that:
http://help.koken.me/customer/portal/articles/632095-text
Anointed 6:37 pm on April 21, 2013 Permalink | Log in to Reply
WOW, just WOW, that koken admin is SWEET! Especially the media manager. thnx for the link, not sure I would have ever found it on my own. Really gives the WordPress media manager something to aim for.
Anointed 6:34 pm on April 21, 2013 Permalink | Log in to Reply
Not sure where to make this request, but this seems as good a place as any.
I actually like the new post-formats setup, especially the video format where the actual player shows up on the page after clicking publish. This makes it so much easier to understand what is happening and to make sure the video oEmbed url works and you have the right video.
My only request, is it would be nice to have the video player display PRIOR to clicking publish.
Right now, we are able to make sure we have everything else right prior to publishing, but cool as this new player showing up is, we still don’t know that everything is perfect prior to publish as we can’t see the player.
So, please make the player show up as soon as the oEmbed url/embed code/etc is inputted into the box.