WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 7 months ago

Last modified 5 months ago

#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 scribu)

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)

18306.diff (3.5 KB) - added by scribu 5 years ago.
before.png (10.4 KB) - added by scribu 5 years ago.
after.png (9.3 KB) - added by scribu 5 years ago.
18306.2.diff (3.6 KB) - added by scribu 5 years ago.
18306.3.diff (4.6 KB) - added by scribu 5 years ago.
18306.4.diff (3.5 KB) - added by nacin 4 years ago.
18306.5.diff (4.4 KB) - added by helenyhou 4 years ago.
18306.6.diff (4.4 KB) - added by sabreuse 4 years ago.
18306.7.diff (4.5 KB) - added by lessbloat 4 years ago.
18306.8.diff (4.5 KB) - added by SergeyBiryukov 4 years ago.
Refreshed after [21592]
18306.9.diff (4.5 KB) - added by lessbloat 4 years ago.
18306.9-refresh.diff (4.5 KB) - added by DrewAPicture 4 years ago.
refresh
18306.10.diff (7.1 KB) - added by helenyhou 4 years ago.
Screen Shot 2015-09-15 at 9.08.35 AM.png (115.5 KB) - added by ryan 8 months ago.
Link, slug bits accessed via link icon next to title
18306.11.diff (6.1 KB) - added by helen 8 months ago.
18306.12.diff (7.1 KB) - added by helen 7 months ago.

Download all attachments as: .zip

Change History (78)

@scribu
5 years ago

@scribu
5 years ago

@scribu
5 years ago

#1 @scribu
5 years ago

  • Description modified (diff)

Before:

http://core.trac.wordpress.org/raw-attachment/ticket/18306/before.png

After:

http://core.trac.wordpress.org/raw-attachment/ticket/18306/after.png

#2 @ramiy
5 years ago

Lookes good!

#3 @jane
5 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.

@scribu
5 years ago

#4 @scribu
5 years ago

  • Keywords commit added; dev-feedback removed

18306.2.diff: removed underline.

@scribu
5 years ago

#5 @scribu
5 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.

#6 @ryan
5 years ago

  • Milestone changed from 3.3 to Future Release

Punting enhancements from 3.3.

#7 @jane
4 years ago

  • Milestone changed from Future Release to 3.4

#8 @hberberoglu
4 years ago

This will be good.

#9 @husobj
4 years ago

  • Cc ben@… added

#10 @nacin
4 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.

@nacin
4 years ago

@helenyhou
4 years ago

#11 @helenyhou
4 years ago

18306.5.diff

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 :)

#12 @ocean90
4 years ago

18306.5.diff looks good.

#13 @nacin
4 years ago

  • Keywords ui-feedback added
  • Milestone changed from 3.4 to Future Release

Good, but too late for a UI change like this.

#14 @helenyhou
4 years ago

  • Keywords ui-feedback removed
  • Milestone changed from Future Release to 3.5

#15 @helenyhou
4 years ago

  • Keywords needs-refresh added

#16 @azaozz
4 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"`.

@sabreuse
4 years ago

#17 @sabreuse
4 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.

#18 @scribu
4 years ago

  • Keywords needs-refresh removed

@lessbloat
4 years ago

#19 follow-up: @lessbloat
4 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

http://f.cl.ly/items/2Z2v2W3G23040f0S2R3H/slug-link.7.jpg

and after

http://f.cl.ly/items/1x0b3L1m2h0d3W11223p/slug-after-clicking-edit-link.jpg

Last edited 4 years ago by lessbloat (previous) (diff)

@SergeyBiryukov
4 years ago

Refreshed after [21592]

#20 @nacin
4 years ago

#21208 was marked as a duplicate.

#21 in reply to: ↑ 19 @ericlewis
4 years ago

[deleted comment]

Last edited 4 years ago by ericlewis (previous) (diff)

#22 @helenyhou
4 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:

http://f.cl.ly/items/1Y1i3a362G3W042E3P1C/bold-w-link.jpg

#23 @scribu
4 years ago

+1 for the bold slug.

#24 @husobj
4 years ago

+1 more for bold slug

@lessbloat
4 years ago

#25 @lessbloat
4 years ago

Slug made bold in 18306.9.diff.

#26 @helenyhou
4 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).

#27 @nacin
4 years ago

  • Keywords needs-refresh added

@DrewAPicture
4 years ago

