On 2/9/07, Bill Konrad bkonrad123@sbcglobal.net wrote:
I'm not sure I see the advantages here. Sure it is kind of cool in a bit of a geeky way, but you still have to click a link to see the disambiguation
It's not geeky, it's good UI design, which MediaWiki kind of lacks. My internet connection is fairly slow, and it takes seconds to load a new page. Being able to avoid that would be great.
And it would appear to make both adding the disambiguation note at the top of pages and possibly
Not true - I've made an otheruses4-expand template which is a drop-in replacement for otheruses4.
the actual structure of the disambiguation pages more complex and fraught with potential for error.
Yeah, that's true. The major issues identified so far are: - not allowing section headings to be transcluded - not allowing the {{disambig}} (and related) templates to be transcluded
There may be others. I notice that some disambig pages have wiktionary links, but they can probably safely stay.
Until the method is relatively idiot-proof [1], and there are clear advantages beyond a little bit of "gee whiz, ain't that neat", I'm skeptical.
I think what we've got so far is "relatively idiot-proof". At worst, the drop-down box may be a bit ungainly. If an idiot did something really bad like putting <noinclude> around the whole page or something, then the worst possibly result is that the end user sees nothing drop down - and they're in the same situation as now.
Advantages: - Saving a couple of seconds every time a user needs to pass through a disambiguation page. - Requiring one less page load in that scenario. The basic workflow would go from three page loads (searching for their term which loads the "wrong page", clicking the disambig page link which loads the disambig page, clicking a link which loads the "right page") to two (loading the wrong page, loading the right page).
What are the disadvantages?
Steve