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 | Owned by: | 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)
Change History (45)
#6
@
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:
↓ 14
@
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
@
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
@
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:
↓ 11
@
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
@
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
@
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.
#14
in reply to:
↑ 7
@
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
@
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:
↓ 17
@
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
@
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
@
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
@
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"
).
#21
follow-up:
↓ 23
@
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
- Should they open in the same window?
- Should they open in a new window?
- 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
@
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
@
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
@
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:
↓ 26
@
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
@
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
@
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
@
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
@
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
@
15 years ago
That's true -- the less differences in almost the same things the better.
(P.S.: I love xkcd references. :))
#31
@
15 years ago
We shouldn't have changed this in a maintenance release. Reverted. We can discuss this during 3.0 if we want to revisit.
#33
@
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:
↓ 35
@
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
@
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.
#40
@
13 years ago
- Keywords ux-feedback added
Why punt a 2yr old ticket that has both "has patch" and "commit" as tags? :(
#41
@
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.
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.