Hi all, I wanted to try and implement this myself, but haven't found the time. So here's my amazing idea:
At the top of a page with a disambig link, you get some text like:
''For other uses, see [[He Said, She Said (disambiguation).]]''.
I think it would be possible, and very desirable, to make that expandable with some javascript:
''For other uses, see [[He Said, She Said (disambiguation).]]'' [show].
Clicking [show] would replace the template by the actual contents of the disambiguation page:
-- He Said, She Said may refer to:
* He Said She Said (song), a single by Ashley Tisdale. * He Said, She Said, a 1991 romantic comedy starring Kevin Bacon and Elizabeth Perkins. * He Said, She Said (game show), an American game show hosted by former baseball great Joe Garagiola.
For the general concept of differing unsubstantiated accounts of an event, see logical argument. -- (and the rest of the page [[He Said, She Said]] would appear here).
Since ambiguous titles are so common now with nearly 2 million articles, navigating to the correct article is taking longer and longer. I think this would speed that process up. Any takers?
Steve
Steve Bennett wrote:
Since ambiguous titles are so common now with nearly 2 million articles, navigating to the correct article is taking longer and longer. I think this would speed that process up. Any takers?
I've never pursued it because it's so unpopular a thought, but I've always felt that the main page of a word should always be the disambiguation page. This is mighty close to it, and yet handles the best of both worlds.
I like it.
-Jeff
On 2/7/07, Jeff Raymond jeff.raymond@internationalhouseofbacon.com wrote:
Steve Bennett wrote:
Since ambiguous titles are so common now with nearly 2 million articles, navigating to the correct article is taking longer and longer. I think this would speed that process up. Any takers?
I've never pursued it because it's so unpopular a thought, but I've always felt that the main page of a word should always be the disambiguation page. This is mighty close to it, and yet handles the best of both worlds.
I like it.
I sometimes feel like Jeff does, sometimes feel very different...which probably makes me pretty close standard policy, although I often find myself wondering...shouldn't [[He said, She said]] be the dab page? Then I realise it isn't worth a fight, and move on.
I really like Steve's idea, but will it cause browser issues?
On 2/8/07, Guettarda guettarda@gmail.com wrote:
I really like Steve's idea, but will it cause browser issues?
We already use this concept on a number of navigational templates, such as as [[Template:Capital cities of the European Union]]. It should be possible to make the template degrade nicely if JavaScript is not switched on.
There seems to be some documentation on how this works here: http://en.wikipedia.org/wiki/Wikipedia:NavFrame#Collapsible_tables
I don't know what happens if JavaScript is off, but what we would probably like is to see just the normal disambig text, without the transcluded page. As long as that happens, the user is no worse off without javascript than they are now.
Steve
Ok, I did a proof of concept:
http://en.wikipedia.org/wiki/User:Stevage/Disambig
Obviously it has graphical issues, but technically it seems pretty simple.
Steve
On 2/8/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/8/07, Guettarda guettarda@gmail.com wrote:
I really like Steve's idea, but will it cause browser issues?
We already use this concept on a number of navigational templates, such as as [[Template:Capital cities of the European Union]]. It should be possible to make the template degrade nicely if JavaScript is not switched on.
There seems to be some documentation on how this works here: http://en.wikipedia.org/wiki/Wikipedia:NavFrame#Collapsible_tables
I don't know what happens if JavaScript is off, but what we would probably like is to see just the normal disambig text, without the transcluded page. As long as that happens, the user is no worse off without javascript than they are now.
Steve
Steve Bennett wrote:
Ok, I did a proof of concept:
http://en.wikipedia.org/wiki/User:Stevage/Disambig
Obviously it has graphical issues, but technically it seems pretty simple.
Steve
On 2/8/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/8/07, Guettarda guettarda@gmail.com wrote:
I really like Steve's idea, but will it cause browser issues?
We already use this concept on a number of navigational templates, such as as [[Template:Capital cities of the European Union]]. It should be possible to make the template degrade nicely if JavaScript is not switched on.
There seems to be some documentation on how this works here: http://en.wikipedia.org/wiki/Wikipedia:NavFrame#Collapsible_tables
I don't know what happens if JavaScript is off, but what we would probably like is to see just the normal disambig text, without the transcluded page. As long as that happens, the user is no worse off without javascript than they are now.
When JavaScript is off, you get both the normal disambig text and the transcluded disambig page, without the hide/show "link". (Tested using Firefox 2.0) I'd think that just the disambig text is what we'd like.
It would also be good, I think, to default to not showing the transcluded disambig page...currently it defaults to showing it.
Also, it would be good if the disambig footer were hidden when showing the transcluded disambig page.
By the way, this is a truly brilliant idea!
-Rich
On 2/8/07, Rich Holton richholton@gmail.com wrote:
When JavaScript is off, you get both the normal disambig text and the transcluded disambig page, without the hide/show "link". (Tested using Firefox 2.0) I'd think that just the disambig text is what we'd like.
Yep.
It would also be good, I think, to default to not showing the transcluded disambig page...currently it defaults to showing it.
Yep.
Also, it would be good if the disambig footer were hidden when showing the transcluded disambig page.
Yep.
Totally agree on all three points. The third is likely to be the hardest. I don't think it can currently be done without actually editing all the disambig pages and replacing {{dab}} with <noinclude>{{dab}}</noinclude>.
It may be possible to do it with some CSS magic, like putting a class on the {{dab}} template, and somehow making that class invisible when it gets transcluded.
I suggest that if there is consensus to actually start doing this, that we introduce it slowly, page by page, adjusting the corresponding disambig pages so they transclude nicely. If that proves to be popular, then presumably the MoS will be updated to make a requirement for disambig pages that they transclude nicely.
Though I'm dubious whether a page like [[Victoria]] would ever come out well. Maybe we can get scrollbars in there?
Steve
On 2/8/07, Steve Bennett stevagewp@gmail.com wrote:
When JavaScript is off, you get both the normal disambig text and the transcluded disambig page, without the hide/show "link". (Tested using Firefox 2.0) I'd think that just the disambig text is what we'd like.
Yep.
This is probably going to require some custom coding - the existing templates all work on the assumption that you want the text to appear if JavaScript is unavailable.
It would also be good, I think, to default to not showing the transcluded disambig page...currently it defaults to showing it.
Yep.
Turns out to be not too hard. I've now got three methods for doing the showy/hidey thing (one donated by someone else). The third one, using the {{hidden}} template is IMHO the prettiest and least intrusive.
Steve
On 2/8/07, Steve Bennett stevagewp@gmail.com wrote:
This is probably going to require some custom coding - the existing templates all work on the assumption that you want the text to appear if JavaScript is unavailable.
Hey, it turns out the Hidden template degrades the way we want: if JavaScript is off, you just get the disambig line, no transclusion. Brilliant!
So this wikicode is basically perfect by itself: {{Hidden|1={{otheruses|He Said, She Said (disambiguation)}}|2={{:He Said, She Said (disambiguation)}}|ta1=left|fw1=normal}}
The only problem left is the undesirable extra {{dab}} link showing up. But we can solve that on a page-by-page basis to begin with.
Steve
Steve Bennett wrote:
... It may be possible to do it with some CSS magic, like putting a class on the {{dab}} template, and somehow making that class invisible when it gets transcluded. ...
Which won't work on browsers that don't support CSS. I believe the best way to do this would be to load the diambiguation page using [[Ajax (programming)|Ajax]]. This should degrade nicely on browsers without JS/CSS.
--Ruud
On 2/8/07, Ruud Koot r.koot@students.uu.nl wrote:
Which won't work on browsers that don't support CSS. I believe the best way to do this would be to load the diambiguation page using [[Ajax (programming)|Ajax]]. This should degrade nicely on browsers without JS/CSS.
The whole scheme[1] is totally dependent on css anyway. If we get as far as having a box that can be expanded and that transcludes another page, CSS and javascript is a given.
How would an Ajax implementation work? Would the MediaWiki code need to be modified?
Incidentally, I've made an expanding version of the "otheruses-4" template: [[User:Stevage/Otheruses4-expand]] There's an example of its use here: http://en.wikipedia.org/wiki/User:Stevage/Disambig2
Steve [1] That is, using the 'hidden' template.
Steve Bennett wrote:
On 2/8/07, Ruud Koot r.koot@students.uu.nl wrote:
Which won't work on browsers that don't support CSS. I believe the best way to do this would be to load the diambiguation page using [[Ajax (programming)|Ajax]]. This should degrade nicely on browsers without JS/CSS.
The whole scheme[1] is totally dependent on css anyway. If we get as far as having a box that can be expanded and that transcludes another page, CSS and javascript is a given.
How would an Ajax implementation work? Would the MediaWiki code need to be modified?
Incidentally, I've made an expanding version of the "otheruses-4" template: [[User:Stevage/Otheruses4-expand]] There's an example of its use here: http://en.wikipedia.org/wiki/User:Stevage/Disambig2
Steve [1] That is, using the 'hidden' template.
Steve,
What you've done is great. However, I did discover an issue (you may already be aware of this)...If the transcluded disambig page has sections, then those sections show up in the TOC of the transcluding page.
No obvious solution comes to mind, short of eliminating sections from disambig pages.
-Rich
On 2/8/07, Rich Holton richholton@gmail.com wrote:
Steve,
What you've done is great. However, I did discover an issue (you may already be aware of this)...If the transcluded disambig page has sections, then those sections show up in the TOC of the transcluding page.
No obvious solution comes to mind, short of eliminating sections from disambig pages.
-Rich
That is a problem with using only wikicode. I'd suggest instead using an ajaxy (not really, but kinda) solution where a javascript loads the HTML from the target page and displays it in the box (I'm thinking of the popups addon, it does that, right?) That would ensure that the headings doesn't appear in the article, since it is added after the page has been rendered by mediawiki.
Also, it would hide the code from non-javascript capable browsers.
--Oskar
On 2/9/07, Oskar Sigvardsson oskarsigvardsson@gmail.com wrote:
That is a problem with using only wikicode. I'd suggest instead using an ajaxy (not really, but kinda) solution where a javascript loads the HTML from the target page and displays it in the box (I'm thinking of the popups addon, it does that, right?) That would ensure that the headings doesn't appear in the article, since it is added after the page has been rendered by mediawiki.
Yeah, I was originally thinking of that kind of solution, like with GreaseMonkey or something. But then transclusion is so easy :)
Presumably this could be done by inserting code into common.js?
Would you want to load the disambig page when the main page loads, or only when the user clicks "show"? In the first case, you're loading two pages every time you load one page (much more work than transcluding). In the second, you lose some of the time saving that we're trying to gain with this whole scheme.
Steve
On 2/9/07, Steve Bennett stevagewp@gmail.com wrote:
Yeah, I was originally thinking of that kind of solution, like with GreaseMonkey or something. But then transclusion is so easy :)
Presumably this could be done by inserting code into common.js?
Yes
Would you want to load the disambig page when the main page loads, or only when the user clicks "show"? In the first case, you're loading two pages every time you load one page (much more work than transcluding). In the second, you lose some of the time saving that we're trying to gain with this whole scheme.
My suggestion would be to load the page every time as soon as the user come to the article. The user would not notice this because it loads after the page is rendered in their browser. There would be a slight performance tax, but it is nothing the user would notice and nothing the servers couldn't handle. Well, I shouldn't put words in the developers mouths, but that's what I imagine. I think that would be the best solution.
--Oskar
On 2/9/07, Oskar Sigvardsson oskarsigvardsson@gmail.com wrote:
My suggestion would be to load the page every time as soon as the user come to the article. The user would not notice this because it loads after the page is rendered in their browser. There would be a slight performance tax, but it is nothing the user would notice and nothing the servers couldn't handle. Well, I shouldn't put words in the developers mouths, but that's what I imagine. I think that would be the best solution.
It would also solve another problem I just noticed: interwiki links.
Would anyone care to sketch out a pure javascript based proof of concept?
Steve
On 2/9/07, Rich Holton richholton@gmail.com wrote:
What you've done is great. However, I did discover an issue (you may already be aware of this)...If the transcluded disambig page has sections, then those sections show up in the TOC of the transcluding page.
No obvious solution comes to mind, short of eliminating sections from disambig pages.
I think it's fairly clear that we could not immediately take every disambig page and just declare it suitable for transclusion at the top of the relevant pages. Most will need minor reformatting, even if it's just sticking <noinclude> around certain bits of text like section headings and what-not.
As a slightly separate issue, more advanced transclusion methods would certainly be beneficial, and I did raise a bugzilla bug over this once. The ability to transclude text without categories was a key issue, and references was another issue. To solve the disambig-template issue, perhaps we would need to be able to mark a template as only being transcludable for N levels (disambig page can transclude {{disambig}}, but another page that transcludes the disambig page doesn't transclude it), but that sounds really complicated and confusing.
Steve
"Steve Bennett" wrote:
On 2/9/07, Rich Holton richholton@gmail.com wrote:
What you've done is great. However, I did discover an issue (you may already be aware of this)...If the transcluded disambig page has sections, then those sections show up in the TOC of the transcluding page.
No obvious solution comes to mind, short of eliminating sections from disambig pages.
I think it's fairly clear that we could not immediately take every disambig page and just declare it suitable for transclusion at the top of the relevant pages. Most will need minor reformatting, even if it's just sticking <noinclude> around certain bits of text like section headings and what-not.
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 information. Is it a significant advantage to have it show up as a drop-down thingie rather than as a separate page? I don't see it. And it would appear to make both adding the disambiguation note at the top of pages and possibly the actual structure of the disambiguation pages more complex and fraught with potential for error.
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.
[1] I realize that since *anyone* can edit wikipedia, idiot-proof is at best a sliding scale
bkonrad
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