#24046 closed task (blessed) (fixed)
Post Format UI change in response to testing
Reported by: | markjaquith | Owned by: | |
---|---|---|---|
Milestone: | 3.6 | Priority: | highest omg bbq |
Severity: | critical | Version: | 3.6 |
Component: | Post Formats | Keywords: | has-patch commit |
Focuses: | Cc: |
Description (last modified by )
We had user testing of the post format UI.
http://make.wordpress.org/ui/2013/04/09/post-formats-usability-test-round-4/
The feedback was sobering. It needs work. Somewhat paradoxically, at first glance, it seems like it is not obvious and intuitive enough before you've chosen a post format, and too much in the way when you have.
Sara Cannon mocked up some ideas, and one of them was pretty much what I was envisioning.
http://make.wordpress.org/ui/2013/04/11/saracannon-has-posted-her-take-on-a-new/
Here's the one that I like:
The proposed mechanics are as follows:
- This UI is only shown until you choose explicitly, or choose implicitly (by proceeding without choosing).
- After choosing, you can still change the format, but in the Publish metabox. You've chosen, so it shouldn't still be in your face.
- You can implicitly choose Standard by either typing in the focused title field, or clicking on title/content. So the experience there will be the same if you just want to start writing.
Dave Martin (lessbloat) has said he can get started on coding this up. Mel Choyce has said she can get large icons by tomorrow. If anyone else can help, please chime in. This is a super high priority. I want this sorted for beta 2.
This ticket is to track that effort.
If anyone can help with this, or has concerns/ideas, please chime in.
Attachments (26)
Change History (94)
#4
@
12 years ago
Don't like what I see in this screenshot.
I think that 99% of all posts are standard one, so this is like a Tumblr style posts, separating by post format, instead of categories.
So opening a new post page should immediately use a standard format, and if the user decides to use a chat format, then he just use it from the top list...
And the icons are too big....
#5
@
12 years ago
24046.diff is a first pass at this. A couple of notes:
- I'll kick off 2 more usability tests later this afternoon with this patch applied. I'll post the results to the Make/UI P2.
- I'd prefer to steer clear of graying out the editor on load if we can get away with not having to
- I'd also prefer to not add anything related to post formats in the "Publish" metabox if at all possible. It's just too far away. I feel like the approach I used is subtle enough to get out of your way, but still functional enough to change formats quickly/easily.
- If you start typing in the title after page load, it just selects the currently selected post format (which defaults to standard)
- I added a light grey box around the permalink div, else it kind of just floats there awkwardly.
On page load:
Once selected:
Smaller resolutions:
#6
follow-up:
↓ 8
@
12 years ago
I started another round of post formats usability tests, but stopped after the first one. I was testing trunk with #24046 and #24062 applied.
Tasks:
- Login
- Look at the Dashboard and get to add post from toolbar
- Add a (standard) blog post with title and text
- Preview your blog
- Add an image blog post, with image from a URL
- Add a video post, with YouTube video URL provided
- Add a link blog post
- Add a quote blog post
- Add a gallery post
- Preview your blog again to see all the posts
Test 9: http://wpusertesting.com/videos/DC7-9.mp4
- At 1:13, she wondered where the buttons went, but it didn't deter her for long.
- Fine
- Fine
- Fine
- She did everything that was expected, but when she published the post, it didn't really publish.
- She did everything that was expected (except she mistyped the video URL), but when she published the post, it didn't really publish.
- Fine
- 6:55 - "I like these buttons here on the top" she says about the post format buttons :-)
- Fine
- Fine
Observations:
From a UX perspective, this seemed to work flawlessly! Unfortunately, a couple of bugs were surfaced with this test:
1) Select image format -> Enter Link URL without entering a title -> Click publish -> Success message says the post was published -> but if you click "View post" you get a 404, and if you click "All posts" the post isn't there.
2) Select video format -> Enter Video URL without entering a title -> Click publish -> Success message says the post was published (and if you enter a valid video URL, it shows up embedded in the right spot on the page) -> but if you click "View post" you get a 404, and if you click "All posts" the post isn't there.
3) Select image format -> Enter a title -> Enter Link URL -> Click publish -> The post is published, but there is no image.
4) Select quote format -> Enter a quote without entering a title -> Click publish -> Success message says the post was published -> but if you click "View post" you get a 404, and if you click "All posts" the post isn't there.
I verified all of these on my local install. 1, 2 & 4 seem to all be related to not having a title.
So, this looks very promising, but I'd like to address these bugs first, before running any additional users through.
#7
@
12 years ago
there are tickets for the title thing - I think everyone thinks everyone else is looking at it - I will take a glance right now
#9
@
12 years ago
Doh. Totally overwrote lessbloat's original patch upload. But yay for using git locally and having a commit at that point.
.2.diff starts with lessbloat's patch and does the following:
- Remove the underline on the PF labels
- Don't hide formats bar when keystrokes are made in the post title.
- Always show the current format prompt text and icon.
- Reserve space for the sample permalink.
- Don't cause sliding on load.
- JS formatting, to pass JS linting.
- Fix JS regex replacement issue. Kill wp-format-set.
#10
@
12 years ago
I tested 24046.3.diff pretty thoroughly last night and I think it's working really well. Some sort of placeholder for the permalink might be a good idea simply because that blank space feels odd if it's not directly above the editor. I played with a couple options locally but didn't find anything I especially love. I'd like to see this get in so we can get some more eyes on it during beta.
#11
follow-ups:
↓ 14
↓ 20
@
12 years ago
Played around with 24046.3.diff as well. Noticed something odd. When I create an image format post, and publish it, I'm unable to delete it from the view all posts page. Is that just my install, or can you guys replicate it?
#12
@
12 years ago
Also, do you think we should treat the image post format the same way we treat audio and video (and include a textarea for them to paste an image URL)? As it stands, if the user selects the image post format, they can't paste an image URL.
- When you click "Select/Upload image" the left column is hidden, so there is no way to click the "Insert from URL" link.
- The user we just tested resorted to pasting the Image URL into the "Link URL" field thinking she was successful in the task.
#13
@
12 years ago
Also, do you think we should treat the image post format the same way we treat audio and video
I started doing this yesterday, and then stopped - I will do an alternate patch here which does that
#14
in reply to:
↑ 11
;
follow-up:
↓ 15
@
12 years ago
Replying to lessbloat:
Played around with 24046.3.diff as well. Noticed something odd. When I create an image format post, and publish it, I'm unable to delete it from the view all posts page. Is that just my install, or can you guys replicate it?
I just created a couple image format posts, and was able to click "trash" to send it to the trash. Then from the trash I was able to click "Delete Permanently" and it worked.
#15
in reply to:
↑ 14
@
12 years ago
Replying to aaroncampbell:
I just created a couple image format posts, and was able to click "trash" to send it to the trash. Then from the trash I was able to click "Delete Permanently" and it worked.
Sorry, I just discovered that it only happens when you leave the title out. So:
- Add new post
- Select image post format
- Click "Select/Upload image"
- Select an image
- Publish
- Go to edit.php
- Click "Trash" link
Expected
Success message shows and post is added to the trash queue.
Actual
Success message shows, but the post remains in the published queue.
#16
@
12 years ago
- Keywords has-patch added
24046.4.diff makes images work like audio / video - meaning, the image meta box can contain:
- attachment ID
- tag soup (any HTML)
- URL
- [caption]
Lots of changes, please test.
#17
follow-ups:
↓ 18
↓ 31
@
12 years ago
Here's another usability test with #24046.4.diff and #24062 applied.
Tasks:
- Login
- Look at the Dashboard and get to add post from toolbar
- Add a (standard) blog post with title and text
- Preview your blog
- Add an image blog post, with image from a URL
- Add a video post, with YouTube video URL provided
- Add a link blog post
- Add a quote blog post
- Add a gallery post
- Preview your blog again to see all the posts
Test 10: http://wpusertesting.com/videos/DC7-10.mp4
- Fine
- Fine
- Fine
- Fine
- Fine
- Fine
- 6:20 - He's uncertain how to add a link with text (he messes with it until 7:40, trying a couple of different things)
- Fine
- Fine
- Fine
Observations:
- Much, much better! Yay!
- The only thing he stumbled on was adding a link. Should we add a "Link Text" field in addition to the "Link URL" field?
#18
in reply to:
↑ 17
@
12 years ago
- Cc sararcannon@… added
@lessbloat: great tests! Link Text... as in what to call the link(title) or commentary on the link?
The UI could be more clear in both these instances... maybe the post content can have descriptive text that prompts in each formant instance. On the link format it could say something like "commentary on the link above" - thoughts?
Replying to lessbloat:
Observations:
- Much, much better! Yay!
- The only thing he stumbled on was adding a link. Should we add a "Link Text" field in addition to the "Link URL" field?
#21
@
12 years ago
Uncaught TypeError: Cannot read property 'url' of undefined
on media-editor.js line 194 when inserting media into the post from the media modal. Media is not inserted into the editor.
#23
follow-up:
↓ 26
@
12 years ago
Image format posts get mangled a bit. I see the following appended to the content.
” alt=”" />
#28
@
12 years ago
- Cc melissachoyce@… added
Only saw this new thread yesterday. Just wanted to make sure you guys have the 64px version of the icons I posted over in #19570. Let me know if you need any other resources or icon updates.
#31
in reply to:
↑ 17
@
12 years ago
Replying to lessbloat:
Here's another usability test with #24046.4.diff and #24062 applied.
[snip}
- The only thing he stumbled on was adding a link. Should we add a "Link Text" field in addition to the "Link URL" field?
The thing that stands out for me in that UX test is that he is repeatedly confused about the difference between the meta box content and the post content. For the link and quote he's pasting text into both places.
On links it's not obvious if the "link URL" is going to apply to the post title or what?
On the quote, it's not obvious if the link URL is going to apply to the post title, quote, quote source, or just show up as a link of it's own...
I think the semantics of calling the line "Link URL" for images, links, quotes and more leads to confusion. Perhaps it should be "Link URL for Image", "Link URL for Quote Source", etc...
#32
@
12 years ago
24046.6.diff uses smaller icons after choosing. This is just to show what it would look like, so I didn't do a transition effect but something would definitely be needed.
#33
@
12 years ago
24046-omnipresent-fades.2.diff
is my first pass. I kind of want to transition the highlighting to be more like johnjamesjacoby's example.
#34
@
12 years ago
First pass at JJJ's design. Someone may need to tweak the colors a little, but it seems to work pretty well.
#35
@
12 years ago
24046.7.diff is built off Mark's Omnipresent Fade and combines it with JJJ's design example
#36
@
12 years ago
24046.8.diff builds on Pete's patch which builds on Mark's. The only changes are removing some console.log() calls that seem to have snuck into Mark's patch, and fixing the issue Ryan pointed out where the add media button looked wrong after it was hidden and re-displayed (it was getting set to inline when it should have been inline-block).
#37
@
12 years ago
I've uploaded color icons at 32px and 64px if you want to play around with including color in selected formats.
#38
@
12 years ago
.10.diff does the following:
- Hides the Add Media button for Audio, Video, and Image - they all have inline media pickers, this is the confusion Ryan was alluding to
- Moves descriptive text above the title
- Shows descriptive text on page load
Anyways, this is my contribution to design-by-committee, no one's on IRC to discuss so I made a patch
#39
@
12 years ago
.10.diff regresses the editor height switching.
Issues with my .9.diff:
- Type a title, then delete it, then switch formats. Then type. The prompt text will remain, jumbling with what you've typed.
- When doing your first PF switch, there is no animation.
#40
@
12 years ago
24046.11.diff is based off .9 and fixes a bug where adding a title, removing it, and then changing post formats would cause the title prompt text to display even after typing in a title again.
#41
@
12 years ago
I am going to add a .12.diff in a few that will try not to regress while incorporating changes based off .11, and cleanup some overall non-lint-worthy codes
#42
@
12 years ago
.12.diff adds the things I mentioned previously and unifies the JS code styles into one that is somewhat agnostic:
- Uses eager whitespace as per WP JS standards
- Passes JSLint with the following command: jslint --nomen --bitwise --regexp --white wp-admin/js/post-formats.js
Please test, I think it all works
#43
@
12 years ago
.14.diff
is .13.diff
plus it fixes the issue with first animation from a non-UI format to a UI format not working.
#44
follow-up:
↓ 45
@
12 years ago
Randomly, while changing formats, an embedded Gallery will lose its TinyMCE placeholder. Switching to Text then back to Visual restores it. It's very odd, and I can find no way to reliably reproduce the issue.
#45
in reply to:
↑ 44
@
12 years ago
Replying to markjaquith:
Randomly, while changing formats, an embedded Gallery will lose its TinyMCE placeholder. Switching to Text then back to Visual restores it.
Related: #24177
#48
@
12 years ago
Needs responsive help for small screens. Seems like the containing box converts to a smaller and/or fixed height at a certain breakpoint.
#50
@
12 years ago
24046.16.diff ditches the console.log
s and makes the format selector thing's CSS more responsive
@
12 years ago
Remove the helper text, lighten the background gradient, modify the h2 tag text to include the post format
#52
@
12 years ago
Looking at the UI again, the Post Formats selection area is more or less a postbox at a special place. It is one of many "content management" features that are shown in postboxes.
However it is the biggest/heaviest "thing" on the screen, it is at the top, and the icon representing it is repeated three times. All that makes it the most important thing ever :) I know we want it to be easy to discover but maybe we overdid it a bit?
Another thing that may be missing is a title. All postboxes are clearly labelled so a user would never have to guess what they are for. For users that are not familiar with post formats (most users?) and have a theme that doesn't do anything special with post formats (currently most themes?) it would be pretty hard to discover what is this all about.
#53
@
12 years ago
I definitely want the post format switcher to go away when chosen, but it should be easy to bring it back. The button/link to bring it back should be at the same place. The choices should collapse or fold like an accordion, and there should be a way to expand again.
The reason for this is that selecting the format should usually be the first thing you do, or at latest when you save/publish. If you start writing content without having chosen a post format, format standard should be assumed and the UI silently go away.
The problem with the persistent UI for selecting a post format is that it may confuse the user to think that the icons should be clicked, to say, add an image, video or a gallery, when the correct action would be to click the "Add media" button.
We can't have to confusion that when a user who really wants a standard post, or don't really know or cares, writes a text and wants to add some image, clicks on the "Image" post format button and expects to be presented whit an add image dialog without any other changes.
So bring back the previous UI, but adjust the position of the "Change post format" link, and add some explanatory text to the importance of selecting a post format.
The post format UI could also be inactive by default, having a "Format standard. Select a different format"-button.
I think that making too prominent has brought us into a problem with possible confusion. If we lower the prominence, the confusion goes away, at least for those who, even after being presented the options, can't decide or can't understand the reason to decide. For those it must be ok to just go ahead with the standard format.
The post format icons/buttons (image, gallery, video in particular) must not be confused with the add media button for the standard, and default, format.
#54
follow-up:
↓ 55
@
12 years ago
We shouldn't hide the "Add Media" button when switching formats. I went to post a Status update, and couldn't include an image from the media gallery. Considering what Twitter and Facebook have taught us about the ease of including media in status updates/asides, we should probably follow suit here.
#55
in reply to:
↑ 54
@
12 years ago
Replying to johnjamesjacoby:
We shouldn't hide the "Add Media" button when switching formats.
There's an ongoing discussion on this topic in #24013.
#56
follow-ups:
↓ 57
↓ 63
@
12 years ago
Some thoughts on the UI with the image post format.
The insert image modal now contains the Link To option, and always links to the attachment page no matter what setting is selected.
This Link To option eliminates the need for the Link URL box, unless the "Image HTML or URL" is used instead. Since it stays on the screen, it's confusing and technically broken.
"Link URL" is geek speak. It means nothing to my mom.
The "Select or upload an image for your post" text is above the title text and not the image selection area. Maybe it should be below the title area?
It would be nice of the image above the link text "Select / Upload Image" were also hyperlinked to provide a bigger target area. In testing, I habitually try to click it. And the box around the "Select / Upload Image" kinda feels too big.
#57
in reply to:
↑ 56
;
follow-ups:
↓ 58
↓ 59
@
12 years ago
Replying to mindctrl:
Some thoughts on the UI with the image post format.
The insert image modal now contains the Link To option, and always links to the attachment page no matter what setting is selected.
I see this too and have received a few reports of the same.
This Link To option eliminates the need for the Link URL box, unless the "Image HTML or URL" is used instead. Since it stays on the screen, it's confusing and technically broken.
Seems like the two should be synced if both are retained. I can see keeping the one directly on the edit page with better copy. Like "Image click-through link".
"Link URL" is geek speak. It means nothing to my mom.
I prefer "click-through link".
The "Select or upload an image for your post" text is above the title text and not the image selection area. Maybe it should be below the title area?
This confused me too. Better copy might suffice.
Adding a patch with suggestions for copy changes.
#58
in reply to:
↑ 57
@
12 years ago
Replying to ryan:
Replying to mindctrl:
I see this too and have received a few reports of the same.
I desperately need @koop's intervention here - I think it is an edge case with the modal's frame state not setting certain data. Our impl is slightly off, but we know that, and @koop just needs to make change or 3. Will ping him.
#60
@
12 years ago
23298.patch certainly helps 23298 and should likely go in, but it doesn't seem to help this case.
#61
@
12 years ago
Don't focus to the Title field when it's not empty.
Happened a lot when I wanted to just use Space to scroll down the page, but accidentally deleted the title text.
#63
in reply to:
↑ 56
;
follow-up:
↓ 68
@
12 years ago
- Keywords commit added
Replying to mindctrl:
The insert image modal now contains the Link To option, and always links to the attachment page no matter what setting is selected.
Fixed in [24289]
I think all that's left here is to commit the copy changes in 24046.17.diff and then this can be closed.
#64
@
12 years ago
Lots of good work here. In the image format, I like the new toggle for the Image URL or HTML and how it shares the same space now.
I do wish the "Attachment Display Settings" were staying in the select image modal.
Without the "Link To" option, the workflow for linking to attachment pages or the media file is not good at all. The only way I know of in this to even get that info is to click "Edit Image", which opens a new tab/window, and copy the link for the file or attachment page, come back, click "Select Image", and then paste that into the "Image click-through link" box. This config pretty much assumes that people don't want to link to internal assets, or if they do they must jump through hoops to do so.
We also lose the ability to insert a thumbnail, small, medium, whatever size and easily linking to the full-size version. On the image format, where presumably one would want control over these things and where we've been able to do these things, it's disappointing to see these gone.
These features are accessible now in 3.5 when using image format, so it can be viewed as removing necessary features.
#65
@
12 years ago
On the image format, where presumably one would want control over these things and where we've been able to do these things, it's disappointing to see these gone.
The theme controls this. It knows better how much space it has.
#66
@
12 years ago
- Resolution set to fixed
- Status changed from new to closed
Spin off new tickets for any new issues.
#68
in reply to:
↑ 63
@
12 years ago
Replying to aaroncampbell:
I think all that's left here is to commit the copy changes in 24046.17.diff and then this can be closed.
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 http://s.sar.ac/image/0H3B2n0o241q