[Wikipedia-l] New stuff on test.wiki

[Oliver Pereira]

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 at ecs.soton.ac.uk                    |
+-------------------------------------------+