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: I know. But I don't see your current changes as optimisations. Sorry. Maybe I'm just short-sighted (no pun intended). 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. 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 :-) 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. Actually, I don't think I'd like two of those boxes better than one ;-) 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. :) 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: 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- 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. 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. 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. 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 disagree that it's ugly. Regards, Erik

Oliver- 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. 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. 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. 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. 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- 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. 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. 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. 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. Yay! Grr... 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: Great idea........ 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. 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. Nice idea. Is it feasible?