#18306 closed enhancement (fixed)
Make sample permalink clickable
Reported by: | scribu | Owned by: | helen |
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 3.2 |
Component: | Editor | Keywords: | has-patch needs-testing make-flow has-screenshots |
Focuses: | ui, administration | Cc: |
Description (last modified by )
Following the lead from #17282, the "View Post" button next to the sample permalink is also just a link to another screen.
I propose we get rid of it and make the sample permalink itself clickable
Attachments (16)
Change History (79)
#3
@
13 years ago
- Keywords dev-feedback added; ux-feedback removed
- Milestone changed from Awaiting Review to 3.3
- Version set to 3.2
Fine by me. Can you remove the underline, though? I know we have inconsistencies here and there (to be cleaned up in the CSS purge) but the general standard for admin links is blue with no underline. No reason we can't do this for 3.3, I'd think.
#5
@
13 years ago
- Keywords needs-testing added; commit removed
18306.3.diff removes remaining calls to makeSlugeditClickable.
Would like to get another pair of eyes on the interaction.
#10
@
12 years ago
I tested out the interaction, but the one thing it removes is the clickable yellow-highlighted slug. This was really handy, to the point where I always click that and never the Edit link.
We *could* keep both interactions. If you click the slug itself, you get the input shown. If you click the rest of the link, it opens in a new window.
I can apply these two patches to sparklemotion so Jane can take a look. Uploading the variant as 18306.4.diff.
#11
@
12 years ago
A little more CSS:
- Hover on underline instead of orange - makes it clearer that it's the whole URL that's the link
- Text cursor when hovering over the editable slug
- Blue :)
#13
@
12 years ago
- Keywords ui-feedback added
- Milestone changed from 3.4 to Future Release
Good, but too late for a UI change like this.
#16
@
12 years ago
Instead of making the link work (clickable) and having the last part of it open for editing, i.e. still clickable but acts differently, would it be less confusing to have the word "Permalink:" be the link to view the post, complete with a `title="View Post"`.
#17
@
12 years ago
attachment:18306.6.diff is a refresh of the previous patch.
That said, I had the same thought as azaozz while I was testing it -- it's strange and a bit confusing to click what looks like a normal link and have it sometimes open and sometimes pop into an editing mode depending on where exactly I clicked. Uploading the patch anyway, in case that's the way we want to go.
#19
follow-up:
↓ 21
@
12 years ago
18306.7.diff makes a few small tweaks to sabreuse's 18306.6.diff
I stripped out the yellow edit link at the end - making the entire URL link to the post (including the /media-test2/ part). To edit the permalink, you'd simply click the "Edit" button.
Before clicking the edit button
and after
#22
@
12 years ago
I rather miss the yellow highlight because it indicated which part of the permalink you are really able to edit. Clicking that part to edit was nice, but once the rest of the permalink is a link, the interaction is indeed kind of weird. Would like to see if we can still indicate which portion is the editable portion, though.
As an example, a mockup from lessbloat with the slug portion bolded:
#26
@
12 years ago
Testing the patch - I rather like the bold! In FF, clicking the input will only put the cursor at the beginning and not anywhere else. There's also a flash of outline in both FF and Chrome (OSX here).
#29
@
12 years ago
Issues from comment 26 remain. Text in the input should also probably not be bold.
#30
@
12 years ago
18306.10.diff removes the link when editing the slug. Turns out inputs inside links are a bad idea, and probably not valid anyway. I'm still personally liking the bold.
#31
follow-up:
↓ 33
@
12 years ago
- Keywords punt added
I went through this today. I think there are a few UX issues:
On drafts, it is not clickable. Normally, with drafts, a button doesn't exist. But I think hiding a button is different from text being linked versus not. Lower severity.
When you change the link, the hyperlink is updated to the new link. When you click it, you'll end up with a 404 (unless you get lucky and the permalink guessing canonical code kicks in). We could not update the hyperlink to the new link, but then you'd have a link showing one thing, and leading to another place. This is more blocking, and helenyhou and I agreed in IRC it should mean punt.
I'm just not convinced this results in a better experience.
#33
in reply to:
↑ 31
;
follow-up:
↓ 34
@
12 years ago
- Component changed from UI to Editor
Replying to nacin:
When you change the link, the hyperlink is updated to the new link. When you click it, you'll end up with a 404 (unless you get lucky and the permalink guessing canonical code kicks in). We could not update the hyperlink to the new link, but then you'd have a link showing one thing, and leading to another place.
I think this might actually mean this is a wontfix, as I have yet to imagine what the working alternative might be.
#34
in reply to:
↑ 33
@
12 years ago
Replying to helenyhou:
Replying to nacin:
When you change the link, the hyperlink is updated to the new link. When you click it, you'll end up with a 404 (unless you get lucky and the permalink guessing canonical code kicks in). We could not update the hyperlink to the new link, but then you'd have a link showing one thing, and leading to another place.
I think this might actually mean this is a wontfix, as I have yet to imagine what the working alternative might be.
The same thing happens to the current "View Post" button. This, however, is less obvious when the URL is not shown.
To fix this, we should probably link to the non-pretty permalink when we need to update the target of "View Post" to ensure canonical sends us to the right place. The same thing could happen for the link in the toolbar, automatically.
This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.
11 years ago
#36
@
9 years ago
- Milestone changed from Future Release to 4.4
Looking at this in conjunction with #18523, would be nice to finally fix this.
#37
follow-up:
↓ 40
@
9 years ago
This is also an opportunity to reduce view post and preview confusion on small screens as well as remove some button clutter.
https://make.wordpress.org/flow/2015/02/13/preview-and-view-post-confusion-iphone-6/
To those ends, I rather like the approach of hiding all of this beneath an icon next to the title. See screenshot.
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
9 years ago
#41
@
9 years ago
Let's leave bigger UX changes to another ticket or experiment or plugin or what have you please, if we try to do that right now we're going to be stuck forever. Note also that this has long been an extensible spot, which .com does not have to worry about when making UIs.
#43
@
9 years ago
18306.11.diff is a patch that is most of the way there. The big thing that needs to happen is to make the link not-a-link while editing, which I believe my old patch did. Right now it'll navigate if you click in the input (bad), and I'm still fairly certain inputs are not supposed to be inside links.
It also does not use the ?p=X
style permalinks when the slug is changed, although that is fairly easy to add. I guess it's a little odd but I don't actually find it all that alarming in practice. All of this is worth user testing, though. And I haven't thought about unit tests at all yet :)
This ticket was mentioned in Slack in #design by helen. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
#49
@
9 years ago
18306.12.diff is ready for testing, both by devs and for user testing. :)
#50
@
9 years ago
#52
@
9 years ago
I did some light user testing of this with @markjaquith (frequent/experienced user) and @sarcasmically (infrequent user) in person at WC Tampa. There are not usually non-WP users at a WordCamp, so I have not tested with one yet :) Here's what I noticed:
- Editing a permalink did not trip up either person. Mark did notice that the highlighted click-to-edit slug was gone and was now just a part of the link. For people who are accustomed to the click-to-edit slug, they may mis-click a couple of times before adjusting, which would be frustrating but not critical.
- Having a default state of no buttons except for the "Edit" one for the permalink slug made it much more obvious what that section was to be used for.
- The linked permalink sample was not obvious at all, and I'm becoming less convinced that it needs to link.
- Being asked to view a post on the front end from an initial edit screen is not actually a very natural task and definitely came across as a forced test. After updating a post, having the view post link in the notice is frequently used and that will not change.
- After using "Preview Changes" to view the post (also a more natural action from an edit screen than viewing the live version pre-update), sarcasmically eventually found the "View Post" link in the toolbar, and naturally found its "Edit Post" counterpart to go back to editing, which is a good thing about the toolbar link, which this proposal would also still keep.
I would still like to run more tests, especially with non-WP users and with a flow that feels more natural than "view the live version of this post you're ostensibly editing but haven't done anything to yet". However, I am going to commit this now, as that also attracts more eyes and I won't be hurt if we have to revert this. I just want this to be resolved one way or another.
This ticket was mentioned in Slack in #core by jeffr0. View the logs.
9 years ago
#57
@
9 years ago
Going to make the displayed slug longer since there's more space now and so the edit input doesn't feel like it's jumping around so much, but I think anything after that around improving this can be new tickets.
#59
@
9 years ago
I would suggest that the link opens in a new window by default. Most of the times the user needs to go back to the edit screen so this will be useful.
#61
@
9 years ago
See related #23432 with ongoing discussion about actually removing target="_blank"
from everywhere.
#62
@
9 years ago
After updating our varius sites to WP4.4 the changes to the post edit screen were a bit jarring. I had clients asking me where their 'view' button has gone and how do they get to it (they are just basic editors). I had to explain you press the blue 'permalink' link and that it takes you to the page.
I'm fairly against clicking on that link and it opening in a new window. I work on dozens of pages a day across multiple sites so the thought of opening up tabs for each seems like a bit much. I'd be happy if it were a setting or something similar under the 'writing' settings tab.
I posted a similar closed bug link (#34961)
Before:
After: