I have the feeling your changes are only gradually taking effect on test.wikipedia.org. When I wrote my previous e-mail about this, I still saw yellow on the discussion pages, and only the line separating the top bar was thinner (not the one for the left bar). Now, with both lines thin, I have to admit I like it even less :(

Erik Moeller wrote:

Timwi-

...

However, I object to your changes to the standard skin.

Well, the whole point is optimizing the defaults, not giving users yet another choice for what are miniscule variations

I know. But I don't see your current changes as optimisations. Sorry. Maybe I'm just short-sighted (no pun intended).

...

I liked the thick borders because they showed very clearly where the actual article is. (I have slightly bad vision.)

That should be easier now because the navigational elements use a different font size from the main article.

I'm not seeing this change, so I'll look back at it tomorrow, but I don't think this will convince me. It still won't be as clear a separation as thicker borders were.

...

I also think the article heading is too small now.

I think that's just an initial impression because the original headings were quite huge.

Well, actually the previous heading appeared bolder to me than the current one does. However, this is due to the particular font I've set in my browser (Verdana) and its habit of suddenly getting quite a bit fatter from one point size to the next. I understand most people use Times New Roman instead. However, if it doesn't upset too many people, if you could change it just slightly from 125% to 130%? Just to achieve this little effect for Verdana users like me?... That would be great :-)

In reality, I only changed each heading size to the next smaller level.

Unfortunately, the H6 heading is now smaller than the normal text. I'm not sure it's really supposed to be. But since H6 doesn't occur too often, I don't really care about this. The new dotted line, which I really like by the way, shows clearly enough that it is a heading.

...

I don't like the border around the footer

I'm not completely happy with it either. I had problems getting the same box around the top table, because that table is much more complex. I'll fiddle some more with it and if I can't make it work I'll remove the box.

Actually, I don't think I'd like two of those boxes better than one ;-)

...

because the previous way was cleaner and more consistent with the look of the rest (the top for instance). I don't like the light-blue colour of the bottom box because it looks bad in contrast to the yellow background of discussion pages.

There is no yellow background of discussion pages ;-).

Yeah, sorry. At the time I still had the yellow backgrounds. I see the new colour now, and to be honest, it's too light for me to distinguish directly from the pure white of real articles (I'm on an LCD). You'd therefore have to make it darker, and to satisfy Daniel Mayer you'd also have to change it back to a yellowish hue, so maybe in the end you'll just end up with the same original colour again. :)

The fact that the strong contrast between yellow and white makes it hard to come up with a global color scheme for things like TOC, boxes etc. is one of the reasons to change it.

What about the simple grey meta uses? But then again, it'd be indistinguishable from meta.

Maybe the actual page text should always be on a white background to avoid colour scheme problems, and only the top and left bars should have a different background to distinguish article pages from other pages. Or a differently-colours thick border around the page text ;-)

Greetings, Timwi

Erik Moeller wrote:

...

I'm not seeing this change, so I'll look back at it tomorrow, but I don't think this will convince me.

Sorry, but you're simply a minority. There's only so much that can be reasonably done to meet your concerns. Putting annoying fat borders on every page is IMHO not an option.

Who else in this thread was voting against the fat borders? I can't recall anyone ever saying they definitely want them gone, or for what reasons. Them being "ugly" is certainly not a reason, or at least not as good a reason as clear separation of the content from the navigational links is.

Timwi

Oliver-

1. Linking with the use of anchors is a Bad Thing, as previously

discussed,

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.

2. The size of the article titles was fine as it was,

Several people complained about it, and I agree with them. 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.

3. There seem to be 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.

5. I don't get the point of the "Post a comment" feature. It seems an

unnecessary complication, providing no more functionality than normal editing.

It appends text directly to the page instead of requiring you to load and save the whole page, which can be very large.

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. Also, newbies often are confused by the concept of editing a page to comment it, and they will likely expect such a link. 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.

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.

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.

Regards,

Erik

Andre-

I don't want Wikipedia to look ugly

I disagree that it's ugly.

Regards,

Erik

Oliver-

The lines intefere with tables, anyway. See:

Alright, that's a killer argument against them. Gone are the lines. I also tested in Konqueror and noted that the "dotted" CSS instruction looks quite ugly in that browser, so perhpas we saw different things. Maybe we can just agree to phase out unnecessary formatting -- lots of articles use bold for headlines, <font...> for table headers etc. This confuses the "edit section" feature, which (correctly) is not triggered on these instructions.

