Last modified: 2012-11-04 11:32:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 23772 - Link to search the keyword after redirect from GO
Link to search the keyword after redirect from GO
Status: NEW
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: design
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-03 13:14 UTC by Subfader
Modified: 2012-11-04 11:32 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Mockup of a contextual bubble from search (119.25 KB, image/png)
2012-11-04 06:10 UTC, Daniel Friesen
Details

Description Subfader 2010-06-03 13:14:30 UTC
When the user is redirected from the GO feature, add a message in the contentSub (breadcrumbs) section on the landing page:

"You have been redirected here. Search [keyword]."

The last part would be a link to search the user's keyword(s). 

Maybe extend the message: You have been redirected here because [keywords] exists as page title. You can search {{SITENAME}} for "[keywords]".
But shorter is better imo. 


This would solve multiple problems:

- People just type and hit return, so they're often redirected without wanting it. So you in old monobook you used to go back and hit search again (becuase the keyword is lost in the search box after the GO redirect).

- In Vector GO is forced (by return and the icon). The official solution is to pick it from teh drop-down, but seriously: Who does that and 99% of the users even don't know that, they're just annoyed and confused.
Comment 1 Derk-Jan Hartman 2010-06-03 21:09:58 UTC
I think this is actually a pretty neat idea. I'm just not sure how feasible it is, with page caching and all...
Comment 2 Trevor Parscal 2010-06-03 21:11:14 UTC
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.
Comment 3 Subfader 2011-02-13 02:47:46 UTC
hmh, cache wins here i guess. Someone please close this as WONTFIX / INVALID.
Comment 4 Bawolff (Brian Wolff) 2011-02-13 03:37:12 UTC
(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.
Comment 5 Subfader 2011-04-06 20:45:51 UTC
hmh, but normal redirects are displayed the same way as i request.
Comment 6 Bawolff (Brian Wolff) 2011-04-06 21:13:59 UTC
(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 ).
Comment 7 Subfader 2011-07-03 17:37:19 UTC
Someone feel free to close this as WONTFIX
Comment 8 Bartosz Dziewoński 2012-09-30 11:43:57 UTC
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?)
Comment 9 Jesús Martínez Novo (Ciencia Al Poder) 2012-09-30 12:46:42 UTC
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.
Comment 10 Daniel Friesen 2012-09-30 14:51:29 UTC
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.
Comment 11 Daniel Friesen 2012-10-14 11:52:12 UTC
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.
Comment 12 MZMcBride 2012-10-15 00:31:51 UTC
(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.
Comment 13 Subfader 2012-10-15 09:19:01 UTC
 ---
 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.
Comment 14 Daniel Friesen 2012-11-04 06:10:33 UTC
Created attachment 11296 [details]
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.
Comment 15 Subfader 2012-11-04 11:32:59 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links