On 22 Jul 2003, Erik Moeller wrote:
Actually, the result of the discussion on wikitech-l is that we would keep the option enabled (as it was always been; the anchors have just not been generated and had to for the TOC) and to set the rules for when to use anchors as policies.
Okay, thanks for telling me. (I don't read wikitech-l.) I was referring to messages on wikipedia-l, such as this one by me:
http://mail.wikipedia.org/pipermail/wikipedia-l/2003-May/010411.html
and this one by Kurt Jansson:
http://mail.wikipedia.org/pipermail/wikipedia-l/2003-May/010418.html
So if we're going to set a policy, I think the best policy would be not to use such links in articles, apart from in the tables of contents.
Headlines are not supposed to dominate the entire page, they are supposed to give the viewer a quick overview of the different sections. The important thing is not to use the same font size/style for totally different things.
I agree, but I don't think the headings do dominate the page as they are.
About the faint horizontal rules below the headings:
Wikipedia allows users to insert other types of large font text into pages besides headings, such as <font..> formatted text, CSS formatted text etc. These lines help to distinguish between the two, which is important for seeing why certain lines don't show up in the TOC, for knowing which sections can be edited with the new right click feature etc. Of all the ways to separate headlines from other large font text I've tried, I like this one the best. Feel free to make alternative suggestions.
Using font size alone to distinguish headings from ordinary text is pretty common elsewhere, so I think the onus should be on the person proposing something extra to demonstrate a need for that something extra. Just because Wikipedia *allows* users to insert other types of large font text into pages besides headings, it doesn't mean that they should. They might do so to demonstrate font sizes in an article about font sizes, for example, but illustrative examples should be clearly marked as such, so that no-one is confused. If an article uses large font sizes but doesn't make it clear what those large font sizes are being used for, then that is a problem with the article, and the article needs to be made clearer. I don't see the need for a technical solution to this.
The lines intefere with tables, anyway. See:
http://test.wikipedia.org/wiki/Be
I haven't checked how they interact with pictures, but I imagine it wouldn't look nice.
About the "Post a comment" feature:
It appends text directly to the page instead of requiring you to load and save the whole page, which can be very large.
Okay, so it makes appending comments slightly quicker, but is it worth the extra hassle of having a new (and not very wiki-like) feature to learn?
Because only your comment appears in the preview, the preview is much faster and it is easier to see the effect of formatting, links etc. because you don't have to scroll to your comment every time you preview it. Having users not always unnecessarily load and save text that they don't need anyway should also help server performance.
Okay, this is true...
Also, newbies often are confused by the concept of editing a page to comment it, and they will likely expect such a link.
I strongly disagree with this. The wiki way of editing pages is quite easy to learn, and obviously *needs* to be learnt by anyone wishing to contribute! At the moment this is pretty much consistent over the whole Wikipedia, with the exceptions of protected pages and special pages, which aren't editable by new people at all. Adding the rule that *some* pages are editable in two different ways will just confuse people. If they have two links that both change the page, they won't know which to pick, and what the difference is. It's simpler to have the same rules for article pages as for talk pages, because then once you know the rules for one, you know the rules for the other. We should aim for simplicity if we want to attract people to the project.
Furthermore, as you know, some browsers have problems editing large pages; this feature allows users of such browsers to post comments without loading the content of the entire page into the edit window. This is also convenient for normal users.
I was thinking of bringing this up myself, but not as a point in your favour! Making it more convenient to add content to pages over 32 KB in size is not a good thing. It would just make the problem worse. Adding a feature to partially automate the archiving process would be good, though. Perhaps when editing a large page, the software could pick out sections (in the same way that the "Table of contents" feature does) and ask if you want to archive them before adding new content. Just a thought...
This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a "Reply to this" link after each comment.
I really don't think that making the Wikipedia more complicated, as many of your innovations seem to do, is the right way to go. Simplicity is good.
As for the headings, we should make it a convention that each discussion thread should have a heading, as this makes it much easier to participate in discussions using the "Edit section" feature, providing many of the same above advantages.
This sounds like a good idea. It would also make it easier to partially automate the archiving process, which might be nice.
Oliver
+-------------------------------------------+ | Oliver Pereira | | Dept. of Electronics and Computer Science | | University of Southampton | | omp199@ecs.soton.ac.uk | +-------------------------------------------+