...

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

Not easy enough. A couple of days ago someone edited their *own* user talk page to comment on a completely unrelated article. I asked them what page they were referring to, and they *emailed* me in response -- the idea of article/talk page separation is simply too complex to grasp immediately for many people. The idea of editing a page to write a comment is even more complex and deviates from standard commenting procedures on other websites.

Not everyone *wants* to contribute, some people just want to provide feedback. That's what "Post a comment" is for -- an easy to understand, immediately usable link that allows people to quickly post their thoughts on an article without learning everything about wikis. From understanding that, however, it's a small step to understanding whole-page-editing, because it happens through essentially the same interface. That way people can learn to *gradually* become wiki contributors, instead of being thrown into the cold water. But "Post a comment" is useful even for long-time contributors because it saves time and energy. I personally saw two long pages today where I would have commented if the feature had already been available, but did not because I did not want to bother to load and go through the whole large talk page.

Where were you anyway in the large discussion about whether we should switch the entire discussion system to a BBS? I almost single-handedly defended the wiki way in that discussion. If I hadn't done so, someone might have set up a BBS already by now. One argument for not using a BBS was that we could simplify talk pages by making them more like common threaded discussions. If people like you oppose such a change, I might as well join the ranks of BBS supporters and rally behind those who want to dump talk pages altogether.

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.

That's silly, because the people who would benefit from the feature could not help in the archiving process anyway -- they could not edit the page at all! At least now they can say "Post a comment"->"Someone needs to archive this talk page. I can't edit the whole page anymore." Furthermore, if eventually it becomes reasonably possible to participate in 100K discussions because the interface allows it (by editing sections, replying to individual comments and appending new comments at the bottom), what exactly is the problem? We're not Microsoft -- we don't need to hardcode the 32K limit.

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...

So lang as we don't end up with dumb automatic archives like [[/Archive 1]], that's fine with me. However, it astonishes me that someone who whines^Wcomplains^Wtalks as much about "simplicity" would propose a feature that would substantially complicate the editing process.

I really don't think that making the Wikipedia more complicated, as many of your innovations seem to do,

You are completely mistaken in your belief that wiki-editing discussions is "simple". It's complex and needs to be made easier, if we want to keep this method of discussing at all. Wading through 20 comments in a small edit window just to find the one you want to reply to is not simple, it is time-consuming. Having to deal with "edit conflicts" because someone commented at the same time is incredibly annoying and confusing, and who knows how many comments were discarded because of it. (We can gradually fix this by eliminating edit conflicts when people are editing different sections, and eliminating them altogether for append edits.) And not being able to just start a new discussion without having to load discussions that may have happened months earlier into the edit box is quite braindead.

Alongside the wiki world, powerful and easy to use discussion systems have emerged. They are used daily by thousands and thousands of average, clueless Windows users. Sit one of them in front of a wiki discussion and they will look at you with glassy eyes and ask you where the "Post comment" or "Reply to this" links are, and how to produce an animated smiley with a beer keg. We won't give them the animated smileys, but we should give them a navigational structure that is reasonably similar to the systems they are familiar with. We should learn from other projects, exactly *because* we should make things as simple as possible.

Regards,

Erik

Oliver-

Okay, I hadn't taken into account the fact that people might overlook or fail to understand the "Discuss this page" link.

The problem is that this page does not actually take you anywhere obvious. Even if you find the link, you may be perplexed as to what to do next.

Well, that's why I suggested a feature for making archiving easier. It's an alternative way of solving the same problem, but the end result is that the page is shorter, rather than longer. I think that would be preferable.

How short can you get? We don't want to have just one thread per page. 30K seems like a reasonable length to me even for people with slow modems. Even at that length, however, the current system is inconvenient to use because you have to load the entire discussion into an edit window. That simply makes no sense.

Well, people might find it annoying to have to wait for a 100K page to load up, and then scroll through it to find the section they want to contribute to.

True, so you would have a new upper bound at which you would want to archive the page. But pushing the limit upwards is not necessarily a bad thing.

Oh, I know, we could just have an "Archive this section" link. When you click on it, ping! the whole section in [[Talk:Joe Bloggs]] headed "Joe Bloggs and New Imperialism" is replaced by the line, "Discussion moved to [[Talk:Joe Bloggs/Joe Bloggs and New Imperialism]]", and that new page is created at the same time.

