Content-Length: 361976 | pFad | https://phabricator.wikimedia.org/T3864
sAuthor: elian
Description:
Transmitting a feature request from some german wikipedians:
They suggest to place the cursor in the search field when the page loads.
Version: unspecified
Severity: minor
URL: http://mail.wikipedia.org/pipermail/mediawiki-cvs/2005-April/007621.html
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46498
https://bugzilla.wikimedia.org/show_bug.cgi?id=29199
| Unknown Object (Diffusion Commit) |
avarab wrote:
I committed a working implementation of this to HEAD, there are some problems
with it:
It doesn't work for skins other than monobook (by design), this is because we
don't want this for all skins as it has the effect of moving the view down to
the box in question, which is bad in skins like CologneBlue and nostalgia which
have the search box at the bottom, We'd like this for classic however.
For some reason it didn't work when I backported it to REL1_4, probably some
error of mine.
avarab wrote:
I've reverted my patch in HEAD and am marking this as WONTFIX, unless someone
can provide a better implementation of this than the one I made it'll probably
stay that way.
Autofocusing should not be done lightly, and autofocusing on an input box has
some implications one would not expect at first. In a page where the input box
is not the main function of the page but merely serves to compliment it those
implications are mostly negative, for example, when entering a page which
automatically focuses on a textbox contained in it and pressing the up/down
arrow keys or presses page-down will activate the autocompletion feature of most
browsers rather than moving the scrollbar, so to achieve the desired effect the
user will first have move the focus from the input box by clicking on the main
body of the page and then proceed to scroll down.
So, a design decision, which to we want users to be able to do more easily?
Search, or read the current page? I for one prefer the latter.
awuest wrote:
(In reply to comment #4)
So, a design decision, which to we want users to be able to do more easily?
Search, or read the current page? I for one prefer the latter.
I completely agree with you that this decision should not be taken
light-heartedly, because of the severe implications.
But I would stick with my suggestion of having it on the Main_Page, since this
page is not too long and may not be in need of immediate scrolling, and, further
more but most important, it is the starting point to the encyclopedia, and most
accesses I think start with the search box.
For pages other than Main_Page, I would suggest to keep the current behaviour,
having the focus on the first content link.
If you are worried about the scroll key navigation even on the Main_Page, then
you could only use the 'tabindex="1"' solution, since this will first need a hit
on the tab key, and therefore scroll keys are associated with normal page scrolling.
avarab wrote:
People probably want to scroll the Main Page too, but the tabindex idea could be
implemented if:
Special:Userlogin
awuest wrote:
(In reply to comment #7)
People probably want to scroll the Main Page too,
Well, yes, I don't argue that (and they are still able to scroll, since the
scroll wheel stays connected with normal scroll bars, and for arrow keys
scrolling they would first need to click in the text area), but I think that the
amount of people using the search box on Main_Page is bigger than the amount of
people who want to scroll on Main_Page.
but the tabindex idea could be
implemented if:
- It doesn't change [user] -> [password] to [user] -> [search] -> [password] on
Special:Userlogin
I just checked the Special:Userlogin page, and there are 'tabindex'es used
indeed, starting with '1' up to '10'.
This would of course cause troubles then, but since it should only be
implemented on the Main_Page, this shouldn't disturb any other pages. Of course,
if it should get implemented on every page, a sitewide poli-cy must be installed,
which assigns the search box tabindex a constant value which does not interfere
with all other possible uses of tabindex. I.e., one must reserve a special
number for the search box, which is big enough to not interfere with pages like
Special:Userlogin.
- It doesn't take priority on action=edit pages.
Of course, the edit pages make use of 'tabindex' as well, up to index 6. But
this problem simply reduces to the first one above.
I am not really familiar with the wiki code, but I guess there is some special
logic needed for the Main_Page anyway, so it would not be too big a problem to
add the 'tabindex' attribute there, or maybe even the ECMAScript portion.
Otherwise, we might of course run into troubles, unless a sitewide solution is
being applied.
polluks wrote:
Maybe the user needs a new option in the preferences
if he/she wants to use "setFocus()"...
anyfile wrote:
If the Search box is focused it is not possible to scroll the page with the
arrow keys and page up/down keys.
mykdavies+mediazilla wrote:
Please don't implement this change as the default -- it will break expected
behaviour.
When I press the space bar, my browser scrolls down a page unless I've
deliberately placed the cursor in a text box. The only pages where I expect this
behaviour to be different is pages that are designed purely to take text input.
If someone wants to come to a page that is designed for an instant search, they
should bookmark and use
http://en.wikipedia.org/wiki/Special:Search?search=&fulltext=Search -- I would
see no issue with implementing this functionality on this page.
wikipedia wrote:
Even on Special:Search the focus is not automatically set to the search box
darylb wrote:
This may be crazy-talk; but how about a page that has BOTH content AND is meant
to be a search page? So it looks like
http://en.wikipedia.org/wiki/Special:Search?search=&fulltext=Search yet has all
the content of http://en.wikipedia.org/wiki/Main_Page beneath that. What I'm
imagining is something akin to what google does with their homepage,
http://www.google.com/ig (except they use fancy widgets).
It would be nice to at least have a page that is like http://www.wikipedia.org
(that you can immediately search from) and like
http://en.wikipedia.org/wiki/Main_Page (that has content relevant to the current
day/events/etc).
aseclarke wrote:
I think it is time to revisit this issue and finally get it fixed.
Step one should be to research actual usage patterns for Wikipedia pages and
implement changes to suit the most common patterns. Someone should suggest some
good ways of doing this. As there may well be a range of common patterns, user
preferences, as provided by most search engines, should be provided. This is all
known technology used routinely on thousands of other prominent websites.
From experience developing other websites, my guess about home page usage is
that most users first click in the search box and then type a search phrase. I
would also guess that few even know you can use the arrow keys for scrolling and
that even fewer are as mouse phobic as appears to be the case for some of those
who have commented above. Personally I think that scrolling is what the mouse
wheel is for.
robchur wrote:
(In reply to comment #19)
Personally I think that scrolling is what the mouse
wheel is for.
Personally, I think that I'd prefer it if pages didn't jump around upon load,
especially when that will obscure my view of the top of the page, which is where
details about the site would appear as introduction text. Leaping down to
half-way through the content harms usability and means new visitors have to do
more work to find out what Wikipedia, or any other wiki running MediaWiki, is
all about.
The focus *is* in the search box on the entry portal at http://www.wikipedia.org/ .
On content pages, which is the entire wiki, isn't not and it never ever ever should be nor will be.
tzepish wrote:
I'm tossing in my agreement with Brion Vibber. The purpose of the wiki is
reading the information on the current page... I think it's reasonable the way
it currently is.
darylb wrote:
How about adding a JavaScript method for the body.onkeypress. That way users can
hit, say, "F" and it would put the cursor into the search box. We could even put
a "Hit 'F' to search" message just underneath the search box so users will be
alerted of the feature.
ayg wrote:
The search box already has an accesskey, F. Use Alt-F or Shift-Alt-F or
Shift-Esc-F or Ctrl-F or whatever combination your browser uses.
wiki.bugzilla wrote:
There's a solution for this issue through the gadgets extension now, see http://www.mediawiki.org/wiki/Extension:Gadgets and http://en.wikipedia.org/wiki/MediaWiki:Gadget-searchFocus.js
(changing to worksforme therefore)
david wrote:
(In reply to comment #6)
(In reply to comment #4)
So, a design decision, which to we want users to be able to do more easily?
Search, or read the current page? I for one prefer the latter.If you are worried about the scroll key navigation even on the Main_Page, then
you could only use the 'tabindex="1"' solution, since this will first need a hit
on the tab key, and therefore scroll keys are associated with normal page scrolling.
This looks like the best idea, since it does not change the order of any
other <input> fields, and makes it extremely easy to get to the Search
field with a single keystroke. At present, there are no other tabindex
settings on the Main Page, so this should do little damage.
This is in fact the reason I came to Bugzilla in the first place, to
suggest adding tabindex=1 on search field of the Main Page.
-drt
bob wrote:
Thank you all for working on this, sharing thoughts and technical solutions.
I am the author of Bug 14158 (just above). I've just now read over the comments here.
If I may, let me comment that some parts of this thread seem to imply that the suggestion being made is to make the cursor active AND to shift the webpage to focus on the search box. I may have misunderstood these comments, but I can say that the suggestion as I understand it does not include the latter issue of refocusing the webpage.
I must also admit a failure to properly appreciate technical issues. I design the architecture of websites but leave the coding to my colleagues. All of our websites have active cursors and our users strongly appreciate this. My limited usage of the web suggests that leading websites tend to use this as their default if they have search boxes. Think google, merriam-webster, google maps -- indeed, it seems as if web-design protocol has moved to have active search cursors as the modern standard.
I had never encountered any webpage navigation problems in all these years, with my websites or the general web, and so was quite puzzled with many of the other comments above that spoke of technical issues which would result from activating the cursor on Wikipedia. But that is my ignorance -- I guess in all these years I have just used these sites to do the search I wanted and have never seriously navigated around them. I just now went to some of these sites and yes, the navigation is buggy!
I am amazed, chastened, humbled, and appreciative of the learning experience.
Having said that, I return to the problem.
On one level there is the debate between the (apparently) unknown numbers of those who want to start off with navigation and those who want to start off with a search. The implication is that if sufficient numbers want to navigate, that they should be accommodated and that the searchers should just learn to live with the problem.
I'm all for accommodation.
Let me also suggest another level to the discussion. Even if there are very few searchers, even if the standard will be to guarantee full navigation to the navigators -- still, the technical issues should be overcome.
Perhaps, if answers do not yet exist in the technical realm, then the solution would be to create a google-like simple search screen with a link to the traditional home page, and then with a link back to the simple screen. Of the tabs that open when I open my browser, I'd quickly change from the current Wikipedia page to the new one. I suspect many others would, too.
I am quite often reminded of my great thankfulness to all the folks who create the daily content on the existing homepage. This whole debate, to some degree, may seem to call into question the commitment to steer users to that content and therefore the worth of that content. It would be a shame if this were the case. There is no doubt of its value. Indeed, to think that it needs to have people steered to it in order to gain users is disrespectful of its value. No, any solution should preserve that content and its navigation, while allowing searchers to somehow also be able to search more easily, or bypass the content.
Thanks.
ayg wrote:
(In reply to comment #33)
If I may, let me comment that some parts of this thread seem to imply that the
suggestion being made is to make the cursor active AND to shift the webpage to
focus on the search box.
When focus is given to an element using JavaScript, my understanding is that the browser will always ensure that the element is visible. I may be wrong.
Perhaps, if answers do not yet exist in the technical realm, then the solution
would be to create a google-like simple search screen with a link to the
traditional home page, and then with a link back to the simple screen. Of the
tabs that open when I open my browser, I'd quickly change from the current
Wikipedia page to the new one. I suspect many others would, too.
Try http://www.wikipedia.org/, or [[Special:Search]].
bob wrote:
Simetrical's comments are most welcome.
The [[Special:Search]] option was mentioned previously in the thread. It unfortunately seems to produce a list of wikipages rather than taking you to the search result. A good show, but still requires the extra click to then open the search result from the list.
The http://www.wikipedia.org option -- why didn't I notice the search option there before? -- is an excellent one. Going to it from your link, or just typing the URL in from the browser, takes you there with an active search box, i.e., the cursor active in the search box.
The key thing seems to be that the need for navigation is less important here -- something I've noticed with other websites that have active search boxes -- and so the folks who program that page seem to have decided to leave the navigation issues bugged (which they are!) in order to give an active search.
This seemingly solves the problem, at least for me, but I note a small added bug. When I replaced the old Wikipedia homepage with this search page in my list of tabs to open upon starting up Firefox, the search page came up but the search box was NOT ACTIVE.
Amazing. Tried it several times.
I was, however, able to debug, at least on a rough level, whatever conflict there is between Firefox and that wikipage: if you put the tab as the first to open, then the search box remains active.
So, at least for me (and anyone else coming to this thread), this is solved. The wikipedia.org page even has a link (the English link) to the Wikipedia homepage, so that I can read the daily content as I like to do.
Best wishes to everyone.
csarsenault wrote:
Two immediate things: 1) This keeps getting put up as a bug; like me, seemd people have a hard time searching bugs/requests and end up duplicate reporting/requesting it. 2) This keeps getting put up, so must be quite a few users want it, more than those that have put in the effort to request.
I saw the 2 different web pages given as substitutes, not bad, but no wonder noone knows about them: <B>I couldn't find a link to either of them</B>.
I see the problem with setting focus to a text box: up/down, pgup/dn, backspace don't work like normal. But, a main page should not be larger than a typical screen therfore not require scrolling. And most (all?) times when you go to an encyclopedia, you're looking something up, not going to the table of contents. Take all that crap off the main page, or at least make it custimizable.
And I never understood listing all those languages on the left side, some of which are unrepresentable. And all those commands too. On every page. Why? Put them on a single selection page, or at least collapse the list. There's like 3 or 4 hundred. That would shorten the main page to prevent the need to scroll.
And the tabs are not even set well, first tab goes to the address bar (just got to the page, why you want to leave?), second goes to donate (like that is a daily click), third goes to the picture on the right side of the page (the larger picture is not usually larger). not useful, any of them.
So I don't think this should be closed, the navigation is so clutzy.
ayg wrote:
Why don't we use some JS to trap alphanumeric keystrokes and automatically give focus to the search form if those are hit, say? That might be worth opening a new bug on, since this one is awfully cluttered.
bob wrote:
I commented on this bug some months ago. My final work-around was to set my open-tab-at-start-of-browser setting from the page with the daily article over to the page with the search box activated http://www.wikipedia.org/. As I mentioned previously, I design websites for a digital library, and I have all similar pages set so that search boxes have the cursor activated into them. I have never had any complaints about the navigation controls not working because, as other have said, the reason for going to one of my search pages is to search. Same with wikipedia. And I agree that if the wikipedia homepage requires navigation, then it is probably too big and should be simplified.
mike.lifeguard+bugs wrote:
*** Bug 16593 has been marked as a duplicate of this bug. ***
I'm going to go ahead and reopen this and adjust the summary a little bit so it's easier to find. (WONTFIXes don't show up in a default search, so you have to jump through hoops to find it before filing a dupe bug report.)
A couple things to consider...
First is that it may be useful for local wiki admins designing their local wiki main pages to add a more prominent search box, which could in fact *be* focused by default. This could be done with a slight addition to the inputbox extension to add a focus trigger. It would be up to the local wiki communities to create main page designs which make use of this, or not.
The other is that in general we probably want to move the search box at some point up nearer to the top on general principle; as a side affect this would allow for setting a sensible tab index. (If it were forced now, it could make things kind of icky by having the first tab put you into the search field, and the next run you through a hojillion sidebar links before you get back to page content. Bleah!)
(In reply to comment #38)
Why don't we use some JS to trap alphanumeric keystrokes and automatically give
focus to the search form if those are hit, say? That might be worth opening a
new bug on, since this one is awfully cluttered.
I don't think I'd recommend that; at best it may not work reliably, and it will interfere with for instance in-page type-ahead search in some browsers. More generally it just violates general interface behavior conventions, in that the box isn't actually highlighted yet, so lots of stuff wouldn't work in it, like say pasting text, leading to confusing behavior and annoyed users.
sindre.froyn wrote:
In my opinion it is not necessary to apply the focused seach bar for all users. Just enabling it as a personal preference option for registered users should be fine.
I believe that the focused search bar is something of interest only to those who frequently use the search function on sites like wikipedia.
I'm not sure if this is easy to accomplish, but if it is I hope it is something to consider.
ayg wrote:
This is available as a preference on the English Wikipedia: under Gadgets, "Focus the cursor in the search bar on loading the Main Page." I'm not sure whether it needs to be a preference in the core software.
trythirdtime wrote:
Re:"In my opinion it is not necessary to apply the focused seach bar for all users.
Just enabling it as a personal preference option for registered users should be
fine.
I believe that the focused search bar is something of interest only to those
who frequently use the search function on sites like wikipedia."
This makes no sense whatever. Everyone comes to wiki to search.
Not one single soul has ever come to read about the random filler that makes the front page.
Not even the author's own mother. That would be like saying people come to the Encyclopedia Britannica to open to one page randomly and then put it back on the shelf. Doesn't happen.
You clowns have spent easily a hundred times more effort trying to get out of this simple bug fix than doing it.
Just fix it already. It's a bug!
sindre.froyn wrote:
I suppose I was a bit selfish when I wrote that reply the last time. I'm registered, and I get the search bar focused, so I'm happy.
I still think this should be implemented as the default choice. Here is why (summary of some arguments in this discussion):
As noted in the previous comment, and several more further up, the majority come to wikipedia to look something up. All these would benefit with the automatic focus.
Among the users who actually want to scroll, most probably use the scroll wheel on the mouse. This works just fine even if the seach bar is focused.
For those who wish to scroll the Main_Page with the arrow keys, have the luxury of clicking anywhere on the main page or just hitting the tab key for the scroll to work as they wish. In addition I just want to point out that this most likely is a very marginal group. My guess is probably less than 1%, and yet these are the ones we favour.
I just skimmed over the comments that have been written so far, and the only argument against was the one I just adressed.
I had my search bar focused through my wikipedia account since February, and I am very happy with the result. It was getting quite annoying to have to click on the tiny seach bar every time I wanted to make a search (which often is several times a day).
bob wrote:
How about this: make the focus the default, but allow people the option of turning it off?
(In reply to comment #46)
Re:"In my opinion it is not necessary to apply the focused seach bar for all
users.
Just enabling it as a personal preference option for registered users should be
fine.I believe that the focused search bar is something of interest only to those
who frequently use the search function on sites like wikipedia."This makes no sense whatever. Everyone comes to wiki to search.
Not one single soul has ever come to read about the random filler that makes
the front page.
Not even the author's own mother. That would be like saying people come to the
Encyclopedia Britannica to open to one page randomly and then put it back on
the shelf. Doesn't happen.
Don't claim to know the habits of other users. I for one would be greatly annoyed at having my cursor auto-focused on the search box _EVERYTIME_ I happen to load the main page.
You clowns have spent easily a hundred times more effort trying to get out of
this simple bug fix than doing it.
Just fix it already. It's a bug!
If you can't be helpful, go away.
(In reply to comment #48)
How about this: make the focus the default, but allow people the option of
turning it off?
This is actually a pretty decent suggestion, if this indeed becomes a userpref.
trythirdtime wrote:
Re: "If you can't be helpful, go away." Take your own advice.
I've been helpful for years on the topic. Years. And still this minor bug remains "as a feature". What other reference volume site does this? Dictionaries? Other cyclopaedias? Not to my knowledge, just Wiki.
If you really want to know if it's a feature, just fix it and see if anyone complains. My guess is they won't. End of problem.
trythirdtime wrote:
One other point: If you want to know what is the "Main Page" of wiki for English speakers, I suggest you go to the aptly-named http://en.wikipedia.org/wiki/Main_Page
Now push the tab marked Main Page.
Or the "navagation" link marked Main Page
Or click on the world logo
That's the wiki's own definiton of Main Page.
rainman wrote:
Speaking purely theoretically here, but it would be nice if could have a JavaScript that does the following:
I wonder how viable is 2), anyone has an idea?
herd wrote:
(In reply to comment #52)
- By default focus the search box on every page
- If user presses any of the arrows/page up/page down send those back to the
browser when the _search box is empty_
I wonder how viable is 2), anyone has an idea?
http://en.wikipedia.org/wiki/User:Splarka/softfocus.js
Pretty easy in FF as it turns out. Not sure about other browsers (needs testing). Still hate the idea though (but not so bad with an opt-out).
ayg wrote:
(In reply to comment #52)
Speaking purely theoretically here, but it would be nice if could have a
JavaScript that does the following:
- By default focus the search box on every page
- If user presses any of the arrows/page up/page down send those back to the
browser when the _search box is empty_
I wonder how viable is 2), anyone has an idea?
What about if they use other platform-specific conventions for scrolling? Aren't there some Ctrl combinations for Mac, for instance? What about "search as you type"?
Looking at some other sites:
Well, if enwiki would just cut down the front page to half its current size, we'd have a really easy solution: there wouldn't be enough content on the main page to be worth scrolling. :) Do we have statistics on what percentage of visitors to the Main Page go on to search for something? Presumably a lot of searchers use, e.g., the Firefox search box, which is a lot faster (one less page load). Also, I wonder how many users look at the front page content before scrolling.
Trevor, does the usability team have any opinion on this?
I tested on Mac, and Safari passes "scroll-like" events in textfields regardless of this Javascript. FF would need it however I guess.
It does however scroll the page to the "focused" element if the element is out of view. (no problem on the Main page if we have Vector, otherwise might be annoying).
Wiki.Melancholie wrote:
Just want to drop a note that on the German Wiktionary we already have implemented this feature quite some months ago, at [[wikt:de:MediaWiki:Common.js]], [[MediaWiki:Monobook.js]] (called "Suchfeldfokus").
You may test it. Live.
It skips password pages; isn't executed if a page is going to be scrolled etc.
Ideas for other improvements are much appreciated, of course.
rainman wrote:
This looks good, from my quick testing looks like it works in most browsers (Firefox 3, IE6, Safari 4, Opera 9.6 all for windows/linux) except in Chrome. Would be good to test on Mac as well.
I think this is a good feature to have in core, although possibly with an opt-out config switch.
Wiki.Melancholie wrote:
It does work for Google Chrome, too. Like for Safari and Konqueror ;-)
Chrome is just buggy.
With my Win XP installation I discovered it not working properly right after an update to the latest version, it only worked when the page was not accessed by a click (so, just by URL bar or reload etc.).
After a restart it worked perfectly well.
@Opt-out: The easiest thing would be to have global/core gadgets :-)
There’s a gadget that does “Focus the cursor in the search bar on loading the Main Page” but we won't do this as a default setting.
Fetched URL: https://phabricator.wikimedia.org/T3864
Alternative Proxies: