I think this is actually a pretty neat idea. I'm just not sure how feasible it is, with page caching and all...

This is an excellent way to provide a user with a form of undo - in that they performed an action which may have been unintended. I would support this change.

hmh, cache wins here i guess. Someone please close this as WONTFIX / INVALID.

(In reply to comment #1)

I think this is actually a pretty neat idea. I'm just not sure how feasible it
is, with page caching and all...

In the worst case I suppose one could have this done on the js side if the caching issues are really that bad.

hmh, but normal redirects are displayed the same way as i request.

(In reply to comment #5)

hmh, but normal redirects are displayed the same way as i request.

Normal Redirects use different urls (relative to the canonical version), which makes the caching point a non-issue ( When you look at [[WW2]] which is a redirect, the url still shows the version of the page name before redirecting - http://en.wikipedia.org/wiki/WW2 instead of http://en.wikipedia.org/wiki/World_War_II ).

Someone feel free to close this as WONTFIX

This is a neat idea.

Maybe we could add "?from=<search>" to the URL to work around the caching issue?

(And then, as a JavaScript enhancement, use HTML5 History API to remove it from there, so that when one copies the address, they don't get bogus "You have been redirected" message later?)

When you do a GO-search and the search engine redirects you to the article with that name, it could send an additional cookie (with a short expiration time, like 1 minute or so) with the target fullpagename and the original search term. Then the client JS may scan for the existance of such cookie and when it matches the fullpagename with the current fullpagename of the article then display that message (and optionally make the cookie expire so the message isn't printed again on page reload during the 1 minute the cookie will remain on the client).

This solution won't interfere with caching and won't leave additional query strings.

Sure, it would fail for browsers with cookies disabled, but it's a minor issue and that's usually what happens when you have cookies disabled anyway ;)

This proposal may fail on some race conditions:

• The user submit a second search form while the first one hasn't loaded the target page yet: The first result page may not get the message because the second search form already overwrote the cookie.
• The user open the same page or reloads while the cookie hasn't expired yet, the message would be displayed. Make the cookie expire (set the cookie with a past expiration date) when the message is processed would prevent this.

I already looked into the best way to handle this myself.

The plan is to add a "Not what you're looking for? You can instead search for <pages containing "...">.".

The way to do this is with JS. Listen for the submission of the search form. On submit save the search query into sessionStorage. On page view if you're on the searchpage discard it. Otherwise use it to insert that message.

sessionStorage is supported by just about every modern browser, in fact even IE8 supports it. sessionStorage is tied to the specific tab you are in, so even if you submit two pages at the same time it'll never be confused about what page to put the message on. If IE7- support is necessary we can use the same technique with a cookie fallback. It won't be as perfect but it's just for minor compat.

I think I actually started writing it somewhere (can't remember where it is). The hardest part is really just figuring out where to output the message and how to do it in a skin-independent way.

https://gerrit.wikimedia.org/r/#/c/27923/

Right now it uses a simple notification. I'm open for bikeshedding on the best location to put the message.

(In reply to comment #11)

https://gerrit.wikimedia.org/r/#/c/27923/

Right now it uses a simple notification. I'm open for bikeshedding on the best
location to put the message.

I read this bug a bit differently than you, I think. From what I can see, this bug would be solved by implementing a message along the lines of:

You're reading about [[{{FULLPAGENAME}}]]. [[Special:Search/{{FULLPAGENAME}}|Search Wikipedia]] for more resources about this subject.

I'm not sure where such a message would fit in to the user interface, but it would accomplish most of the goals of this bug, I think. And it would do so without the need to track where users are coming from, without the additional code complexity and weight of session storage and JavaScript, and it would do so consistently (not just on supporting browsers).

This bug has (wrongly, in my view) focused on tracking the status of a user (i.e., tracking whether the user came from a search or not). I'm not sure that this is important enough to support the current proposed implementation (Gerrit change 27923) over a simpler implementation that would be generically helpful (a path from an article subject to a search on the same site about that subject).

Others have suggested using server-side session variables for adding context to the user search experience. The argument being that local (client-side) session storage is inadequate for a good user experience, I guess.

You're reading about [[{{FULLPAGENAME}}]].
[[Special:Search/{{FULLPAGENAME}}|Search Wikipedia]] for more resources about
this subject.

This sounds like it could be there all the time? (bad idea)

This bug is about informing the user after a GO-Search why he landed on this page and how he can SEARCH the keyword instead.

Mockup of a contextual bubble from search

AHAH! Trying to find the proper placement for the "Not what you were looking for?" messages was tricky.

First I thought of putting it in the subtitle area. However that varied by skin. And it was obscure and potentially not user friendly.

Then I ended up implementing it using the notification area. But that's still not entirely an expected place to find it.

But I just thought of a better way to implement it. A contextual bubble coming from the search area.

Attached:

The bubble is a nice idea, esp. since you typed there.
But usability-wise I'd guess people's focus is on the upper left (heading) after page load.