Yes, I thought of that. The only problem is that it would be virtually impossible to move only the history of that specific section (edits don't have a section flag, some edits concern several sections etc.), so you would end up with the equivalent of copy & pasting the section without the history. Not good. The only way to preserve the page history is to move the page and then replace the resulting redirect with the new talk page. Then you can at least do

[[/Archive Dec. 2002 - June 2003]] contents: * Should Lir be banned? * Should Lir be re-banned? * Should Lir be unbanned? * Should Lir be renamed?

This kind of archive could be automatically generated from the section headings.

Oh all right, you've convinced me.

Yay!

But I'm not convinced that a feature to add new sections should be one of those reforms.

Grr...

Most additions to talk pages will be to ongoing discussions anyway, so the feature would rarely need to be used. Before you decided to remove all criticism of your feature from [[m:Layout vote]], Bdesham suggested that it would encourage people to ignore threading, which sounds a good argument to me.

Newbies will certainly use it this way -- they will click "Post a comment" and refer to a comment somewhere else in the discussion at the bottom of the page. Just like they do now: Newbies don't know how to change the indendation level, where to insert comments etc. But the problem will be more visible, because people who previously did not figure out how to comment will now do so. Instead of blaming the fact that newbies behave this way on the new feature, blame it on the real cause: It's damn difficult to properly post a reply. It tookm -me- a while to figure it out, and I consider myself an advanced user. And I -still- find it annoying to set the indentation level for each frelling paragraph that I type.

"Post a comment" is really only part of a larger puzzle. "Edit section" is part of the same puzzle and also makes discussions a lot easier. However, that's primarily intended for articles; what we really need is a "Reply" function to complement the "Post a comment" function. This is tricky to implement, because you need to auto-render the reply links somehow (my idea is to use the sigs as markers, but these are sometimes also used in a non-comment context). At that point we can also auto-sign comments that are entered using either feature, so we won't have to teach newbies the meaning of the four tildes anymore. This, however, will only be possible if we retain the "Post a comment" functionality, because that is one of the two ways to participate in a discussion -- reply in an existing thread or start a new one.

So it is really part of a larger scheme which I am working on, and any arguments you will come up with will be outweighed by far by the benefits of an overhauled discussion system. In any case, I would much appreciate a general attitude of "Interesting idea - let's see how this works" over "Terrible idea - let's vote on taking out this feature right now." Furthermore, I have always been a proponent of voting, but only within a proper process -- voting should be used when there has been a reasonable discussion period and a search for compromise, when most arguments have been presented and no consensus could have been reached.

The silliness of the whole thing is quite obvious from the fact that several of the voting options are not even relevant anymore -- the box is gone, the underlining is gone, the background is changed -- so what's the point of voting? Mav made a suggestion, I agreed to it, we try the new variant, talk about it, see if everyone can live with that, set it up, exchange arguments etc. Discussions should not be endless, but they should also not be cut short by an immediate call to the polling box. That's just frustrating for everyone involved and will not produce good results, because we need to listen to each other before we can really make a decision based on more than just gut feelings.

Regards,

Erik

Neil Harris wrote:

At the moment, only PHP coders can re-design skins. This is bad, since good coding skills and good design skills are not strongly correlated. With all the effort being devoted to tweaking the current layout, and arguing about it, we could instead be doing two things:

• decoupling code from content by using text-only template files

instead of PHP code to control the final assembly of page content

• decoupling content from graphical presentation by using CSS more

thoroughly

Great idea........

This then turns making new skins into something that can be done by regular logged-in users with only graphic design / Web skills, without any security or performance implications. By allowing them to edit their own template and CSS files _on the Wiki itself_, we can enable them to show off their skin designs to other users.

Up to this point! Do you know how many times I reload a design in Mozilla, Netscape, Ie and Opera? Ever 30 seconds or so. There is no way I could work on designs within the wiki system. It would simply take too long.

We can then hold a beauty contest without elaborate votes... by doing, rather than by talking.

Talking is better. A beauty contest .... we'd get "The header of design A is nice" "The footer of design B is nice". If we *talk* we can set out design goals and clear ways to implement them.

This would also make designing a new layout much more interesting as a general design competition for graphic designers. The fly in the ointment is backwards compatibility to ancient and brain-dead browsers such as IE 3.0 and Netscape 4.7. What we need for these is a special backwards-compatibility skin, just for these, and some server-side browser sniffing to deliver this skin instead of the normal default skin for these broken browsers.

Nice idea. Is it feasible?