Erik Moeller wrote:

I can live with an override function. I am strongly opposed to making authors have to insert a TOC tag manually into articles. For the time being, howeevr, I would like to see examples where the TOC is inappropriate before I implement the override, to avoid having unnecessary added complexity.

I think part of the problem I've been having with coming up with examples where a TOC is inappropriate/needed is that it is currently only implemented on the test Wikipedia, and I don't really spend much time just "browsing" the test server. I believe that when the TOC feature is on the live server, then cases where it needs to be overridden will become apparent. Then again, perhaps not.

Cheers!

- David [User: Nohat]

When can we hope that the new feature will be implemented on Wiktionary? Structure is a lot more important there than on Wikipedia.

Ec

Erik Moeller wrote:

Ray-

...

When can we hope that the new feature will be implemented on Wiktionary? Structure is a lot more important there than on Wikipedia.

There are still a couple of bugs to fix and some adjustments to be made before the remaining wikis are upgraded. For Wiktionary, it would be interesting to have a minimum article length before the TOC is triggered, since Wiktionary entries often have a lot of headings while being relatively short (making the TOC mostly pointless).

Yes, that's a point to consider. I just looked, and out of 4343 articles the 434th has only 1449 bytes. Many of the bigger ones are indexes and other kinds of lists that really serve a meta-dictionary function. The minimum number of headings parameter will also be available as in Wikipedia. Is the TOC function flexible enough to make these kinds of parameters so that they can be set in user preferences. Whatever a user chooses, since the TOC function operates only on the currently called article it will not significantly affect operation time.

Ec

James D. Forrester wrote at last:

On the semi-related note of inter-article sub-linking ([[a#x]]) as opposed to intra-article sub-linking ([[#x]]), I also think that having support for this (the former) is a Bad Thing(tm); given that we are so set against it being used, adding the deprecated functionality to the system is (highly) illogical, IMO.

I'm also unhappy with the prospect of inter-article sub-linking; but in fairness, I must remind you that we get this automatically. No coder is going out of their way to enable this; rather, we're asking them to go out of their way to disable it.

-- Toby

Cunc-

It simply should be a user-pref option, turned off by default.

It *is* a user preference, and it should be enabled by default, because it is a navigational tool that is especially useful for readers who will never create an account.

Regards,

Erik

Cunc-

It should be turned off by default, because it is awkward and interferes with the flow of the entries

It is only displayed in articles with more than three headings.

--moreover, it is not editable by Wikipedians.

Nor is a lot of other stuff displayed on every Wikipedia page.

Regards,

Erik

Cunc-

What of that is in the "article" space? None.

Actually, the subpage backlinks are a good comparison. They are also displayed by default, in roughly the same location, and a navigational structure that is not directly editable. And they're not a user preference.

Regards,

Erik

The-

On 7/4/03 6:35 PM, "Erik Moeller" erik_moeller@gmx.de wrote:

...

Cunc-

...

What of that is in the "article" space? None.

Actually, the subpage backlinks are a good comparison. They are also displayed by default, in roughly the same location, and a navigational structure that is not directly editable. And they're not a user preference.

And are there subpage backlinks in the Wikipedia article space? No.

Define "Wikipedia article space". They are right below the subtitle, where the TOC was initially placed. Sure, we have subpages disabled for the main namespace, but that is for an entirely different reason, and irrelevant to your argument, which is bogus anyway, since there is no "sacred article space" which must not be violated.

Regards,

Erik

The Cunctator wrote: [in objection to table of contents display]

The content of the Wikipedia pages below the title and above the links at the bottom has always been entirely user-configurable. To change that summarily is not something to be taken lightly.

An admirable sentiment, perhaps, but it doesn't make sense here.

1) The TOC is created only by the addition of headings to an article by human hands. (Even Ram-bot articles are based on a template written by a human!) If the TOC is unmanageable, it's because a human has gone mad with the headings, and any human can fix it by refactoring the page.

2) An article long enough for multiple headings to be appropriate would benefit from a table of contents in usability improvements. While some people may well like to read every article from beginning to end, many people are actually searching for specific information, and would be better able to find it in long articles by getting an overview of section headings.

Vision-impaired users using text-to-speech software, with less ability to scroll-n-skim, should certainly benefit from the up-front TOC and ability to jump directly to relevent sections of the text. (Some browsers support jumping directly from heading to heading, but I gather not all. I'd appreciate if any accessibility experts lurking around might be able to shine more light on this.)

3) Anyone mortally offended by it can disable it in their preferences.

Separately, the present implementation does look dreadful in my opinion. It takes up too much space and is rather distracting, and I'm offended by the markup used to render it. ;) However this is an implementation detail, and does not discredit the concept.

Thoughts:

* It would be fairly trivial to add a JavaScript goodie to hide the table of contents with a click in most modern browsers. Where JavaScript is disabled or unavailable, or for the wackos running Netscape 4 or something ;) well, they'll just have to log in won't they?

* It would be less trivial, but not impossible, to have some support for display preferences stored in a browser-local cookie instead of a logged-in user account. I don't know if this is desirable or not.

-- brion vibber (brion @ pobox.com)

The Cunctator wrote in part:

The content of the Wikipedia pages below the title and above the links at the bottom has always been entirely user-configurable. To change that summarily is not something to be taken lightly.

Persumably you meant Wikipedia /articles/ here, not Wikipedia /pages/, since you already pointed out that Erik's example of subpage backlinks applies only outside the article namespace -- but it does apply to some pages.

-- Toby