refresh

#28 @DrewAPicture
4 years ago

  • Keywords needs-refresh removed

#29 @helenyhou
4 years ago

Issues from comment 26 remain. Text in the input should also probably not be bold.

#30 @helenyhou
4 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.

@helenyhou
4 years ago

#31 follow-up: @nacin
4 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.

#32 @scribu
4 years ago

  • Keywords punt removed
  • Milestone changed from 3.5 to Future Release

#33 in reply to: ↑ 31 ; follow-up: @helenyhou
3 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 @nacin
3 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.


2 years ago

#36 @helen
8 months 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: @ryan
8 months 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.

@ryan
8 months ago

Link, slug bits accessed via link icon next to title

#38 @ryan
8 months ago

  • Keywords make-flow added

This ticket was mentioned in Slack in #core-flow by boren. View the logs.


8 months ago

#40 in reply to: ↑ 37 @afercia
8 months ago

Replying to ryan:

I rather like the approach of hiding all of this beneath an icon next to the title.

FWIW I'm all for hiding anything that's between the title and the editor :) see #29838

#41 @helen
8 months 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.

#42 @ryan
8 months ago

#33895 - Editor: Reduce clutter between title and content by hiding permalink UI

@helen
8 months ago

#43 @helen
8 months 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.


8 months ago

#45 @melchoyce
8 months ago

@helen: Can you add some screenshots or a video of your patch in action?

#46 @wonderboymusic
7 months ago

  • Owner set to helen
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core by helen. View the logs.


7 months ago

#48 @helen
7 months ago

  • Focuses ui administration added
  • Keywords has-screenshots added

The link needs to be removed when editing, but here are a couple screenshots.

Initial view
http://s.hyhs.me/dMnI/image.png

Editing
http://s.hyhs.me/dN0B/image.png

@helen
7 months ago

#49 @helen
7 months ago

18306.12.diff is ready for testing, both by devs and for user testing. :)

#50 @DrewAPicture
7 months ago

With 18306.12.diff:

Initial view:
http://f.cl.ly/items/2s0d3y0p3M3k170q0g0s/Screen%20Shot%202015-09-27%20at%2011.52.06%20AM.png

Editing view:
http://f.cl.ly/items/1C1x0N1z2L1F3I3f0k0W/Screen%20Shot%202015-09-27%20at%2011.52.22%20AM.png

Last edited 7 months ago by DrewAPicture (previous) (diff)

#51 @DrewAPicture
7 months ago

.12 looks and works as I'd expect it to.

#52 @helen
7 months 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.

#53 @helen
7 months ago

In 34670:

Edit: Remove the redundant "View Post" button-link and link the sample permalink.

Previously there were two persistent "View Post" links on an edit screen: next to the permalink and in the toolbar. This would then become three links after a post was published or updated, as a link is also included in the admin notice. This is a lot of redundancy and visual noise for a flow that is not your primary action upon starting to edit a post. The "View Post" link next to the sample permalink was particularly bad because it is styled like a button, but unlike a button, does not keep you on the current screen.

Because the permalink is now linked, there is no highlighted slug that you can click to edit, but rather just the "Edit" button.

props scribu, lessbloat, sabreuse, SergeyBiryukov, DrewAPicture, helen.
see #18306.

#54 @helen
7 months ago

In 34671:

Sample permalink: Buttons still need the .button class.

Also fixes unit tests post-[34670]. The test methods have been slightly renamed because it is no longer a button. Hopefully this name will be more future-proof.

see #18306.

This ticket was mentioned in Slack in #core by jeffr0. View the logs.


7 months ago

#56 @DrewAPicture
7 months ago

@helen Can we call this fixed?

#57 @helen
7 months 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.

#58 @helen
7 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 34833:

Permalinks: Slightly lengthen the truncated slug for display.

This brings it closer to the width of the input so there is less jumping around of buttons. We can afford the space now that other buttons in the space are typically no longer there.

fixes #18306.

#59 @SGURYGF
6 months 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.

#60 @wealthy
5 months ago

Yea agree with @SGURYGF about opening in new tab at least

#61 @afercia
5 months ago

See related #23432 with ongoing discussion about actually removing target="_blank" from everywhere.

#62 @simonrcodrington
5 months 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)

Last edited 5 months ago by SergeyBiryukov (previous) (diff)
Note: See TracTickets for help on using tickets.