Last modified: 2010-05-15 16:03:35 UTC
For AJAX search with $wgEnableMWSuggest, the width of the autosuggest box is hard-coded to be the same as the search box:
c.style.width = s.offsetWidth+"px";
Please let this width be a system-configurable or user-configurable parameter. If a wiki has many long article titles, this limits the usefulness of the AJAX search.
This would look pretty sloppy. Do note that when the cursor is over a title, the full title shows in a tooltip box already.
Hmmm... I don't think it looks sloppy (we're using a larger width and 280 people are happy), and the functionality is greatly improved. Imagine looking at these dropdown results:
They're useless until you expand the width.
Mousing over each one isn't a solution -- it takes tons of time. The wider dropdown lets the user visually see the right link in one second. Widening the dropdown instantly increased productivity and user happiness at my company.
How many identical prefixes are there? And how is this happening all the time?
In a corporate wiki, it's common for many articles to begin with the same few words, say, the name of a department or a process:
Software development standards
Software development best practices
Software development workstation setup
Software development environment
Software development migration
Software development department
Software development deliverables for September 2008
Our corporate wiki has 12,000 titles and this kind of repetition happens all the time. Heck, try typing "Software develop" on en.wikipedia and you get the same result (10 lines that say "Software devel").
The first day I enabled mwsuggest functionality on our wiki, 10 users asked if I could increase the width.
Having it widen dynamically to fit the titles displayed (perhaps with a maximum width) would be fine if having it configurable by the user is a concern.
(In reply to comment #3)
> How many identical prefixes are there? And how is this happening all the time?
My first attempt at finding an example to show you:
These results are 100% useless; tooltips provide a workaround, but using it 100% of the time on results such as these is unacceptable.
If this is a problem, it really shouldn't need a config var. The JS should deal with this on it's own.
I think this is a problem worth fixing. It would be nice to have adaptable width, and possibly some resizing-animation for eye candy so the user knows the variable width is not a bug. I've made an attempt in r40507.
All config vars are js variable, so they go to MediaWiki:Common.js. One might for instance want to override os_animation_steps=1 to kill all animation effects, or os_container_max_width to change max relative width.
We made the list width customizable on commons a couple of weeks ago.
Dynamic resizing to adapt to the contents is a tad more work though.