Make WordPress Core

Opened 15 years ago

Closed 12 years ago

#11406 closed enhancement (fixed)

Why is the View Post opening in a new window once again?

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by: azaozz's profile azaozz
Milestone: 3.5 Priority: normal
Severity: normal Version: 2.9
Component: UI Keywords: has-patch commit
Focuses: Cc:

Description

There had been a ticket over in 2.8, and if memory serves the general agreement was that opening the preview link in a new window made sense, while opening the view post link in the same window was preferable. (Or maybe this discussion was on the View Site link...)

r12020, I am assuming, re-introduced the clumsy behavior two months ago. Could we change this back to where the general agreement stood? It's quite annoying to no longer be able to Edit, Save Chances, and then View Post without ending up with a) an extra tab and b) WP later complaining that a new version of the post or page exists because the useless tab was not closed on the spot.

Attachments (2)

11406.diff (1.9 KB) - added by scribu 15 years ago.
Remove target="_blank" when post/page is published
11406.patch (1.5 KB) - added by SergeyBiryukov 13 years ago.

Download all attachments as: .zip

Change History (45)

#1 @Viper007Bond
15 years ago

Big +1

This drives me nuts. If I want it to open in a new window, then I'll make it open in a new window.

#2 @caesarsgrunt
15 years ago

Big +1 from me too.

@scribu
15 years ago

Remove target="_blank" when post/page is published

#3 @scribu
15 years ago

  • Keywords has-patch added

#5 @markjaquith
15 years ago

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

#6 @janeforshort
15 years ago

  • Severity changed from major to normal

Personally I'd rather have the live site in a separate tab from the editor so I can go back and forth, but whatever the behavior is in 2.8.6 is what we should have it as in 2.9. I'd like to do some testing around this before 3.0, as I remember it coming up in testing for 2.5 and being somewhat contentious based on different styles of workflow. Might be one of those things that actually does deserve an option in settings, though I'm sure Matt would say that it should be a plugin rather than an option. :)

#7 follow-up: @scribu
15 years ago

Jane, there's a significant difference:

If the link is set to open in the same window, you can make it open in a new window.

Whereas, if the link is set to open in a new window, you can't make it open in the same window.

#8 @filosofo
15 years ago

And it's mistake #2 of Jakob Nielsen's classic top 10 web design mistakes.

If you want a new tab, click the scroll wheel.

#9 @azaozz
15 years ago

Replying to janeforshort:

Personally I'd rather have the live site in a separate tab from the editor so I can go back and forth, but whatever the behavior is in 2.8.6 is what we should have it as in 2.9.

In 2.8.6 it still opens in a new tab/window.

I'd like to do some testing around this before 3.0, as I remember it coming up in testing for 2.5 and being somewhat contentious based on different styles of workflow.

The View Post button acts similarly to the Preview one and seems mostly used to preview the post. Don't think it's often someone would edit/write a post then go to the front-end to read it. Most users would want to preview it and eventually fix typos or make changes which is faster/easier when the front-end is in another window/tab.

There is also the case where the users have both the admin and the front-end opened in two windows side by side (on a wide screen), making changes in the admin and previewing them straight away. That's how the Preview button works, updating the post in the same window. We could make the View Post act the same (instead of target="_blank" have target="viewpost").

This is also dependent on the settings in the browser. Newly opened tabs can be set to get focus (show) or open in the background.

I'm going for "wontfix" on this since it's not a regression or new behaviour in 2.9.

#10 follow-up: @caesarsgrunt
15 years ago

But if you click edit on the frontend, it opens in the current tab. (Good.)

If you then edit and click view post, it opens in a new tab/window. (Bad.)

This means I have two tabs open with different versions of the same article.

#11 in reply to: ↑ 10 @azaozz
15 years ago

Replying to caesarsgrunt:

But if you click edit on the frontend, it opens in the current tab. (Good.)

If there's an Edit link on the front-end, it's part of the theme or a plugin. Don't think we have control there. It may also let you edit the post in place.

#12 @caesarsgrunt
15 years ago

Yes, it's part of most themes including the standard one. You add it with the function {{{edit_post_link()}} That's not the point. The point is that when you've come from the front end, you want to be able to go back to it without opening a new tab/window.

#13 @caesarsgrunt
15 years ago

Sorry about the formatting there. Should obviously be edit_post_link().

#14 in reply to: ↑ 7 @Denis-de-Bernardy
15 years ago

Replying to scribu:

Jane, there's a significant difference:

If the link is set to open in the same window, you can make it open in a new window.

Whereas, if the link is set to open in a new window, you can't make it open in the same window.

Agreeing 100%. I really don't mind the behavior for the preview button. But please, please. Not the View Post link.

#15 @Viper007Bond
15 years ago

I prefer the preview button opening in a new tab because I'm likely not done writing the post and want to literally preview it.

However after I hit Publish and the View Post link shows up, I'm likely done writing the post (and using the admin area) and am just clicking it to see how it looks on my blog.

And technically you can avoid having the link open in a new tab, but dragging the link to the address bar (so it'll open in the same tab) is really annoying.

#16 follow-up: @azaozz
15 years ago

  • Milestone changed from 2.9 to 3.0

The question seems to be: do we want to change the behaviour now and make it inconsistent with the View Post button (next to the permalink) without doing some UX testing.

#17 in reply to: ↑ 16 @Denis-de-Bernardy
15 years ago

  • Milestone changed from 3.0 to 2.9

Replying to azaozz:

The question seems to be: do we want to change the behaviour now and make it inconsistent with the View Post button (next to the permalink) without doing some UX testing.

Not, the real question is why has it changed at some point without any UX testing.

In this thread, everyone seems to agree that when you click on the View Post link that shows towards the top the editor when you've saved your post or page, you merely want to return to your site in the same tab. And that when you click the Preview/View *button* to the right, you want to open a tab.

That was the behavior in 2.8, and based on this thread it's desirable to return to this behavior before releasing 2.9.

#18 @waclawjacek
15 years ago

  • Cc mail@… added

In my opinion, NO links should be opened in new windows - it should be up to the viewer to select whether they want to open it in the same or a new window, but that's probably something a new trac ticket should be created for.

#19 @caesarsgrunt
15 years ago

I tend to agree with you, waclawjacek, but there are a few cases such as the preview button where a new window is arguably better, because it allows you to repeatedly preview again and again in the same new window which was opened the first time. (using target="viewpost").

#20 @Viper007Bond
15 years ago

Just to everyone's clear:

2.8.4 = same window
2.8.5 = new window

#21 follow-up: @azaozz
15 years ago

I would suggest for everybody (3-4 people?) that want this changed to do their own mini UX research applying the 80/20 rule (don't forget you are the researcher not the subject of the research).

There are five status messages that include a link:

  • Post updated
  • Post published
  • Post submitted
  • Post scheduled for
  • Post draft updated
  1. Should they open in the same window?
  1. Should they open in a new window?
  1. Should they be inconsistent (some in the same/some in new) and why?

Personally I don't mind either way as I don't seem to use that link at all. I use the View Post button as it's a bit closer and requires less mousing to get to.

#22 @caesarsgrunt
15 years ago

The main point of this ticket is that the behaviour has been changed without discussion in a point release. It should be reverted pending discussion.

#23 in reply to: ↑ 21 @scribu
15 years ago

Replying to azaozz:

Personally I don't mind either way as I don't seem to use that link at all. I use the View Post button as it's a bit closer and requires less mousing to get to.

Here's another ideea: remove the link altogether, since we already have the button on the Actions box.

That notice is the only one in the admin area that has a link after the message.

#24 @caesarsgrunt
15 years ago

That would also require discussion and testing. And it would make it impossible to go back to the frontend after coming from it with the Edit Post link - edit_post_link().

#25 follow-up: @scribu
15 years ago

And it would make it impossible to go back to the frontend after coming from it with the Edit Post link - edit_post_link().

Wouldn't the "Preview Changes" button handle that?

Btw, the "Go back" link was removed some versions ago.

#26 in reply to: ↑ 25 @caesarsgrunt
15 years ago

Replying to scribu:

And it would make it impossible to go back to the frontend after coming from it with the Edit Post link - edit_post_link().

Wouldn't the "Preview Changes" button handle that?

No, because that opens in a new window/tab, causing the problem I mentioned above: you click Edit in the frontend, but then after saving the post the only link back to it opens in a new window/tab rahter than just going back to it in the same one.

#27 @strider72
15 years ago

If nothing else, it should be consistent.

All the discussion of which link on which page does which behavior tells me that We're Doing It Wrong. ( http://xkcd.com/463/ ) I shouldn't need a flow chart to tell me what clicking this button is going to do, vs. clicking the same or similar on a different page or slightly different circumstance.

Pick one! ONE! Harrumph.

#28 @strider72
15 years ago

...and as it's safe to assume that I would not suggest making every link in the Admin open a new page, I'll let you guess which "one" I choose.

#29 @caesarsgrunt
15 years ago

I would suggest that every link opens in the same page, and buttons such as preview open a new page, since this is useful for switching between preview and edit.

But mainly, we should revert to the previous behaviour (link opens in current page) until UX testing has been done.

#30 @waclawjacek
15 years ago

That's true -- the less differences in almost the same things the better.

(P.S.: I love xkcd references. :))

#31 @ryan
15 years ago

[12406]

We shouldn't have changed this in a maintenance release. Reverted. We can discuss this during 3.0 if we want to revisit.

#32 @ryan
15 years ago

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

#33 @jane
14 years ago

  • Milestone changed from 2.9 to Future Release
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to enhancement

Reopening, as there are two view post links (one link, one button) that have different behaviors, and we should standardize. Would like to fix for 3.3..

#34 follow-up: @JohnONolan
14 years ago

Example of Jane's comment above: http://cl.ly/5EK0

Either way, the links should be consistent. I think they should both open in the same window, if people want a new window they should cmd+click (or similar), not have browser behavior forced upon them.

#35 in reply to: ↑ 34 @mcgaritydotme
14 years ago

Replying to JohnONolan:

Either way, the links should be consistent. I think they should both open in the same window, if people want a new window they should cmd+click (or similar), not have browser behavior forced upon them.

+1. This behavior emulates the last fix of this issue.

#36 @SergeyBiryukov
13 years ago

Attaching the patch, as per Jane's suggestion.

#37 @JohnONolan
13 years ago

  • Keywords dev-feedback needs-testing added

#38 @nacin
13 years ago

  • Keywords commit 3.4-early added; dev-feedback needs-testing removed

#39 @SergeyBiryukov
13 years ago

  • Keywords 3.5-early added; 3.4-early removed

#40 @JohnONolan
13 years ago

  • Keywords ux-feedback added

Why punt a 2yr old ticket that has both "has patch" and "commit" as tags? :(

#41 @SergeyBiryukov
13 years ago

Since we are past freeze and the ticket is categorized as an enhancement, not sure if it still can make it into 3.4.

#42 @SergeyBiryukov
12 years ago

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

#43 @markjaquith
12 years ago

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

In [21189]:

Standardize our "View Post" new-tab/no-new-tab behavior. Committed this thirtieth day of June, Anno Domini MMXII. May peace and good sense forever reign in this realm. Uh... Amen.

props SergeyBiryukov. fixes #11406.

Note: See TracTickets for help on using tickets.