The following features are currently tested on http://test.wikipedia.org :
* Automatic table of contents. A TOC-table is added to pages that contain more than three headings. This table links to the individual sections within the article and hopefully makes navigation easier. * Editing of individual sections. You need to be logged in to test this. Just click the "[edit]" link next to a headline to change the text of that particular section. * Linking into the Special: namespace with parameters. See Brion's separate mail for details.
Please help us test these features before we put them on the live server, otherwise, things might break unexpectably.
Thanks,
Erik
I could find the following problems:
- Automatic table of contents. A TOC-table is added to pages that contain more than three headings. This table links to the individual sections within the article and hopefully makes navigation easier.
The TOC is invalid HTML for two major reasons: * The top-level LI elements are not enclosed in an UL or OL * The child ULs are outside the parent LIs.
- Editing of individual sections. You need to be logged in to test this. Just click the "[edit]" link next to a headline to change the text of that particular section.
The [edit] link does not display when you're logged out, but when you log in it is set as a default. This is potentially confusing to users. Settings should not change by creating an account :-)
- Linking into the Special: namespace with parameters. See Brion's separate mail for details.
Seems to work great! :-)
Greetings, Timwi
On Wed, 2 Jul 2003, Timwi wrote:
The TOC is invalid HTML for two major reasons:
- The top-level LI elements are not enclosed in an UL or OL
- The child ULs are outside the parent LIs.
It's also mysteriously in a table and there are no line breaks. :)
I notice that duplicate headings (which is not unlikely to occur with subheadings) are marked with a numbered suffix after the first one. Better than nothing, but this is fragile for linking; if the major sections are rearranged in order, the numbers for the minor sections will change.
The [edit] link does not display when you're logged out, but when you log in it is set as a default. This is potentially confusing to users. Settings should not change by creating an account :-)
Indeed. If we're adding features to make it easier to edit, I'm not sure it makes sense to hide them from new users...
Another minor suggestion I made to Erik earlier but which would apparently be "hard" with his regexps :) would be to have the section editing separate on horizontal rules as well as headings. This would be particularly helpful in talk pages and the Village Pump, where common practice is to separate subdiscussions with rules, not headings.
- Linking into the Special: namespace with parameters. See Brion's separate mail for details.
Seems to work great! :-)
Woo-hoo!
-- brion vibber (brion @ pobox.com)
Brion-
It's also mysteriously in a table and there are no line breaks. :)
I think it looks nicer in a table, but that's easy to change in Skin.php.
I notice that duplicate headings (which is not unlikely to occur with subheadings) are marked with a numbered suffix after the first one. Better than nothing, but this is fragile for linking; if the major sections are rearranged in order, the numbers for the minor sections will change.
So what else do you suggest?
Indeed. If we're adding features to make it easier to edit, I'm not sure it makes sense to hide them from new users...
My reasoning for this was that Wikipedia has two uses: - a work of reference - a collaborative editing system used by us.
We need to find the right balance between making editing easy and making reading Wikipedia unobtrusive. Some work on this is being done in the Skin department, for example, where we will probably end up with a Skin preferred by editors, and one that is more friendly to non-editing users.
On the other hand, I do (of course) believe that the section editing feature is very useful, and can save us substantial bandwidth, so that every signed in user should get it by default. Perhaps a better long term solution is to show users the preferences screen when they sign in for the first time.
Another minor suggestion I made to Erik earlier but which would apparently be "hard" with his regexps :) would be to have the section editing separate on horizontal rules as well as headings.
While this would complicate matters indeed, it is not the only reason I oppose it. One problem is that on many pages we have both section headings and horizontal rules used to separate different parts of the article, i.e.
== foo ==
bar
-----
== baz ==
bam
-----
So you would end up with duplicate links (or if you eliminate the dupes, you surprise the user by not showing them the edit link). Moreover, it is unclear what an edit link next to the ruler would refer to; the part above or below the ruler? You would have to place the link above or below, which would look ugly.
But the most important reason not to do this is that horizontal rules are evil. Not only are they ugly, they provide no information whatsoever about the sections that follow or precede them. That's what section headers are for: to separate different parts of a page. When the different parts of a page are so separate that a new section would not be enough, they should be moved to separate pages.
By having the neat "edit this section" feature only for headings, we encourage people to create headings for their own editing benefit. They will reorganize talk pages to have them to be able to respond quicker in the future. We provide no such incentive if we also implement the feature for rules.
Regards,
Erik
On Wed, 2 Jul 2003, Erik Moeller wrote:
Brion-
It's also mysteriously in a table and there are no line breaks. :)
I think it looks nicer in a table, but that's easy to change in Skin.php.
The table doesn't do anything a styled div wouldn't do. It's not tabular, it's a list with a caption. :)
I notice that duplicate headings (which is not unlikely to occur with subheadings) are marked with a numbered suffix after the first one. Better than nothing, but this is fragile for linking; if the major sections are rearranged in order, the numbers for the minor sections will change.
So what else do you suggest?
One possibility would be to append the name of the upper header(s) to the lower header:
== Culture == === Blecchistan === === Miscania === == Language === Blecchistan ===
... <a name="Culture/Blecchistan">... <a name="Language/Blecchistan">... ...
These would remain consistent if the order of Culture and Language are changed, or if another named section with a 3-rd level Blecchistan header is added before or between them.
We need to find the right balance between making editing easy and making reading Wikipedia unobtrusive. Some work on this is being done in the Skin department, for example, where we will probably end up with a Skin preferred by editors, and one that is more friendly to non-editing users.
Suppose the edit links are small, unobtrusive, and by default are faded (so seemingly partially transparent on the solid background) until a mouseover darkens them up to full visibility?
Just thoughts.
Perhaps a better long term solution is to show users the preferences screen when they sign in for the first time.
That's a good idea in any case.
[snip]
By having the neat "edit this section" feature only for headings, we encourage people to create headings for their own editing benefit. They will reorganize talk pages to have them to be able to respond quicker in the future. We provide no such incentive if we also implement the feature for rules.
Hmm...
Debatable, but I'll let it slide for now. :)
-- brion vibber (brion @ pobox.com)
Brion-
I think it looks nicer in a table, but that's easy to change in Skin.php.
The table doesn't do anything a styled div wouldn't do. It's not tabular, it's a list with a caption. :)
Tables are predictable and dependable. CSS often isn't. ;-) But it's probably safe to use it by now.
So what else do you suggest?
One possibility would be to append the name of the upper header(s) to the lower header:
== Culture == === Blecchistan === === Miscania === == Language === Blecchistan ===
.... <a name="Culture/Blecchistan">... <a name="Language/Blecchistan">... ....
These would remain consistent if the order of Culture and Language are changed, or if another named section with a 3-rd level Blecchistan header is added before or between them.
But not if the hierarchy is changed, and we would still have to retain the numbering feature for H2 dupes. Also, these anchor names could get very long, especially for H4 anchors.
Suppose the edit links are small, unobtrusive,
I've tried to make them small and unobtrusive, any further suggestions in that area?
and by default are faded (so seemingly partially transparent on the solid background) until a mouseover darkens them up to full visibility?
Hm, can you demonstrate that?
Regards,
Erik
On 7/2/03 2:56 PM, "Erik Moeller" erik_moeller@gmx.de wrote:
Brion-
It's also mysteriously in a table and there are no line breaks. :)
I think it looks nicer in a table, but that's easy to change in Skin.php.
I notice that duplicate headings (which is not unlikely to occur with subheadings) are marked with a numbered suffix after the first one. Better than nothing, but this is fragile for linking; if the major sections are rearranged in order, the numbers for the minor sections will change.
So what else do you suggest?
Indeed. If we're adding features to make it easier to edit, I'm not sure it makes sense to hide them from new users...
My reasoning for this was that Wikipedia has two uses:
- a work of reference
- a collaborative editing system used by us.
We need to find the right balance between making editing easy and making reading Wikipedia unobtrusive. Some work on this is being done in the Skin department, for example, where we will probably end up with a Skin preferred by editors, and one that is more friendly to non-editing users.
This would be a terrible violation of the basic Wiki-nature of Wikipedia.
The Cunctator wrote:
We need to find the right balance between making editing easy and making reading Wikipedia unobtrusive. Some work on this is being done in the Skin department, for example, where we will probably end up with a Skin preferred by editors, and one that is more friendly to non-editing users.
This would be a terrible violation of the basic Wiki-nature of Wikipedia.
I'm not sure it's as dramatic as all that. As long as readers can jump right in and start editing, there's no un-wiki-ness. Possibly the default behavior could be that you're in read mode (which looks the way it looks now) until you edit, and then some rearrangements are made to suit the fact that you're editing.
I'm not sure what's right exactly, but I think that thinking in terms of 'editing skins' and 'reading skins' isn't a terrible violation of wikiness.
The Cunctator wrote:
Erik Moeller wrote:
We need to find the right balance between making editing easy and making reading Wikipedia unobtrusive. Some work on this is being done in the Skin department, for example, where we will probably end up with a Skin preferred by editors, and one that is more friendly to non-editing users.
This would be a terrible violation of the basic Wiki-nature of Wikipedia.
I don't see a problem with having skins optimised for reading and editing. I do see a probelm with making the former the default, although even that doesn't seem to me to be isurmountable. What /would/ be a terrible violation is the make the default skin a skin in which there is no "'''Edit this page'''" link at all -- but I don't think that Erik is proposing that for /any/ skin.
-- Toby
Erik Moeller wrote in part:
Brion VIBBER wrote:
It's also mysteriously in a table and there are no line breaks. :)
I think it looks nicer in a table, but that's easy to change in Skin.php.
Some of the reasons why using tables for layout is bad can be found on [[meta:Wikipedia accessibility]] (and pages and sites linked from it).
I notice that duplicate headings (which is not unlikely to occur with subheadings) are marked with a numbered suffix after the first one. Better than nothing, but this is fragile for linking; if the major sections are rearranged in order, the numbers for the minor sections will change.
So what else do you suggest?
The natural thing for me would be [[X#Y#Z#...]]. If this gets too long ... well, that's a pretty good sign that [[X#Y]] really should go onto its own page!
By having the neat "edit this section" feature only for headings, we encourage people to create headings for their own editing benefit. They will reorganize talk pages to have them to be able to respond quicker in the future. We provide no such incentive if we also implement the feature for rules.
I'll buy this.
-- Toby
On 02 Jul 2003 19:22:00 +0200, Erik Moeller erik_moeller@gmx.de gave utterance to the following:
The following features are currently tested on http://test.wikipedia.org :
- Automatic table of contents. A TOC-table is added to pages that contain
more than three headings. This table links to the individual sections within the article and hopefully makes navigation easier.
- Editing of individual sections. You need to be logged in to test this.
Just click the "[edit]" link next to a headline to change the text of that particular section.
I think it's highly confusing having the edit section link above and to the right of the section it refers to. Below and to the right would be the more natural position
Richard-
I think it's highly confusing having the edit section link above and to the right of the section it refers to. Below and to the right would be the more natural position
I would like to have it displayed *right-aligned* with the section heading, and that's how it looks in Mozilla. The HTML used is
<div style="float:right;margin-left:5px;">[edit link]<div> <h2><a name="Anchor name">Page title</a></h2>
Could this be improved somehow? Perhaps this is a case where a table should be used?
Regards,
Erik
On Wed, 2 Jul 2003, Erik Moeller wrote:
Richard-
I think it's highly confusing having the edit section link above and to the right of the section it refers to. Below and to the right would be the more natural position
I would like to have it displayed *right-aligned* with the section heading, and that's how it looks in Mozilla. The HTML used is
<div style="float:right;margin-left:5px;">[edit link]<div> <h2><a name="Anchor name">Page title</a></h2>
Could this be improved somehow? Perhaps this is a case where a table should be used?
death to tables, noooo!!!! :)
A minor problem here is that in a linear browser (text-only, speech, etc) or a browser with no CSS / CSS disabled, the 'edit' link will appear before the header.
A negative top margin on the float should be able to take care of that and let the float be logically placed after the header...
-- brion vibber (brion @ pobox.com)
On 02 Jul 2003 21:46:00 +0200, Erik Moeller erik_moeller@gmx.de gave utterance to the following:
Richard-
I think it's highly confusing having the edit section link above and to the right of the section it refers to. Below and to the right would be the more natural position
I would like to have it displayed *right-aligned* with the section heading, and that's how it looks in Mozilla. The HTML used is
<div style="float:right;margin-left:5px;">[edit link]<div> <h2><a name="Anchor name">Page title</a></h2>
I just checked in Moz 1.4a, IE6 and Opera 7 - the edit link is definitely higher than the header in all three - if I have the link right at the bottom of the screen, the Heading is off the bottom of the screen. This makes the link look as though it relates to the section above it. The following markup achieves what you were aiming for:
<div><small style="float:right;margin-left:5px;">[<a href="/w/wiki.phtml?title=This_one&action=edit&section=1" class='internal' title="This one">edit</a>]</small><H2 id="newcomers"> This is a very long heading that might clash with the float</H2></div>
i.e. transfer the float to the inline element small and make the heading a child of the div. Notice that I've also replaced the <a name> element with an id on the header, which is much more efficient and avoids problems with headers accidentally inheriting styling intended for links in some browsers.
More efficient still would be <div class="editheader"><small>[<a href="/w/wiki.phtml?title=This_one&action=edit&section=1" class='internal' title="This one">edit</a>]</small><H2 id="newcomers"> This is a very long heading that might clash with the float</H2></div>
and then you can define .editheader small {float:right; margin-left:5px;} and skins can do groovy things like .editheader {outline:1px solid #ccc;}
Richard (really looking forward to the day when users can specify their own stylesheets, stored locally)
On Thu, 03 Jul 2003 08:29:06 +1200, Richard Grevers lists@dramatic.co.nz gave utterance to the following:
On 02 Jul 2003 21:46:00 +0200, Erik Moeller erik_moeller@gmx.de gave utterance to the following:
Richard-
I think it's highly confusing having the edit section link above and to the right of the section it refers to. Below and to the right would be the more natural position
I would like to have it displayed *right-aligned* with the section heading, and that's how it looks in Mozilla. The HTML used is
<div style="float:right;margin-left:5px;">[edit link]<div> <h2><a name="Anchor name">Page title</a></h2>
I just checked in Moz 1.4a, IE6 and Opera 7 - the edit link is definitely higher than the header in all three - if I have the link right at the bottom of the screen, the Heading is off the bottom of the screen. This makes the link look as though it relates to the section above it. The following markup achieves what you were aiming for:
<div><small style="float:right;margin-left:5px;">[<a href="/w/wiki.phtml?title=This_one&action=edit&section=1" class='internal' title="This one">edit</a>]</small><H2 id="newcomers"> This is a very long heading that might clash with the float</H2></div>
i.e. transfer the float to the inline element small and make the heading a child of the div. Notice that I've also replaced the <a name> element with an id on the header, which is much more efficient and avoids problems with headers accidentally inheriting styling intended for links in some browsers.
More efficient still would be
<div class="editheader"><small>[<a href="/w/wiki.phtml?title=This_one&action=edit&section=1" class='internal' title="This one">edit</a>]</small><H2 id="newcomers"> This is a very long heading that might clash with the float</H2></div>
and then you can define .editheader small {float:right; margin-left:5px;} and skins can do groovy things like .editheader {outline:1px solid #ccc;}
Richard (really looking forward to the day when users can specify their own stylesheets, stored locally)
Following up to myself: I just discovered that if you add a border, the CSS margin-collapsing rules come into play and add default 1em top-margin to the H2. So in any skin where you wanted a border you would need to specify something like .editheader H2, .editheader H3, .editheader H4 {margin-top:0;} .editheader {border:1px solid #ccc; margin-top: 1em; padding: 2px 0.5em;}
Erik Moeller wrote:
The following features are currently tested on http://test.wikipedia.org :
- Automatic table of contents. A TOC-table is added to pages that contain
more than three headings. This table links to the individual sections within the article and hopefully makes navigation easier.
The TOC should be just above the first section heading. Otherwise the lead paragraph, the one that tells you what the article is actually about, can be pushed down so far it's completely off the initial screen, which is bad. As a reader, I'm only interested in the TOC when I've read the lead and decided that this article is the one I'm looking for; at that point my eyes will be at the end of the lead, and a TOC at that point helps me decide between reading the whole article or just jumping to a section of special interest.
It would be cool if sidebar vs main flow was a preference.
Stan
On Thu, 3 Jul 2003, Erik Moeller wrote:
Stan-
The TOC should be just above the first section heading.
You are absolutely right, I have changed the behavior accordingly (not on test.wiki yet). Looks very nice.
Updated test to cvs version... Definitely looks a bit cleaner now.
But...
Markup note:
<div style="margin-bottom:0px;"> <a CLASS="internal" HREF="#About_Wikipedia">1 About Wikipedia </a><br> </div>
Ewwwwwwww! :)
The great Tim Berners-Lee gave us ordered and unordered lists for a reason. A minimum of semantic markup allows for reasonable rendering on non-graphical browsers -- text, speech, PDAs, etc -- and for appropriate navigation techniques in non-mouse environments.
Now, if we really don't like the way the bullets/numbers are rendered in an unordered or ordered list, we can suppress or change that in the style sheet.
Just because you _can_ emulate the whole of HTML 4 with just <div> and <span> and liberal use of the style attribute hardcoded on every element doesn't mean you should. :)
-- brion vibber (brion @ pobox.com)>
On 02 Jul 2003 19:22:00 +0200, Erik Moeller erik_moeller@gmx.de gave utterance to the following:
The following features are currently tested on http://test.wikipedia.org :
- Automatic table of contents. A TOC-table is added to pages that contain
more than three headings. This table links to the individual sections within the article and hopefully makes navigation easier.
Not only is the markup of the TOC dreadfully invalid, it looks really weird seeing both bullets and numbers. How about omitting the numbers from the text and simply using ordered lists
<OL> <li>First section</li> <li>Second section <ol> <li>the second section has</li> <li>two subsections</li> </ol> </li> etc.
and set the list-types via the skin stylesheet: e.g. OL {list-style:upper-roman;} OL OL {list-style:decimal;} OL OL OL {list-style:lower-roman} This also leaves better scope for internationalization: list numberings include hebrew, katakana, georgian etc.
Richard-
Not only is the markup of the TOC dreadfully invalid,
Correct, that was the result of some code moving. I have fixed it, and while I was at it, I've removed the <UL>s entirely and replaced them with <DIV>s. (Not on test.wiki yet.)
it looks really weird seeing both bullets and numbers.
This should no longer happen. (Didn't happen in Mozilla anyway.)
How about omitting the numbers from the text and simply using ordered lists
We need the numbers because some people have auto-numbering turned on, and the TOC numbers should correspond to the auto-generated numbers within the headings.
Regards,
Erik
Erik Moeller wrote in part:
We need the numbers because some people have auto-numbering turned on, and the TOC numbers should correspond to the auto-generated numbers within the headings.
As a user of auto-numbered headers, I'd be quite happy with ordered lists inside ordered lists, like so:
<ol><li>Header A <ol><li>Subheader a</li> <li>Subheader b</li> </ol></li> <li>Header B</li> </ol>
which generally appears along the lines of:
1 Header A 1 Subheader a 2 Subheader b 2 Header B
That seems pretty clear to me.
-- Toby
Erik Moeller wrote:
The following features are currently tested on http://test.wikipedia.org :
- Automatic table of contents. A TOC-table is added to pages that contain
more than three headings. This table links to the individual sections within the article and hopefully makes navigation easier.
This should be a list, NOT a <table>
This copied from my post to wikitech-l:
The Table of Contents feature could potentially suffer from the following problems, as it is currently implemented:
1. An article with many short sections would inappropriately get a TOC that would waste space. 2. An article with just two very long sections wouldn't get a TOC but would be appreciably helped by one. 3. Sometimes a TOC would be best located not at the top of an article, but after a short introductory paragraph. I think some dead tree encyclopedias use this method. 4. If displaying TOCs is off by default, most users won't appreciate their utility, as most users won't change preferences. It seems a TOC is most useful to readers of an encyclopedia, and as many readers won't even be logged in, they won't see the potentially helpful TOCs.
I propose that whether and and where a TOC appears should be specified by each article using a wiki tag indicating where the TOC should appear. This would allow articles with many short sections to not have a TOC, long articles with just a few sections have a TOC, and allow article authors/editors to specify the best location for the TOC without relying upon the wiki software to presume the very top of an article is the best place.
I think keeping the option of having automatically-generated TOCs as a user preference is desirable, as at first, most articles won't have a TOC. Maybe they should be a different color, so editors can easily identify articles that would benefit from a TOC and insert the wiki tag for one, and perhaps identify articles that suffer from a TOC and insert a wiki tag to exclude one.
- David Friedland (Nohat)
David-
- An article with many short sections would inappropriately get a TOC
that would waste space.
Then remove some sections.
- An article with just two very long sections wouldn't get a TOC but
would be appreciably helped by one.
Then add some sections.
- Sometimes a TOC would be best located not at the top of an article,
but after a short introductory paragraph. I think some dead tree encyclopedias use this method.
That's the current behavior.
- If displaying TOCs is off by default,
It is enabled by default.
Regards,
Erik
Erik Moeller wrote:
- An article with many short sections would inappropriately get a TOC
that would waste space.
Then remove some sections.
A growing article with many stub sections should have those stubs removed then, so the TOC doesn't get in their way?
- An article with just two very long sections wouldn't get a TOC but
would be appreciably helped by one.
Then add some sections.
What if there is no good way to break up a few long sections into shorter ones? Should such an article be doomed to suffer without a TOC?
I surmise you supporting the notion that some wiki-algorithm is better at determining whether an article merits a TOC than each article's author. I disagree, as it seems that an aspect of articles that is so intimately married to the content as a TOC should be modifyable by editors and not arbitrarily imposed by the wiki software.
I agree than in an ideal Wikipedia, every article would have exactly the right number of sections of exactly the right length, and the TOC algorithm would word perfectly. But in the meantime, with a non-ideal Wikipedia, how can you defend the TOC feature's exacerbating the situation by disallowing TOCs where they might be useful and forcing them to be included where they are extraneous?
- David
David-
Then remove some sections.
A growing article with many stub sections should have those stubs removed then, so the TOC doesn't get in their way?
Stub sections are evil. They are a form of meta comment like "is this really true?" insertions in articles and should be avoided whenever possible. Wiki is a means to an end, not an end in itself -- Wikipedia is first and foremost an encyclopedia, not a scratchpad. If you want to talk about an article's potential future structure, use the talk page.
Articles should always be in a consistent state. Encarta or Britannica have many stubs, but they don't have "stub sections". In any case, I fail to see how the TOC can get in the way if there is no content it can get in the way of.
Then add some sections.
What if there is no good way to break up a few long sections into shorter ones?
Show me such a case and I will show you how it could be broken up. In any case, a TOC of 2 or 3 sections would only look out of place, and be of little help in navigating the article.
I agree than in an ideal Wikipedia, every article would have exactly the right number of sections of exactly the right length, and the TOC algorithm would word perfectly. But in the meantime, with a non-ideal Wikipedia, how can you defend the TOC feature's exacerbating the situation
Articles that have improper sections will be fixed sooner as the problems become more apparent. For example, I already noticed several articles that use colons in the headings. This looks very ugly, and the TOC makes it easy to detect such stylistic errors. Then, with the section editing enabled, you just select the heading, edit it, and save in a matter of a few seconds (OK, saving usually takes a while because of terrible code in that area).
Hiding our problems, on the other hand, will not make them go away. Those who are annoyed by the TOC can turn it off easily. But its current implementation should work well for articles that are reasonably structured.
Regards,
Erik
Erik Moeller wrote:
Articles should always be in a consistent state. Encarta or Britannica have many stubs, but they don't have "stub sections". In any case, I fail to see how the TOC can get in the way if there is no content it can get in the way of.
I think I was unclear about what I meant by stub sections. I meant only a section that has just one or two sentences. Some types of articles fit into a category and there is a standard set of sections for each article in that category, like elements or countries. When creating a new article for one of those categories, an author should copy the template for that type of article and try to fill in as much as much as possible. However, that person may not know much about some subsection, and so just puts in a sentence or two of overview of that topic. In the case of such an article, where a few of the sections are filled out, but most are just short one or two sentence 'stubs' a TOC would be in the way, as most of the headings would be visible within one or two screenfuls of the top.
What if there is no good way to break up a few long sections into shorter ones?
Show me such a case and I will show you how it could be broken up. In any case, a TOC of 2 or 3 sections would only look out of place, and be of little help in navigating the article.
If there is an article that has a long first section and a short section at the end, say an external links section, a TOC would be very valuable to someone looking for that information. You are probably right that the long first section should be broken up, but it is conceivable that there could be a long section that is best left intact, like a long quotation (say a poem) or a narrative. In fact, it seems that as articles become more in-depth articles, longer sections of prose that can't be easily broken up will become more common. It seems arbitrary to say "TOCs are only for articles with 4 or more headings."
Additionally, we don't want to encourage people to delete or add sections unnecessarily just to get a particular desired TOC behavior. I just can't believe that all articles with fewer than 4 sections should never have a TOC and all articles with 4 or more sections should always have a TOC. The world is not so easily quantized: there have to be exceptions on either side. Why not leave it up to individual articles' authors/editors?
I agree than in an ideal Wikipedia, every article would have exactly the right number of sections of exactly the right length, and the TOC algorithm would word perfectly. But in the meantime, with a non-ideal Wikipedia, how can you defend the TOC feature's exacerbating the situation
Articles that have improper sections will be fixed sooner as the problems become more apparent. For example, I already noticed several articles that use colons in the headings. This looks very ugly, and the TOC makes it easy to detect such stylistic errors. Then, with the section editing enabled, you just select the heading, edit it, and save in a matter of a few seconds (OK, saving usually takes a while because of terrible code in that area).
Hiding our problems, on the other hand, will not make them go away. Those who are annoyed by the TOC can turn it off easily. But its current implementation should work well for articles that are reasonably structured.
Regards,
Erik
I agree that putting the TOC before the first heading is good. That and having them on by default satisfy two of the concerns I had.
As for my proposal, perhaps indeed it is an unnecessary additional burden for every article of significant length to specify whether or not it should have a TOC, and where. I also think having a default of a TOC in articles with 4 or more headings and not for articles with fewer is, generally, an excellent default. I only think there should be some way to override the default, not necessarily for any reason we can think of now, but because there might be a reason we can't think of. I think it is much more in keeping with wiki to allow the default to be overridden than not. Perhaps when exceptions come up, a policy of when it should be overridden could be discussed and then agreed upon. I am very doubtful that most would agree upon a policy that was: if an article has more than 3 sections, it gets a TOC, otherwise not. No exceptions.
There are _always_ exceptions.
Cheers!
- David
David-
I think I was unclear about what I meant by stub sections. I meant only a section that has just one or two sentences. Some types of articles fit into a category and there is a standard set of sections for each article in that category, like elements or countries.
This is a fair point, but in these cases of templates I would prefer it if authors commented out individual section titles until there is enough text to fill them (<!--foo-->). Editors will still see them, but the TOC will no longer be triggered.
If there is an article that has a long first section and a short section at the end, say an external links section, a TOC would be very valuable to someone looking for that information. You are probably right that the long first section should be broken up, but it is conceivable that there could be a long section that is best left intact, like a long quotation (say a poem) or a narrative.
We usually do not like long quotations because we are not a source text repository. Even if we do have them, we should comment individual parts of the quotation, which again allows us to make a logical break. Can you explain what you mean with narrative? I would really like to see specific examples.
In fact, it seems that as articles become more in-depth articles, longer sections of prose that can't be easily broken up will become more common. It seems arbitrary to say "TOCs are only for articles with 4 or more headings."
Well, it is less arbitrary than it looks. E.g. Mary Evans writes in "Web Design: An Empiricist's Guide":
Regardless of structure most experts agree that users should not have to go through more than three jumps to find the information they need. They added that users will become frustrated if presented with more levels of pages acting as tables of contents rather than providing content.
Usually, menus should contain about eight items; that is the amount of information that most people can process relatively quickly. However, we cannot set such a high requirement, of course, because we have shorter articles which would nevertheless benefit from a TOC. But if we have only two or three items, we can have unforunate results:
For long articles, menu items will be too broad to accurately describe the content they describe. Users will find it difficult to use this navigational tool except for the most obvious sections (e.g. external links). Is the information about Albert Einstein I need in the "Life" or in the "Work" part? With so few sections, having no TOC at all would make more sense.
For short articles, users will be frustrated because they perceive the TOC as another navigation level, which may not have been necessary since the information they seek is readily available.
As a general principle, navigation aids should be added only when they are truly useful and can save user time; otherwise they can end up being only an annoyance. Making tables only visible at four items automates this to some extent, although user intelligence is still required to set up the sections properly.
Additionally, we don't want to encourage people to delete or add sections unnecessarily just to get a particular desired TOC behavior.
Absolutely, if the TOC behavior is wrong, it either needs to be corrected, or as you say, overridden. I'm open to both a "NOTOC" or "FORCETOC" option should that ever turn out to be an issue. I'm also focusing mostly on Wikipedia's and Wiktionary's use right now and not considering what other uses of our software might pop up.
Let's wait how this TOC experiment turns out and how user experiences are until drawing any further conclusions. My current belief is that the way the TOC is set up, it will encourage positive changes to the way articles are structured.
Regards,
Erik
03.07.2003 23:46:23, David Friedland david@nohat.net wrote:
I am very doubtful that most would agree upon a policy that was: if an article has more than 3 sections, it gets a TOC, otherwise not. No exceptions.
There are _always_ exceptions.
I know I'm new and all, and I probably don't have a lot of say in this, but I agree with David here. It seems arbitrary to define such a rule that cannot be overwritten by article authors. It would be more 'wiki' to create a small tag that can be inserted in an article to generate a TOC.
My 2¢, Timwi
Timwi-
I know I'm new and all, and I probably don't have a lot of say in this, but I agree with David here. It seems arbitrary to define such a rule that cannot be overwritten by article authors.
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.
Regards,
Erik
Timwi wrote at first:
I know I'm new and all, and I probably don't have a lot of say in this,
We try to not let seniority have a great influence here. See [[en:Wikipedia:Wikipedia:List of Wikipedians in order of arrival]] and the discussion surrounding that page. The main relevance (that I can think of) of your recent arrival is that it suggests possible unfamiliarity with Wikipedia's culture -- but that just means that we'll have to judge what you say on its merits!
-- Toby
Erik Moeller wrote in part:
Stub sections are evil. They are a form of meta comment like "is this really true?" insertions in articles and should be avoided whenever possible. Wiki is a means to an end, not an end in itself -- Wikipedia is first and foremost an encyclopedia, not a scratchpad. If you want to talk about an article's potential future structure, use the talk page.
One of the poorest developements that I've seen in Wikipedia over the course of the past year that I've spent here is that people are abandoning the notion that Wikipedia articles are, by their very nature, always and inherently works in progress. Comments hidden away on the talk page or inside the HTML code are useful to me only once I decide to work on it -- they do nothing to encourage me to start working in the first place.
-- Toby
Erik Moeller wrote:
A growing article with many stub sections should have those stubs removed then, so the TOC doesn't get in their way?
Stub sections are evil. They are a form of meta comment like "is this really true?" insertions in articles and should be avoided whenever possible. Wiki is a means to an end, not an end in itself -- Wikipedia is first and foremost an encyclopedia, not a scratchpad. If you want to talk about an article's potential future structure, use the talk page.
Articles should always be in a consistent state. Encarta or Britannica have many stubs, but they don't have "stub sections". In any case, I fail to see how the TOC can get in the way if there is no content it can get in the way of.
I was pleasantly surprised to return from vacation to see that a TOC system had sprung up out of nowhere. It looks great.
As for the stub, or at least the empty sections, could they not be made to appear in red? This behaviour would parallel the use of coulour in our links to other articles.
What if there is no good way to break up a few long sections into shorter ones?
Show me such a case and I will show you how it could be broken up. In any case, a TOC of 2 or 3 sections would only look out of place, and be of little help in navigating the article.
A long article that can't be sectioned is probably badly written with no sense of organization to the author's thoughts. After some copyediting the sectioning should fall into place naturally.
I agree than in an ideal Wikipedia, every article would have exactly the right number of sections of exactly the right length, and the TOC algorithm would word perfectly. But in the meantime, with a non-ideal Wikipedia, how can you defend the TOC feature's exacerbating the situation
Articles that have improper sections will be fixed sooner as the problems become more apparent. For example, I already noticed several articles that use colons in the headings. This looks very ugly, and the TOC makes it easy to detect such stylistic errors. Then, with the section editing enabled, you just select the heading, edit it, and save in a matter of a few seconds
Hiding our problems, on the other hand, will not make them go away. Those who are annoyed by the TOC can turn it off easily. But its current implementation should work well for articles that are reasonably structured.
I agree fully with Erik on this. One benefit may be to encourage the consolidation of overly fragmented subjects. Thus, for example, where there are now separate articles to list the contents of each of a band's albums it will be more convenient to have these together on a single page.
Ec
David Friedland wrote:
I propose that whether and and where a TOC appears should be specified by each article using a wiki tag indicating where the TOC should appear.
This seems like the obvious thing to do, and was suggested on one of these mailing lists before Erik's code was ever implemented on [[test:]]. The obvious code would be <TOC> (or <toc>, or either).
Despite David's arguments, I see one big problem with /requiring/ a <TOC> tag on any article with a TOC. The problem is that articles all start out without TOCs. My solution: Let Erik devise the best system that he can for estimating when an article needs a TOC and when it doesn't. (The current estimate is the number of headers; that's fine.) And let him estimate the best place (before the first header). Then run a conversion script to put "<TOC>" in all of those articles.
At this point, the situation is exactly what Erik would have it be always. Yet humans can now go through and make adjustments, if necessary.
-- Toby
Toby-
Despite David's arguments, I see one big problem with /requiring/ a <TOC> tag on any article with a TOC. The problem is that articles all start out without TOCs. My solution: Let Erik devise the best system that he can for estimating when an article needs a TOC and when it doesn't. (The current estimate is the number of headers; that's fine.) And let him estimate the best place (before the first header). Then run a conversion script to put "<TOC>" in all of those articles.
This isn't going to happen, but I might implement a <notoc> tag, which would pretty much have the same effect with far less trouble and clutter. For the time being, no convincing arguments have been made for either, though, and not a single real world example has been cited except for the Main Page, which is already auto-exceptioned. So I consider this a largely theoretical discussion.
Regards,
Erik
wikipedia-l@lists.wikimedia.org