Misplaced Pages

Revision as of 17:25, 30 June 2009

• Table of contents
• First discussion
• End of page
• New post

• WP:VPR
• WP:VP/PR
• WP:PROPS

• Check if your proposal is already taken care of at Perennial proposals.
• Proposed software changes should be filed at Bugzilla. Editors here can help you with this.
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed new wikis belong at m:Proposals for new projects.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Refining the administrator elections process Blocks for promotional activity outside of mainspace For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

Watched counter

A recent changes page for unwatched articles

Vandalism is a problem on all pages, but it is a much larger problem on pages that, on average, have fewer or zero people watching them. One solution to this problem is Wikipedia_talk:Special:UnwatchedPages, which was requested by Jimbo, is accessible only to admins, is updated infrequently, and is therefore very difficult to 'clean out'. Another solution, advocated here, is to modify the recent-changes table in MediaWiki to grab the watcher-count from the watchlist table. We would then be able to create a "recent changes in unwatched articles" page. This page would let editors catch vandalism that would usually have gone unnoticed for long periods of time. It would also encourage editors to expand their watch-lists, and urge editors to contribute to fringe/stub articles that are seeing some recent activity. It would also allow us to finally address one of the WP:PERENs. To get this proposal off the ground, we would need:

1. Interest from editors. Other potential benefits. Perhaps a straw-poll.
2. Critical comments, including reasons why this might not be as useful as stated.
3. Solid estimates of cost - can this be done without locking the site? How long would it be read-only for?
4. Input from a developer. Should one be contacted to check feasibility?

Comments addressing any of these four points are especially welcome. –M 19:38, 25 April 2009 (UTC)

Now this is an interesting, and probably feasible, idea. Technically, it could probably be done without a schema-change, and it could be useful to do so; the code in FlaggedRevs, for instance, uses the fact that it has to do a database lookup to be more clever in what it shows: it only 'counts' users who have logged in in the past 60 days, for instance, which is pretty neat. If the servers can take the strain, having that feature available on Recent Changes would be very useful, and avoids the issue of pages apparently being watched because they're on the watchlists of users who last logged in three years ago. Performance-wise, having a rc_watched column in the recentchanges table would massively reduce database load when viewing RecentChanges. Or we could define a few more types in the rc_type field (only ~3 actions defined out of a possible 16 million!), and avoid an explicit schema change, but the devs might find that a bit hackish (I remember there being hiccups over the RevDeleted bitfields). On the other hand, that field then has to be populated on every action.

Procedurally, it sounds like a godsend. Unwatched articles are only dangerous if they're edited; unwatched but untouched articles are no harm to anyone. Happy‑melon 14:39, 27 April 2009 (UTC)

I think 7 days would be the best last-login time, unless someone can give a better figure. Given the rate of revisions vs the rate of access, and the many other fields in recent changes, I don't think that this would do too much damage to performance. And the benefits, as you say, are a godsend. Should we get dev feedback, or try to get a few more comments? –M 02:36, 28 April 2009 (UTC)

I guess it should be the latter... –M 04:28, 5 May 2009 (UTC)

How might the column increase performance?   M  20:37, 13 May 2009 (UTC)

I have to agree that this is an interesting proposal. During my vandalism patrols i cross infrequently visited articles every now and then which blatant vandalism on them for periods up to (And in some cases over!) a year. While I encounter them irregularly it won't automatically mean there are not a lot of pages vandalised this way - they simply don't show up on anti-vandalism tools often. I also see possibilities for using this page for new page patrol as pages listed might very well be missed non notable or vandalism pages that slipped into forgetfullness.

On a more critical note: How would these articles be patrolled? I can imagine that this category will end up having at least 100.000 articles in them. Even if they are only infrequently edited it will still mean a lot of edits in a day - and how will double / triple / n* checks of the same page be prevented? Likewise, not every actively edited article has to be on a watchlist. Also, some active editors have massive watchlist from new page patrols (I had to remove 600 entries from three weeks patrolling). How can we prevent pages from going unnoticed due to unclean watchlists? Might it be better to filter on pages that have not been edited in say, two months? Excirial 19:51, 15 May 2009 (UTC)

Another way to look at it is as filtering out all 'watched' pages from recent changes - if someone's watching, you don't need to. So right away we're preventing many multi-checks. Overflowing watchlists are a problem, but this new page will catch further edits to infrequently-edited articles. So if you can't track every page on your watchlist, then you shouldn't, and now you wouldn't have to. The other problems you bring up - inevitable double checks, thousands of edits per day - are ones we already face. This proposal can't solve them, but it does reduce them.   M  22:13, 15 May 2009 (UTC)

You could just use variables, like

"Recent Changes on Village pump (proposals): Allstarecho, on 06/30/2009"

But it would be a good idea for rollback

Would there be some way of combining it with the recent "whitelist" list of autreviewers? That is, for there to be a list of recent changes to unwatched pages excluding those pages where the last change is by an autoreviewer? That way it would be easy to look for vandalism without checking pages where someone else has already reverted vandalism. That might well solve some of Excirial's concerns about multiple checks of the same recent edit. Grutness...wha? 02:09, 23 June 2009 (UTC)

Recent unwatched changes straw poll

The proposal is to create a recent changes page for unwatched articles to prevent vandalism by modifying the recent-changes table in MediaWiki. (I'd really prefer not to see this one archived, since it would open up several useful features. It would permit Watched counters. A now-ignored bugfix in the watchlist code and the addition of a 'checked' watchlist row would then let you patrol your own watchlist. Adding a public-watchlist preference would then give us a passive form of Flagged revisions.) Though this is a software feature request, support from editors would help.

• Support. –M 04:28, 5 May 2009 (UTC)
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232 18:34, 9 May 2009 (UTC)
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M 19:46, 10 May 2009 (UTC)
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 19:35, 10 May 2009 (UTC)
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M 19:46, 10 May 2009 (UTC)
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages   M  20:29, 13 May 2009 (UTC)
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)
• Support - Great idea. Kevin Baas 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\ 20:38, 13 May 2009 (UTC)
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists).   M  22:31, 13 May 2009 (UTC)
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC)
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only.    M   01:14, 6 June 2009 (UTC)
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance.    M   00:27, 11 June 2009 (UTC)
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature.    M   18:29, 16 June 2009 (UTC)
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases.    M   00:23, 22 June 2009 (UTC)
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort.    M   08:11, 26 June 2009 (UTC)
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)

The link for sections

Would it be possible to tweak this feature so that it always appears immediately at the end of a section header instead of on the right hand side of the page. Currently, the button has a nasty habit of appearing over text and I feel the suggested tweak would remove this problem. Mjroots (talk) 10:03, 24 May 2009 (UTC)

Agreed, and make it look like a proper button ->   M  19:54, 24 May 2009 (UTC)

Also agreed (to both suggestions). Some other language Wikipedias (French, German, Italian) have the link just after the section heading, where it is more visible than having it to the far right. On the far right, it often gets tangled up with images and other links; how many editors have clicked the wrong edit link when there is a cluster? -- John Broughton (♫♫) 20:53, 24 May 2009 (UTC)

An example in another[REDACTED] (de) is this page.   M  21:01, 24 May 2009 (UTC)

An interesting idea. Where is the code for that kept? Somewhere in MediaWiki: namespace? OrangeDog (talk • edits) 21:56, 24 May 2009 (UTC)

They move the link around with Javascript. Anomie⚔ 23:27, 24 May 2009 (UTC)

This has been a constant problem for those editing articles for New York City, especially pages and sections about demography and elections. You end up making lots of ugly white space, re-sizing images, or moving images around, just in order to keep "" in a useful, non-disruptive place without stacking. On the other hand, putting right after every heading and sub-heading can be jarring to the eye of ordinary, casual readers, just as too many in-line footnotes can be. —— Shakescene (talk) 23:37, 24 May 2009 (UTC)

Jarring as well they should be - footnotes, because people should get used to wanting to see sources, but the edit link especially, because we'd like more people to notice it, and edit the pages.   M  05:40, 25 May 2009 (UTC)

I notice it's less jarring (while still jarring enough) on that German page by virtue of a smaller font and a subscript effect (and this despite "Bearbeiten" having two-and-a-half times as many characters as "Edit"). PL290 (talk) 09:13, 25 May 2009 (UTC)

So, it looks like the general consensus so far is that this is a desirable feature. Let's hope it gets noticed and taken forward. Mjroots (talk) 15:47, 25 May 2009 (UTC)

I don't like this idea. It's in a standard place now, so you can just flick to the right hand side of the page, and that's where I'd keep looking if it were moved. As for the concerns about bunching and stacking of edit links where images are floated right, that's what {{Fixbunching}} is for. If it ain't broke, don't fix it. Dendodge _T\ 16:39, 25 May 2009 (UTC)

FixBunching is a very very poor workaround, and works only in limited conditions. If floating divs are placed in separate sections, or if they have widely different widths, then the result is not really satisfactory. Amalthea 16:44, 25 May 2009 (UTC)

Except it is broke, hence why the template is called FixBunching. Just because one fix exists doesn't mean we shouldn't explore others. Mr.Z-man 17:32, 25 May 2009 (UTC)

You would quickly get used to it. Further, you wouldn't need to get used to it - whenever you click one of those links, you first look at the heading, and the edit link would be right there beside it. You would not even need to track along that line to the right hand side.   M  18:18, 25 May 2009 (UTC)

For my part, I prefer the links where they are. Make a Gadget? Anomie⚔ 16:41, 25 May 2009 (UTC)

Well, this is obviously something that is going to need the input of more than us few editors. If anyone knows how to get this fully debated by the wider[REDACTED] community please feel free to enable the discussion. Mjroots (talk) 17:47, 25 May 2009 (UTC)

Could you elaborate? Preference is not a reason that I think we should give much consideration to. We should do this to fix bunching, to make the edit link more visible, and to associate a the control with what is being controlled. From the usability study:

"Users often missed the ‘edit’ buttons next to each section, clicking on ‘edit this page’ all the way at the top. This often got them lost if they were editing a particularly long article, as they weren’t easily able to find the section they wanted to edit. Several users also clicked on the wrong ‘edit’ button next to the sections, thinking that the ‘edit’ button below the section referred to the section above."

I think that this overrides preference.   M  18:18, 25 May 2009 (UTC)

We all managed to work it out—maybe the people that can't aren't the kind of people who should be editing a knowledge resource like an encyclopedia. (I don't mean to offend anyone, but it really does seem pretty simple). Dendodge _T\#

That is both offensive and ignorant. Putting 'edit' at the top-right of a section violates the convention of just about every forum on the internet (ever seen edit, reply, quote?). Placing the edit button on the opposite side of the page is like placing a door-handle on the side of the door that has hinges. Abandoning a control that makes no sense rather than continuing to mess with it is perfectly rational behavior. I am not surprised at the reactions, nor at the fact that it takes some getting used to. If you hit a person on the head with a baseball bat every day, pretty soon they'll start making up reasons why getting smacked with a bat is a good thing, and why anyone who doesn't know the exact procedure for the application of ice is an idiot. These people aren't idiots, and thankfully (after how many years?) we finally have a usability study to disprove sentiments like the one you just expressed.   M  20:33, 25 May 2009 (UTC)

You worked it out. I worked it out. Everyone here worked it out. I'm not calling anyone an idiot, I'm just saying that a person who can't work it out may not have the intelligence level required to edit Misplaced Pages. Dendodge _T\ 20:36, 25 May 2009 (UTC)

"Everyone here knows how to apply ice and has gotten used to it, therefore getting clonked with a bat is a good thing" is a terrible argument, and I have no idea how you fail to see that your comments imply that new editors are stupid.   M  20:56, 25 May 2009 (UTC)

No, what I imply is not that new editors are stupid, but that new non-editors are. We need some barriers, to stop people who know very little editing articles. Dendodge _T\ 20:59, 25 May 2009 (UTC)

There is no 'non-editors' group, not being able to use our crappy interface has no bearing on contribution quality, and all people are welcome to edit no matter how stupid.   M  01:13, 26 May 2009 (UTC)

There is actually reason to think that there is an inverse relationship (to some extent) between being able to figure out tech issues of editing WP, and quality of content contributions: older people who aren't particularly web tech-savvy are probably more useful contributors than schoolkids, who generally are web tech-savvy. Plus older people are under-represented anyway, so we should care about making it easy. Personally I don't see the Edit button being on the right-hand side being confusing if it appears in the right place; but if the Usability studies say it is, we should consider moving it. Rd232 18:25, 26 May 2009 (UTC)

I'm quite sure this proposal has been made multiple times in the past... Though I would have no clue where to start looking. As a sidenote, moving the edit link will not "Fix" the bunching problem all together, because it applies to all floating elements, so it will just make the problem less common and even more obscure. I have no particular preference either way. —TheDJ (talk • contribs) 19:17, 25 May 2009 (UTC)

It's no big deal if we have to clear the float on images, but for edit links it might push them down several sections. The bunching problem is pretty much limited to the edit links, I think.   M  20:34, 25 May 2009 (UTC)

There is a lot of relevant discussion to these issue on bugzilla:1629. As you can see, after three years there still isn't a good solution, partly, because HTML/CSS just doesn't account for the way we use floating elements like infoboxes and images. :( —TheDJ (talk • contribs) 21:33, 25 May 2009 (UTC)

I would be tempted to be WP:BOLD about it, if I knew how to change it. OrangeDog (talk • edits) 21:13, 25 May 2009 (UTC)

Since I doubt that interface issues could be resolved in any other way, I would support this.   M  01:13, 26 May 2009 (UTC)

The use of Misplaced Pages is primarily as an encyclopedia. Even those of us who are now active editors here came in most part because we first used it as an information source. The first job of an encyclopedia is to provide information, and the readability of information is a very great virtue. That people can edit is our distinct feature over previous encyclopedias, but what we edit is not a game, and not pure self-expression, but for a purpose. The edit links should be visible, but unobtrusive. And that;'s as they are. Editing should be made easier, but this is not the biggest problem. A much more radical approach than moving links will be needed. The usability survey did find one related problem that can be easily handled: people couldn't figure out how to edit the top section, but this is relatively trivial to fix, they way many of us have fixed it in preferences. Beyond that, altering the basic interface is not the place to be bold. I'd call it the classic example of reckless. DGG (talk) 03:43, 26 May 2009 (UTC)

I notice you recommend unobtrusiveness, seeming to hint that it's for the reason of lessening the likelihood of editing that's merely a game, or pure self-expression, or not for a purpose. But on first viewing an article, users are greeted by some words which invite, in a bold font, "edit this page". Therefore unobtrusive section edit links only go so far in accomplishing the above, while perpetuating the other issue cited earlier: those unaware of section edit links will use "edit this page" unnecessarily, with consequent complications, to which complications I would add the increased potential to damage the article brought by having its entire text open in the editor. I personally feel moving the section edit links to after the section title will indeed go a long way in solving the usability problem identified, and I support this, ideally using a slightly shrunken, subscripted font just like that German page. As to getting used to it, the more prominent link just by the section title should, in my opinion, mean that in practice it won't be hard to get used to, as it will be seen—and seen right at the moment of aligning the eye with where the edit link used to be on the right (remembering that not all section levels are underlined). Lastly, I do feel the "apply ice...clonked with a bat" analogy goes a very long way, not just in this (wider) discussion but in some previous ones too. Far from being critical of anyone by saying that, I do think it's part of human nature that we have this tendency. Could someone please hang that analogy somewhere as a sign, to be cited when necessary in any discussion here? PL290 (talk) 19:57, 26 May 2009 (UTC)

It seems to me that the edit link would get lost if pushed up against the section header. I prefer to keep it out of the way but still associated with the section. Powers 15:50, 26 May 2009 (UTC)

LTPowers, how so? What I suggested will have the opposite effect. Having the edit link immedately after the heading will make it more visible, avoiding any bunching issues. It would look something like this

Article header

The discussion is mentioned in the current edition of Signpost, so hopefully we'll get much more discussion. Mjroots (talk) 15:55, 26 May 2009 (UTC)

It means I have to scan to a different horizontal location on the page every time I want to find an edit link, instead of being able to just go to the right margin. Rule #1 of UI design is to keep UI elements in a consistent place. Having it move around (horizontally) reduces efficiency, even if it is attached to the end of the section header. Powers 18:44, 26 May 2009 (UTC)

Similar arguments were made back when changing the "+" tab text on talk pages to "new section" was discussed; the change went through anyways, and a gadget was quickly written and deployed for use by those who preferred the old text. I see no reason why this same reasoning should *prevent* a change in this case, and why another gadget would not be a satisfactory solution for those of us who prefer the old positioning (and, as if I really have to say it at this point, I support this change). ···「ダイノガイ千？！」 19:38, 26 May 2009 (UTC)

Finding the section edit links was a problem in the usability study. I support moving it to after the section title. - Peregrine Fisher (talk) (contribs) 16:39, 26 May 2009 (UTC)

I'll apologize up front for my language, but: it really pisses me off when an experienced editor says something like I don't like this idea. I know exactly where to find . If you change it, I wouldn't like it because I've gotten used to it where it is. And it doesn't help at all when that is followed by Well, we should make Misplaced Pages editing more difficult, so that less smart people will be discouraged from editing and just stick with reading Misplaced Pages. For those who may have missed the statistics: total edits here at the English Misplaced Pages are down more than 10% since the peak in early 2007, and that's not because of decreased vandalism; roughly two-thirds of existing articles are stubs; an average article gets edited less than once every ten days. We're hurting here, folks.

If you're an editor who has "figured out" a feature, that's evidence that the feature needs to be improved. The closer a feature is to intuitive, with little to no learning curve, the better. We should not be discussing what experienced editors need or like for this particular feature, because this isn't a feature that only experienced editors use; we should be having a discussion about what's good for the vast majority of Misplaced Pages editors, including people who aren't editors yet.

Bottom line: As was pointed out, we had exactly this argument over changing the "+" tab to "new section". All it took was someone to create a gadget for experienced editors to put that tab back the way it was; today novice editors no longer have to deal with such a cryptic tab. Win-win. -- John Broughton (♫♫) 21:13, 26 May 2009 (UTC)

I see the point about horizontal alignment, but your eyes have to slide over to see what the edit link refers to anyway. If you wanted to, you could put first, though I dislike that idea. I'd like to point out that most vandals either blank the page, or vandalize the lead (i.e. use the edit this page button). So is this because the buttons aren't visible? I doubt it; vandals want their message to be prominent. Normally they aren't subversive enough to add something a few sections in. So I argue that anyone editing a section is a legitimate editor, and this proposal would increase beneficial edits (often by less-computer savy people). And I flatly reject that we should require technical competency to write an encyclopedia; new users need to bring only knowledge and good faith. Experienced users can clean up grammar, NPOV, organization, citations, and so on--but the article is better off with the anonymous contributions than without. So why not encourage them? That's the founding ideology of Misplaced Pages. (A gadget for old users would be nice, too, in case we're more trained than we think.) HereToHelp 21:25, 26 May 2009 (UTC)

(ec) That was cryptic—the word "" could not be less clear. I do not strongly oppose this change, but I don't see a compelling reason to alter the sitewide javascript to make it easier for people to work out to what the word "edit" refers. I believe my first (or maybe second) edit was editing a talk page section, so I worked it out (if there was any working out needed) quickly enough. I don't see what's difficult about it, and I think the German layout looks messy. I made a single throwaway comment while I wa stired, and it was misconstrued (a simple mistake, I admit). So the ain reason for my opposing this is the aesthetics of the proposed solution. Dendodge _T\ 21:30, 26 May 2009 (UTC)

It does detract aesthetically; my own support is despite that. However, I think it's likely that that can be improved by subtle changes even with the new positioning. A toned-down greyish graphic instead of square brackets and hyperlink-coloured text, for instance. Or, if preferred, a proper button like someone said. PL290 (talk) 21:51, 26 May 2009 (UTC)

I would support putting it to the left of the header text. Then we can do a proper button, but I think a button would be even worse than a link if hte button appears directly after the text. Dendodge _T\ 21:55, 26 May 2009 (UTC)

I did consider that idea but IMO it detracts more by misaligning the heading with the margin. Unless it can be outside the margin. But I wouldn't imagine that can be done without wasting a lot of space. What about after the header, but a faint greyish rectangle graphic (flat, not a button)? PL290 (talk) 22:00, 26 May 2009 (UTC)

Or underneath the header text, aligned at the margin? (Would need to consider what to do about the horizontal line on level 2 headers. Could either push line down slightly, or insert before line start...or probably best below line) PL290 (talk) 22:14, 26 May 2009 (UTC)

AEB

Sample removed due to TOC-breakage

Maybe like that? Though obviously with a working link. OrangeDog (talk • edits) 23:41, 26 May 2009 (UTC)

That is certainly aesthetically pleasing, but does it not go against the original proposal, which was intended to make the button easier to find? Making it grey just makes finding it harder. Dendodge _T\ 00:02, 27 May 2009 (UTC)

No, it doesn't go against the original proposal, which was to move the button to immediately at the end of the section header. Details like aesthetics can be sorted out later. FWIW, I like the grey version. Now there's been a fair bit of input, what's the best way to go from here. Should I make this into a formal proposal under a subsection with voting for/against? Mjroots (talk) 05:14, 27 May 2009 (UTC)

Done a bit more fiddling with positions at User:OrangeDog/Headings. Seems like the simple place-it-immediately-to-the-right version is the only one that solves the bunching problems as well (unless anyone can see how to do the others without divs). Obviously the colour and style can be whatever, but I kind of like the grey. OrangeDog (talk • edits) 05:49, 27 May 2009 (UTC)

Perhaps requesting this proposal be posted via WP:Watchlist notices and/or WP:Centralized discussion would be in order? --Cybercobra (talk) 07:49, 27 May 2009 (UTC)

Raised at WP:CENT Mjroots (talk) 08:39, 27 May 2009 (UTC)

I think you are supposed to add a link to here in the box on Misplaced Pages:Centralized discussion, not raise the issue on Misplaced Pages talk:Centralized discussion.  Done

I have to say that I never consciously noticed the difference between de: and en:. Now that I am aware of it, from a technical point of view I much prefer the solution with the link directly after the header - it's always clear which section it refers to, and it always seems to be typeset rationally in any browser, unlike our current solution, where the link often ends up in unintuitive and/or inaccessible locations. --Stephan Schulz (talk) 09:39, 27 May 2009 (UTC)

• I'm going to be a heretic and say that I like nice, clean, encyclopedic headers, separate from Misplaced Pages stuff (as in, it's good to have the edit-link away from the section title). If this is introduced using Javascript, will there be an opt-out? ╟─TreasuryTag►hemicycle─╢ 09:42, 27 May 2009 (UTC)

I've removed the proposal from the talk page and added it to the template on CENT. Mjroots (talk) 11:43, 27 May 2009 (UTC)

OrangeDog, thank you for creating those mock-ups to make it possible to see and judge the effect of the different factors. Looking at them confirms my opinion that greying does indeed make the difference aesthetically, and as to positioning, IMO after the title is best as originally suggested. PL290 (talk) 12:13, 27 May 2009 (UTC)

I would point out that, while it may not be intentional, those samples are extremely flawed. The 2, 3, and 4 sample headings should all be possible to do without floats (using margins and position:absolute), and would not have the bunching problem. They could also likely be done purely with CSS, with no JavaScript required. The samples are also constructed differently from how the actual section edit links are made; I'm not sure how they're even usable as a comparison. Mr.Z-man 05:57, 28 May 2009 (UTC)

They are not intended as proposed solutions, just mock-ups of what it would look like. Feel free to modify them (or sandbox your own) if you can make them look the same without introducing the bunching problem. I have no idea how the actual edit links we have now are implemented. OrangeDog (talk • edits) 19:04, 28 May 2009 (UTC)

The problem is that people are basing their opinion about whether solutions fix the bunching issue on the basis of those. The real section edit links are a span inside the heading, before the actual heading text. They're put in the current position by floating them to the right. Something like sample 2 could be accomplished just by setting them to float:none, as that's the position they actually would be in without the float. I tested something like sample 4 using CSS alone,

.editsection {
  float: none !important;
  position: absolute;
  font-size: 60% !important;
  margin: 1.7em 0em 1.5em 0em !important;
}

mostly does it, though I'm not a CSS expert and haven't tested how it looks with different font sizes, browsers, and monitors. Its also optimized for h2's and would need some extra rules for other heading levels. Mr.Z-man 19:17, 28 May 2009 (UTC)

Formal proposal

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.

The result of the discussion was: No consensus. Default to keep as is (outside opinion gained at Misplaced Pages:Administrators' noticeboard#Discussions need administrator closing). I will implement a JavaScript gadget within a few days for those who want to use the proposed layout. –Drilnoth (T • C • L) 13:48, 20 June 2009 (UTC)

That the button be moved so that it appears immediately at the end of section headers (default setting). An opt-out to be made available via user preferences for editors who wish it to remain at the right hand side of the page. Any issues about aesthetics/display are not part of this proposal. Mjroots (talk) 11:43, 27 May 2009 (UTC)

Sample available: I have created a working sample of the edit links using almost exactly the code from the German Misplaced Pages. If you would like to test this proposal (across the entire wiki), just add importScript('User:Drilnoth/sampleeditlinks.js'); to Special:MyPage/monobook.js. Please note that this uses the current font styling, just a different alignment. While testing this, please keep in mind that it would certainly take some getting used to for long-time users who are used to the previous version... please try to look past this while testing it. –Drilnoth (T • C • L) 20:59, 27 May 2009 (UTC)

Well, it's nice that it can be scripted so easily. We're indebted to Drilnoth for drawing that to our attention. So those of us who like it can use it anyway while the debate continues. I confess I'm not personally seeing the suggested "rush to implement" "anything" effect, simply a lot of people who judge that this very thing is a usability and debunching enhancement for newcomers ond oldcomers alike. To those concerned about aesthetics: I recommend adding this line to the script:

     span.style.fontSize = "xx-small";

PL290 (talk) 09:04, 28 May 2009 (UTC)

Agreed; I just wanted to have the sample here use the exact same format as the previous version, so that they could be more easily compared. I'll probably make this code available as a gadget if consensus is against universal implementation, at which point I may allow an option for normal size, normal size but gray, small, and small gray. While people are still just trying it out, I think it should use the previous styling so that "style" isn't involved in this discussion as much as "location". –Drilnoth (T • C • L) 13:31, 28 May 2009 (UTC)

Quite so, you did the right thing. The sample is most helpful in its present form for this discussion. I speak only to any who do feel like copying the mere 14 lines of .js and tweaking their own copy. PL290 (talk) 15:35, 28 May 2009 (UTC)

Question: Any reason why your sample version is working for me on articles, but not on WP:AN/I, WP:AN or WP:RM? Ed Fitzgerald _{t / c} 11:07, 8 June 2009 (UTC)

Can't confirm: I have no issues with those three pages using the script provided by Drilnoth with Firefox 3.0.10/Mac or IE 7.0.5730.13/WinXP. Can you provide details including skin (monobook.css etc), browser, OS and display size (pixel dimensions)? Sswonk (talk) 12:57, 8 June 2009 (UTC)

Actually, it's only working for me on article, not anywhere else, including talk pages in all spaces. IE7 under Windows Vista, monoboook skin, 1280x800. Ed Fitzgerald _{t / c} 06:16, 9 June 2009 (UTC)

Seems to be working everywhere for me using Firefox 3.0.5, Safari 3.1.2 and Google Chrome 2.0.172.30, but not working at all using Opera 9.63. Ed Fitzgerald _{t / c} 06:29, 9 June 2009 (UTC)

Sorry, I didn't see this before. The script probably isn't perfect... I just copied it from the German Misplaced Pages. Browser support for scripts varies greatly. If Happy-Melon's bug report is done, then this can be done with a single line of CSS. The JavaScript can probably be simplified, too... I'll look into this. –Drilnoth (T • C • L) 16:28, 13 June 2009 (UTC)

My apologies as well, I lost track of this mini-thread. I just tested the script on Opera 9.64 Mac and the pages in question displayed as expected, i.e. like every other page. I don't know what could be wrong there - the only thing I can think of is a conflicting javascript. See if 9.64 makes a difference, although I doubt it will. Sswonk (talk) 01:46, 15 June 2009 (UTC)

• Support: Having the edit button immediately at the end of the section headers would remove the bunching issue with Mozilla Firefox and other browsers where this is an issue. Having the facility to display it at the right via user preferences allows those who are happy with it at the right hand side to keep it there. Mjroots (talk) 11:48, 27 May 2009 (UTC)
• Support:There are issues with displaying it where it is on some articles & it hopefully may be more noticeable & encourage editing. dottydotdot (talk) 11:50, 27 May 2009 (UTC)
• Support: Avoids the {{fixbunching}} hack and hopefully addresses usability problems. OrangeDog (talk • edits) 12:02, 27 May 2009 (UTC)
• Support: The WikiFairy in me, noticing that the format proposal explicitly excludes aesthetics, whimpers a little, hoping that this aspect can nevertheless be addressed at some point even if not in the immediate implementation. PL290 (talk) 12:11, 27 May 2009 (UTC)

• As I stated above, I like the look of the light grey button. I've specifically left that issue out of the proposal to keep people focussed on the main proposal. If someone wants to propose a change in the aesthetics/display of the button they are quite welcome to post a proposal to that effect. Mjroots (talk) 12:18, 27 May 2009 (UTC)

• Oppose as I feel that the encyclopedic and editing elements of Misplaced Pages should not be moved so close together, however, the opt-out will mean that I wouldn't be affected in any case... ╟─TreasuryTag►hemicycle─╢ 12:15, 27 May 2009 (UTC)
• Support, as per my comment in the preceding section. --Stephan Schulz (talk) 12:24, 27 May 2009 (UTC)
• Support, per useability study. -- Avenue (talk) 12:35, 27 May 2009 (UTC)
• Support, in principle; there are technical caveats, of course (and some aesthetics :D). Happy‑melon 12:44, 27 May 2009 (UTC)
• Support. Thank you for separating the aesthetics/display issue from the location issue, and noting that there can be an opt-out provision via a preference/gadget. -- John Broughton (♫♫) 13:11, 27 May 2009 (UTC)
• Support. Anything that can help the newcomers. Rettetast (talk) 13:21, 27 May 2009 (UTC)
• support, per Fisher (usability study) and Broughton. R. Baley (talk) 13:52, 27 May 2009 (UTC)
• Oppose. Having the edit link in a different horizontal position for every section is counter-intuitive and inhibits efficient use of the UI. New users encountering a UI for the first time are best served by having UI elements in consistent locations—standards in the field of usability testing are, AFAIK, quite clear on this point. Including an "opt-out" for experienced users is thus no panacea; it is new users about whom I'm concerned with this change. Powers 13:53, 27 May 2009 (UTC)

I think the successful use on the German Misplaced Pages shows that the placement does not cause serious usability issues. --Stephan Schulz (talk) 20:57, 27 May 2009 (UTC)

And the successful use of the current style on the English Misplaced Pages shows nothing? Anomie⚔ 23:34, 27 May 2009 (UTC)

Sure. It shows that the current style is functional as well. But take a look at Homo antecessor#Fossil_sites - how do you edit that section (tested in Firefox3Beta5 with reasonably large windows, and in IE8)? Or edit the References and External Link sections in Bellerophon class battleship. Not impossible, but not very intuitive either. --Stephan Schulz (talk) 15:42, 28 May 2009 (UTC)

But they do not currently appear in consistent horizontal locations either -- have you seen an article with right-floating elements? OrangeDog (talk • edits) 23:24, 27 May 2009 (UTC)

But they are: they are at the right edge of the column of text. It doesn't seem to cause a problem (for me, anyway) that that width infrequently changes, as "the edge of the column of text" is still trivially obvious to locate. Anomie⚔ 23:34, 27 May 2009 (UTC)

Is "immediately following the section title" any less trivially obvious? OrangeDog (talk • edits) 00:06, 28 May 2009 (UTC)

Perhaps not less obvious, but still harder to find. The column of text is a very large rectangle taking up most of the page and clearly demarcated from any bordering rectangles (as those normally have borders and distinct background colors), while the section title is typically a narrower rectangle wedged in between larger rectangles with subtle demarcation. Also, BTW, the end of the section title may not actually be at the right edge of the section title rectangle, if the section title is long enough to wrap onto a second line. Anomie⚔ 00:16, 28 May 2009 (UTC)

Sorry, this is simply not true. Relative to the target of the control (the control is the edit link, the target is the heading), the positioning is perfectly consistent - a few pixels to the right. You are confusing style (which would recommend that similar elements are placed in an orderly way) with usability.   M  02:58, 28 May 2009 (UTC)

Unfortunately, "relative to the target of the control" isn't all that helpful, because "the target of the control" changes size arbitrarily. Consider a series of UI windows in Microsoft Windows. If you want to minimize a bunch of them in succession, would you rather have all the windows maximized, or all the windows at various locations around the screen so that you have to search each one for the minimize button? They're all in the same place relative to their targets, but that doesn't make them trivial to find. I realize these edit links are not used in quick succession, but it still illustrates the problem of having to search for the button. With the current layout, one doesn't even need to look at the section header; one can just go to the right margin and find the first link that appears above the section one was reading. Moving the edit link means one doesn't know where the link will be without first scanning for the header. Powers 13:28, 28 May 2009 (UTC)

If it is easier to find the link than it is to find the end of a heading, then I agree. Given the close and consistent proximity of the link to the title, I don't believe that 'scanning around' for a link is a problem, so power users would not be substantially affected. There are relatively few power users, and they can change this in prefs. A poor association of the link to the heading, due to the distance, is a problem, though, and this has been demonstrated by the usability study.    M   02:46, 29 May 2009 (UTC)

• Oppose - per LtPowers. Also, the WMF has nearly US$900,000 to hire professional UI designers and usability specialists to fix the usability issues over the course of a year or so; I can't imagine that a bunch of random Wikipedians deciding in a week that we know best is doing much more than getting in the way. Mr.Z-man 15:42, 27 May 2009 (UTC)

Mr.Z-man, I don't intend this to be over in a week. As it is something that will be Misplaced Pages wide if brought in, it needs full discussion. I'd expect that to mean at least a month, if not longer. Mjroots (talk) 16:31, 27 May 2009 (UTC)

The poll might last for a month, but the poll is only a binary decision - do this, or don't do it. The discussion about what option to use for the poll only lasted a few days. Mr.Z-man 01:13, 28 May 2009 (UTC)

And Microsoft spent how much money to create Office 2008 and look what they did to that UI. Just because $Some_Large_Sum is being spent on fixing something does not mean that something better will come out of it. Q 21:25, 28 May 2009 (UTC)

The exception does not make the rule. But in any case, the issue is not just money. Its effort and expertise. The fact that some people involved in the initial discussion believe gray links with smaller font on a white/light-blue background is a good idea suggests a lack of UI design skills. There was less than 6 hours between when the mockups were created and when the poll started. There's been virtually no testing and almost no discussion of alternatives. The alternatives were dismissed becuase the 1 set of mockups (which are actually useless as testcases) for the other options didn't fix the bunching problem. Mr.Z-man 21:50, 28 May 2009 (UTC)

• Support. An obvious improvement, agree with other supporters. Sswonk (talk) 16:48, 27 May 2009 (UTC)
  • Adding specificity here: I support the formal proposal that the default position of the edit button be immediately after the heading because I feel it enhances usability, prefer the implementation that is found on the French Misplaced Pages (example DVD article), cite the default implementations found there and on the German, Spanish, Italian, Japanese and other Wikipedias as working models and recommend a clear preference choice and a clear, easily found explanation of the change and the optional setting available once implemented. Sswonk (talk) 17:42, 8 June 2009 (UTC)
• Support: There are multiple reasons for this: It fixes up the horrible bunching issues, it just plain looks better (take a look at the German Misplaced Pages), and it makes it more visible for newcomers who might not notice the "edit this page" tab (which could bring in some more new editors). If this isn't done, making a gadget to allow it to be applied on a user-by-user basis would be good. To mention my view on visuals, having it look just like it is (or maybe a smaller font size) seems fine... in the brackets I doubt that it will disrupt the reading of section headers or anything. Some specific response: LtPowers, I don't believe that the position would be different for each section... every section will have it in the same place, just a different place from where it currently is. I'd also oppose this if it was going to make some edit links be on the left and some on the right, but I don't think that that is the proposal. Mr.Z-man, wouldn't you think that if a group of Wikipedians decides here that the edit button should be moved, that would save the Foundation money and time in doing further studies or polls? I agree that it will take a month or so-long poll, but if there is consensus for the change that will make it much easier on the Foundation (to my knowledge), since all that would have to be done in this case is insert a bit of JavaScript/CSS into the MediaWiki namespace, rather than going through a huge poll or anything like that. –Drilnoth (T • C • L) 16:51, 27 May 2009 (UTC)

  No, because we are not usability experts, we're going by "this looks good" - the usability team will still need to evaluate it to determine if its actually an improvement or works with other things they were considering. Most of the studies are already done, but if we do this, then any data about the section edit links becomes worthless. The money comes from a grant specifically allocated for the usability improvements, so if we don't spend it on usability, we don't spend it at all. Also, what's the difference between "a month or so-long poll" and "a huge poll"? Mr.Z-man 17:12, 27 May 2009 (UTC)

  I'm basing my reasoning on usability as much as ascetics here... my feeling is that if the links are on the other side then they will be more noticeable for new users, would be easier (and faster) to find, and as a result would encourage more readers to start editing. I hadn't been aware that the money was coming from a grant, but if that's so there's still no reason to use it if it isn't required. My feeling is that a "month or so-long poll" is different from "a huge poll" in that it can be set up and implemented by Wikipedians easier, rather than needing some more "official" thing on Meta where it isn't as visible to the average user. Also, as Dinoguy1000 mentions below, this change can both be easily undone if the developers need to, and it would also allow further testing on what the new configuration's usability was in comparison with the old before making a "this is what needs to be done" type of decision that might be a bit more final than what is determined in a !vote here. –Drilnoth (T • C • L) 19:29, 27 May 2009 (UTC)

  Good, now they won't have to spend a few thousand dollars moving the edit link to the left. As for the data being invalidated - this would only give them more data, namely reactions from editors as to the new layout of the button.   M  02:58, 28 May 2009 (UTC)

  The reactions from editors is mostly irrelevant. Editors already know how to use the site. The goal of the usability project is to make the site more usable for others. They can't study that by reading a talk page. They have to do real studies, like the ones they already did 2 months ago. Mr.Z-man 04:07, 29 May 2009 (UTC)

  I categorically reject the assertion that "it just plain looks better". I looked on the German Misplaced Pages and think it looks horrible. Powers 13:28, 28 May 2009 (UTC)

• Support per my reasoning above. Personally, I think Mr.Z-man's argument is just a "don't change what I've gotten used to" masquerading in pretty clothes; this change would have no influence on any usability studies the Foundation has had performed in regards to the section edit link. Au contraire, it would be beyond trivial for the devs to restore the right-hand links if it's necessary, and the findings of such usability studies would include recommendations on new placement of the edit links, which could be implemented quite easily regardless of their then-current placement. I also quite like Drilnoth's suggestion of having a gadget either way, instead of only if the change is decided upon and made. ···「ダイノガイ千？！」 17:25, 27 May 2009 (UTC)

  The usability studies are mostly already done. I've actually put some thought into my argument, but thanks just dismissing it as crap, I appreciate it. I think we're diving into this with too little thought. We started the poll after only 3 days of real discussion. Alternatives were proposed, but the discussion turned to polling before anyone really had the chance to evaluate them. Mr.Z-man 17:35, 27 May 2009 (UTC)

Alternatives were proposed, and quickly shown not to fix the bunching issue. They are still available to be looked at, and compared to each other. I'm sorry that you think that the 3 days discussion wasn't enough, but the discussion remains open for further comments and suggestions. Mjroots (talk) 19:11, 27 May 2009 (UTC)

I certainly didn't mean to dismiss your argument "as crap", and I'm quite sorry if it sounded that way (I have nothing against you personally). However, I still stand by my own comment. ···「ダイノガイ千？！」 19:58, 27 May 2009 (UTC)

Mr.Z-man, I certainly don't wish to dismiss your comment either, but I too wonder why this particular proposed change provokes your line of reasoning, and my concern is, are you therefore saying we're wasting our time by discussing any UI change in this forum? PL290 (talk) 20:14, 27 May 2009 (UTC)

Unless the usability team decides against it and reverts it, we aren't wasting our time, just the usability team's. My main concern is really that of LtPowers, that as a usable UI goes, its worse than what we have now. It fixes the bunching problem at the expense of inconsistency. Combined with rushing into a vote with little discussion and even less testing, I just don't think this is a good idea. I just don't see what the rush is. Why is this something that needs to be resolved post-haste all of a sudden? I'm not saying we need to start conducting surveys of our own, but right now the process looks like "We should fix the bunching problem / This fixes the bunching problem / Excellent, let's vote / It fixes it? Okay, Support!" Mr.Z-man 21:27, 27 May 2009 (UTC)

• Support. Much better visibility and less prone to random up-down float when images, templates etc. interfere. Germans did it again! NVO (talk) 19:33, 27 May 2009 (UTC)
• Support, per OrangeDog. ParlorGames 19:54, 27 May 2009 (UTC)
• Support, fixes the very annoying bunching problems; increases visibility of edit link (but not in an annoying way), thus furthering ease-of-editing for new editors --Cybercobra (talk) 21:12, 27 May 2009 (UTC)
• Oppose The intent of this proposal is to make it slightly easier for absolute newbies to find the edit link, at the cost of making it much slower for everyone else to locate the actual link I tried Drilnoth's script for a few minutes, and verified the speed decrease. With the current style, I can move the mouse pointer to the right edge of the text "automatically" while seeking the appropriate vertical position; with the proposed change, I must seek both horizontally and vertically. Also, with the proposed change it was harder to spot those edit links as they tend to blend into the header when scanning the page.
  I agree with Mr.Z-man that this seems to be a "We have to do something! / This is something! / Let's do this!" discussion; a real usability study involves actually evaluating proposed alternatives for usability instead of just arbitrarily deciding to change things because it might be better. IMO, that should be left to the people being paid to do that sort of thing, instead of a bunch of armchair amateurs. Anomie⚔ 23:34, 27 May 2009 (UTC)

  The same can be said for writing an encyclopedia, but we're doing a damn good job. I'm happy to see more people involved in usability issues. The arguments are hardly arbitrary. Your verified results are suspect, since you've become accustomed to the old interface, and will likely spend some time getting accustomed to the new location. If you can agree that you look at the heading before editing, then showing that this takes a shorter time is relatively simple. You subtract the need to track to the right, and inconsistent link positioning affects nothing since (unlike, say, the scroll bar) you cannot click these links out of the corner of your eye.   M  03:12, 28 May 2009 (UTC)

  For that matter, everything 'you assert is suspect too, and I certainly do dispute your baseless assertions regarding the tracking time. I see in several discussions here you have been extremely quick to dismiss anyone who disagrees with you, only backing down once consensus is overwhelmingly against you. Here, there are a number of people on each side of the debate so there is not likely to be an overwhelming consensus any time soon, but your closed-mindedness is still not helping the matter. But fortunately, it's not my purpose here to try to argue with the closed-minded, so I'll just say "Have a nice day" and leave you to it. Anomie⚔ 03:24, 28 May 2009 (UTC)

  I gave a reason why your experiment is suspect: single user is accustomed to the old interface. Of course you'll be slower at first. Your criticisms belong on my talk page. 19 support, 4 oppose is a great start on consensus. Please read through parts of this book, Fitts's law, and this selection of citations. I can look up some more (better) information if you're interested, most of this is from a quick google search. If you'd like to have a (cited) argument in terms of usability, I'm up for that, in one of the sections above. In the meantime, I don't want other editors to get the wrong idea when you say 'verified', and I want them to understand that at first, a speed decrease is normal.   M  04:03, 28 May 2009 (UTC)

  Let's all calm down a bit. Obviously if consensus is reached that the edit button should be moved, I'd expect that the issue would be investigated fully before implementation by those who deal with such issues as UI. It may be that the default is kept to the right, but a user preference is granted that allows the button to appear immediately at the end of the section heading. Mjroots (talk) 05:54, 28 May 2009 (UTC)

  You might expect that, but I certainly wouldn't count on it. Mr.Z-man 06:24, 29 May 2009 (UTC)

  M, you seem particularly eager to get this change implemented, to the point of trying to shoot down every opposing argument. Is it really that important to you? Can't you acknowledge that there may be some valid points on both sides of the issue? Powers 13:28, 28 May 2009 (UTC)

  Actually, if your overall editing time is significantly affected by searching a (non-bunched) edit button in either style, you must have a much faster brain, faster fingers, and a much faster internet connection than me. For typos, just finding the proper place in the edit box is dominating the edit click, and for real content, thinking and formulating is. Even typing and a preview cycle take longer than to move the mouse pointer hither or thither. --Stephan Schulz (talk) 21:02, 28 May 2009 (UTC)

• Support I don't know how many times I've seen those edit buttons are place they really shouldn't be, and spent quite a while re-aligning images, tables, etc... so things would line up properly. I'd rather have them on the right, but I'd also rather have them work and not screw up with article layout. Place them on the left by default, and give the monobook.jss code for those who would like to see on the right. Headbomb {_{κοντριβς} – WP Physics} 00:32, 28 May 2009 (UTC)
  • This is the problem with rushing directly into polling without adequate time for development or testing. There are more alternatives than the one here in the poll. Mr.Z-man 06:00, 28 May 2009 (UTC)
    • Erm, there was testing, see User:OrangeDog/Headings (which was mentioned above) --Cybercobra (talk) 09:05, 28 May 2009 (UTC)
      • And as I pointed out above, those tests are flawed to the point of uselessness. Also, there were only 6 hours between the time when the test page was linked here and when the poll started. That is not adequate time for testing a major change to the interface. Mr.Z-man 16:02, 28 May 2009 (UTC)
• Support Exactly what Headbomb said, practically to the letter.--Aervanath (talk) 04:47, 28 May 2009 (UTC)
• Support. I hate bunching and playing the "which section does this edit link belong to?" game. MER-C 13:31, 28 May 2009 (UTC)
  • There are other ways to fix the issue besides this one. Mr.Z-man 16:02, 28 May 2009 (UTC)

It's better than the current situation though. MER-C 04:32, 29 May 2009 (UTC)

So despite there being a possibility of an even better option, we should use this because it was proposed first? Mr.Z-man 06:21, 29 May 2009 (UTC)

• Strongly Oppose – I've seen the edit links on other language wikis and it really bothered me. The edit link looks very good where it us, and moving it will create unnecessary hassel and disorder. It certainly isn't broken, so there is absolutely no reason to fix (or brake, rather) it. American Eagle (talk) 20:25, 28 May 2009 (UTC)
  • You don't consider the bunching problem to qualify as "broken"? --Cybercobra (talk) 23:20, 28 May 2009 (UTC)
    • Also, did it bother you in other languages because you actually didn't like it or because you just weren't used to it? Remember that change can be hard to adapt to... for a new user, which would be better? Also, if there's a gadget long-time users can keep it the way it is. –Drilnoth (T • C • L) 03:26, 29 May 2009 (UTC)
      • Cybercobra, no, I have never had an issues with it. Drilnoth, in other languages, I found it very distracting when I was looking for sections headers. I'd see "Primeras etapas de la vida " (for example) and I'd get confused. Although the proposal might save a newbie a half a second (which it may), it will also frustrate many oldbies and distract most readers. If this passes with enough consensus, I won't retire because of it, but I still can't support its implementation. American Eagle (talk) 05:08, 31 May 2009 (UTC)
• Despite my earlier resistance, I conditionally support this proposal, provided that the opt-out is provided as a gadget as soon as the change is made. Dendodge _T\ 20:31, 28 May 2009 (UTC)
• Weakly Oppose—I can see the attraction for this solution, in part because it is a relatively small incremental change to the current situation. However, the fact that it is an incremental change bothers me. I think something more radical would better serve to facilitate and encourage editing. For instance (this is an off the top of my head suggestion - there are other things that could be tried), if the entire horizontal line on which a section title appears were activated to enable launching an edit session, the would be a great help. What do I mean ... in the image below, the text would only appear upon mouseover; the shading would be persistent. --User:Ceyockey (talk to me) 01:47, 29 May 2009 (UTC)
  

• That probably wouldn't be too hard to do with just a little bit of JavaScript and CSS. I'll try to make a mockup. –Drilnoth (T • C • L) 01:52, 29 May 2009 (UTC)
• An excellent illustration of why this poll was premature; there may be multiple alternatives, some of which may solve the problems inherent in both current proposals. Powers 02:04, 29 May 2009 (UTC)
  • This is a bit trickier than I'd thought; I don't have enough experience with JavaScript to code it in any amount of time that it would still be useful for this poll. MediaWiki's setup just isn't quite right to make it easy (the headlines need a class). –Drilnoth (T • C • L) 02:27, 29 May 2009 (UTC)
• This is a bit too obtrusive. A minimal change is good because we have only one factor to worry about - the position. Adding sizing and color would introduce too many factors and objections. Further, the change is exactly what the second-largest Misplaced Pages is already using, and has tested (which is why I find the "it's premature" objections hard to swallow).    M   03:12, 29 May 2009 (UTC)

• Just to clarify, I don't know how I feel on this particular proposal; it could work, but may also have some problems. I was simply offering to try and make a mockup, a task at which I failed miserably. :/ –Drilnoth (T • C • L) 03:25, 29 May 2009 (UTC)
• Again there are more options. Just because the German Misplaced Pages is using this one doesn't mean we shouldn't consider others. Its premature because all the other options presented were rejected because the test cases didn't work, despite the test cases being suboptimally designed and completely unrealistic. Then we started a poll 6 hours later. Everything else was rejected before it had time to be properly evaluated or even brought up. Mr.Z-man 04:07, 29 May 2009 (UTC)

• Mr Z-man, where has everything else been rejected? I think you're maybe misrepresenting the situation, which is this. An idea was floated, it seemed on first appearance to be a good one. A few alternatives were tried and the original idea show to work best. A formal proposal was drafted and consensus sought.

Now, I'm not an expert in the various coding etc needed to achieve the suggested change. It may well be that there are technical reasons why the English Misplaced Pages can't have it. It may be achieveable and set as the default, or alternatively made available via user preferences. The discussion is still open, if you (or any other editor) has another suggestion, please propose it and let the community state whether or not they support the proposal. This isn't something I'm trying to bring in overnight. It needs the involvement of a large number of editors over a reasonable period of time because the suggested change, if implemented, would affect all users of Misplaced Pages. Mjroots (talk) 05:18, 29 May 2009 (UTC)

I think you're missing my point entirely. The one option worked best because in the one and only test done, all the other options were done incorrectly, and there was no time for more extensive coding or testing or discussion before the poll started. I never said there are technical reasons why this couldn't be done (though there are technical reasons why other solutions are better, specifically they can be done without JavaScript). Its probably too late at this point to propose something else, especially since the poll has already gained inertia and I prefer to actually test things properly before suggesting them (though I did provide some CSS code above that could be used as a start). This may very well be the best solution, but since there's been no real testing done, we'll never know. Mr.Z-man 06:21, 29 May 2009 (UTC)

I think this would be too easy for readers to click accidentally. --Cybercobra (talk) 04:19, 29 May 2009 (UTC)

• Pollster Since there haven't been votes for a while (over 12 hours), I counted the votes so far and got 19-For (76%) vs. 6-Against (24%). But keep in mind WP:POLLING and all that. --Cybercobra (talk) 19:28, 29 May 2009 (UTC)
  • I count 5+6+6+3+1=21 support (including the proposer, the unbolded support, and the conditional support), and 6 oppose. There are 4 more supports below, making it 25/6 for this section.    M   15:38, 8 June 2009 (UTC)

• Comment: I've been using the script that I created so that this can be tested since I created it. At first it was kind of strange, because it's in a different location, but I've found that I'm already growing used to it. I strongly urge anyone who isn't sure of their feeling on this to try out the script for a good amount of time—not just a few minutes or hours—and give it a chance. I'm honestly surprised by how quickly I got used to the location. –Drilnoth (T • C • L) 19:33, 29 May 2009 (UTC)
• Comment—If someone has access to a software simulation tool, such as iRise (the only one I'm familiar with), then we wouldn't have to wait for resolution of code technicalities in order to have full page mockups of various options. This is true of both the present and other usability discussions. --User:Ceyockey (talk to me) 23:59, 29 May 2009 (UTC)
• Enthusiastic Support. The stupidly brain-dead postioning and bunching problems with the section edit links have long been an annoyance. older ≠ wiser 21:16, 30 May 2009 (UTC)
  • I am happy for your enthusiasm, but please try not to call other peoples' hard work "stupidly brain-dead". –Drilnoth (T • C • L) 21:56, 30 May 2009 (UTC)
    • I didn't mean to demean anyone -- but whatever hard work may have been involved, the flaws of the section edit link placement have long been an annoyance as well as a usability problem. older ≠ wiser 22:05, 30 May 2009 (UTC)
• Support with the same enthusiasm, and same disdain for our collective lethargic tolerance of an obviously broken solution, as older/wiser above. The proposal specifically provides an opt-out for those who prefer it the broken way, so "I don't like it" is even less of an argument than it is usually.--Kotniski (talk) 22:20, 30 May 2009 (UTC)
• Support the general idea, although I understand the objections. Even after a year and several thousand edits, I more-than-occasionally find myself reflexively reaching for the "edit this page" tab at the top of the page when I just want to edit a section. Aesthetically (when there aren't ugly bunching and displacement problems), the current placement has much to recommend it. But the balance of reasons very strongly favours putting the link next to the (sub)section header, either to its left or more closely to its right. New editors (and new readers who may not even known they could edit) are far more likely to see it (as the usability study showed), and the bunching/displacement issues can be greatly diminished for the overwhelming majority of working editors who have neither the knowledge, the skills, the patience nor the inclination to start fiddling around with Javascript, CSS, monobooks, etc. (If an automated option can be entered into User Preferences, then that becomes a rather different question about default appearances, etc. Maybe the current format could then be offered as an option there.) —— Shakescene (talk) 23:52, 30 May 2009 (UTC)
  • I must have missed the part of the usability study where they actually tested different positions for the section edit link. Where in there are those results hiding? Anomie⚔ 01:56, 31 May 2009 (UTC)
• Support; this not only takes care of the bunching problem, it also (to me) appears to be more naturally intuitive. I do understand TreasuryTag's objection, but I think we cannot hide the connection between the two aspects of our project here. One question: Will the section edit link be as small as it is now? Certainly it will not match the section heading font size, will it? Unschool 02:32, 31 May 2009 (UTC)
  • I believe the proposal is just to change the position of the edit link and not otherwise modify how it looks. That bit of bikeshed-painting has been left for another discussion. --Cybercobra (talk) 02:43, 31 May 2009 (UTC)
    • Cybercobra is correct; the result of this discussion will just determine whether or not it should be moved. If there is consensus for this, another discusison will be held regarding appearance before the change is actually implemented. –Drilnoth (T • C • L) 02:47, 31 May 2009 (UTC)

Arbitrary break

• Comment I've just filed Template:Bug, which will make this effect achievable entirely with CSS, no JS needed. Happy‑melon 10:16, 31 May 2009 (UTC)
  • Update Template:Bug was closed as repeat of Template:Bug, which was reopened for consideration of this issue. Finell (Talk) 16:04, 14 June 2009 (UTC)
    • Actually, it was reopened in 2007, because the patch that "fixed" it in r28517 was reverted in r28630. Anomie⚔ 17:35, 14 June 2009 (UTC)
• Strong oppose (vote changed to "Support if there is just evidence that readers prefer this structure"). This spoils the readability of the page and only serves to make it easier for certain editors to click on a button. I prefer the button on the right, where it doesn't interfere with the flow of the page, but that's exactly what it is: a preference. I strongly don't believe that the entire 'pedia should be changed just at the preference at certain people. If you desperately want it that way, you can use Javascript or CSS to enforce it, but don't drag the rest of us into it. I also disagree with this "opt-out" scheme. As the problem is is supposedly aesthetics, we would generate more problems than we solve if different editors view the layout of the page in different ways. Greg Tyler 17:43, 31 May 2009 (UTC)
  • Many users already view pages differently than say, non-editing readers. Skins drastically change page appearance, and things like User:Drilnoth/rounded.css can drastically alter a page's appearance for certain users. I haven't found this to be a problem. Second, how does it spoil the readability of the page? Just because the edit link is in a more visible location? You can still just read the section headings... I've been testing this for awhile now and at this point don't even notice it. Having three or four edit links bunched up together in places destroys readability more, IMO. Also, at this point there seems to be more consensus for the change, so I'm not sure if saying that "I strongly don't believe that the entire 'pedia should be changed just at the preference at certain people." really applies... if it was a minority trying to make this changed, then yes, but based on the discussion here, it would appear that the minority don't want it changed. –Drilnoth (T • C • L) 18:01, 31 May 2009 (UTC)
    • The problem here is that it's entirely a matter of preference, right? Some people think that changing will improve readability, ease of use and suchlike. Others, such as myself, believe that implementing will lead to a decline in readability, ease of use and suchlike. Hence, the best solution is the make the implementation a simple "Yes I want it" or "No I don't" checkbox in Special:Preferences. I'm completely up for that, but why the proposed structure should be marked as default..? The default should, of course, be the structure that readers prefer. I would believe that to be our current system, but that's entirely subjective...
    • My point is that we're polling the wrong people. We editors can always change our preferences, and the site shouldn't revolve around us. Its primary concern is what the readers think, so it's they who we should be asking. Though how you want to organise a poll amongst readers that isn't bias, disallows any sort of rigging and gives a fair consensus, I know not. Perhaps it's just easier to edit Special:MyPage/monobook.js if there's a part of the design you draw issue with? Greg Tyler 18:40, 31 May 2009 (UTC)
      • This is a good point. My feeling is that yes, it is just a matter of preference. Some people would prefer the links in the proposed location, some in the current location. The thing is, if this poll was being held when the wiki was first being started and these were the results, it would be obvious that consensus was to have the link near the header. Consensus can change. In essence, the answer your question of "why the proposed structure should be marked as default..?" would be "Because that's what the consensus is for." Something's having been one way for a long time doesn't really change the consensus.
      • You have a very good point about polling the wrong people. However, do you have any ideas as to how we could ask the readers about this issue? People who have never edited wouldn't really care about it—some don't know that you can edit, some don't have the time, and some want to leave it to other people—and many probably wouldn't fully understand what this was about if they haven't already edited, but moving the link might make some more people (those in the first group) edit. –Drilnoth (T • C • L) 18:51, 31 May 2009 (UTC)
        • You've picked up my point perfectly, thanks. The people who should be polled are, for the majority, not going to answer any of our queries. This means that the entire thing would be on such a small scale that fair and useful consensus simply couldn't be generated. I feel we need to talk to readers about this but personally, yet I have no idea how we can do so successfully. To me, that's the biggest step to overcome in this proposal. Greg Tyler 19:00, 31 May 2009 (UTC)
          • That's exactly the sort of polling the usability people are being paid to do. Right now, we have results saying "some absolute newbies missed the section edit button" and people are somehow using that to justify assuming (without any evidence at all) that this proposal will be better and without any other adverse effects. And the worst part is, some of them apparently don't even realize how vastly they're misrepresenting the study. IMO, we should let the usability people do what they're being paid to do, since they have the resources to actually perform the needed studies, and revisit this only if they inexplicably ignore the issue. Anomie⚔ 01:18, 1 June 2009 (UTC)
            • If it's a preference matter, I'd be quite happy for the solution to be having it made available via user preferences instead of an arbitrary change. Even if this proposal is passed up the chain as "consensus is that something needs to be done, what do you think of this, should it be the default, or made into a user preference?"I'd be happy with that as an outcome. Mjroots (talk) 08:23, 1 June 2009 (UTC)
  • This is not about aesthetics. It's in part a response to results of the usability study, which found that
    "Users often missed the ‘edit’ buttons next to each section, clicking on ‘edit this page’ all the way at the top. This often got them lost if they were editing a particularly long article, as they weren’t easily able to find the section they wanted to edit. Several users also clicked on the wrong ‘edit’ button next to the sections, thinking that the ‘edit’ button below the section referred to the section above."
    In addition to the issue of bunching, this provides two reasons why the current implementation is difficult to use. Many editors have expressed support that this will solve these issues. Given that we are acting on the appropriate data, would you consider changing your vote - or perhaps your reason for objecting?   M   19:16, 31 May 2009 (UTC)
    • Perhaps, then, we ought to wait until the usability testing can test this proposed solution and see if it works before we go changing the new-user experience, possibly for the worse? Powers 12:33, 1 June 2009 (UTC)
• Support - In many larger articles, the edit buttons freak out - more so in some browers than others. I understand that we cater to readers and not editors too, but I feel having edit buttons appearing in seemingly random places like little ghost buttons completely ruins the flow and readability of many otherwise quality articles. Not only that, but the edit button problem has actually kept me from adding images to articles before, as I was afraid of screwing up the button layout. With that in mind, it can dissuade people to add useful content to articles the way it is now. Cheers! Scapler (talk) 20:54, 31 May 2009 (UTC)
• Support - As was pointed out above, on de.wiki they are already doing this and they don't seem to have any problems. I agree that the text should be made small; smaller than the header for sure, and probably smaller than the article text. I would also support making it a separate CSS class (if it isn't already) so that anyone who doesn't like the new setup could simply revert to the old one via a custom entry in their CSS file. Soap /_{Contributions} 01:21, 1 June 2009 (UTC)
• Information – The following table is provided for informational purposes. Several have mentioned that the German Misplaced Pages uses the editsection button directly after the h2 header.(^and also all other headers marking an editable section - Sswonk (talk) 01:28, 15 June 2009 (UTC)) This is also the case on other language versions. The strictly arbitrary table shows the top 12 Misplaced Pages language versions based on article count, a link to a sample article ("DVD", chosen arbitrarily because the title is the same in all languages), and the non-formatted, position-only disposition of the editsection button on that site.

http://meta.wikimedia.org/List_of_largest_wikis ranked by article count

Misplaced Pages version	DVD article	Disposition of edit link
English	en:DVD
German	de:DVD
French	fr:DVD
Polish	pl:DVD
Japanese	ja:DVD
Italian	it:DVD
Dutch	nl:DVD
Portuguese	pt:DVD
Spanish	es:DVD
Russian	ru:DVD
Swedish	sv:DVD
Chinese	zh:DVD

Sswonk (talk) 04:13, 1 June 2009 (UTC)

• Info The bunching problem is actually an FAQ on WP:Village pump (technical). --Cybercobra (talk) 04:39, 1 June 2009 (UTC)

• Information – Just a little bit of background to the so called "German solution" (which in my ears sounds a bit weird …):
  I did the first version of the script back in March 2005 for mainly three reasons: The screwed up edit links when they intersect with floated elements, the (in my opinion) better usability, and because back then the edit links where placed before the headings in the HTML code which made no sense to me.
  I used the script just for myself in the beginning, but as the problem with floating edit links came up repeatedly I showed it to others in October 2005.
  When in July 2006 DaB. enabled it for all users in de, about 50 to 60 people were already using it. As DaB. just was bold and did it without any prior discussion (or telling me) the following discussions where quiet fierce. Mainly because the script was meant to be opt-in and so it had no opt-out build in at that time. The rest of the discussion had exactly the same arguments as here.
  In October 2006 the structure of the edit links was changed in MediaWiki from having a div above the heading to a span inside of the heading (but still before the headings text). That made it possible to shrink the script down to a few lines of code, which Marc Mongenet and I did more or less simultaneously (at least I guess so, because his version was online a little prior to mine, but I don't remember looking over to the French Misplaced Pages.)
  The French version was later modified by Maloq who claims that his version ist 500 times faster … didn't check this, just found it myself today.
  So in the languages Sswonk listed you'll find several different versions of the script, if you plan to try it with js before it gets integrated in MediaWiki itself (won't believe it until its done), choose wisely. I wrote this mostly to make clear that this is not some hasty reaction, lots of people are working on it and with it for years now. --Dbenzhuser (talk) 16:02, 1 June 2009 (UTC)

• MORE information! :) I think that I mentioned it somewhere above, but it may have gotten lost in the shuffle. I've been testing this out for a few days now and am almost completely used to it... it actually makes much more sense to me than the current stup does and I think that it is easier to use. The first day or two it was kind of weird, though; please try it for awhile before !voting to see if you experience the same effect I did. –Drilnoth (T • C • L) 16:26, 1 June 2009 (UTC)
  • As has been pointed out by M several times, this isn't about how easy it is for us to use this, since there will no doubt be a way for individual registered users to set this as a preference, but rather whether this change makes any difference for new and inexperienced editors who, according to the usability study, had trouble finding the edit links before. If they will still have trouble with the edit links, then this doesn't seem worth implementing, at least not as the default. Powers 16:31, 1 June 2009 (UTC)
    • I think fixing the bunching problem makes it unequivocally easier to find the edit links when bunching is present. Any usability difference between directly-after-section-name vs. right-aligned is minor compared to the gains of fixing bunching. --Cybercobra (talk) 17:05, 1 June 2009 (UTC)

• Support either fixing the problem (the stacked edit markers is an identifiable problem) or creating a new way to do it that avoids the stacked ambiguity issue is preferred. I have no preference on either solution, but one of them should be implemented. As for "They spend $900,000 for user interface"...I think they are getting ripped off... — BQZip01 —  03:57, 2 June 2009 (UTC)

• Information – In the Chinese Misplaced Pages, there is actually a gadget for registered user to choose such that the edit button appears immediately after the heading, similar to German, French, etc Misplaced Pages. --Quest for Truth (talk) 14:11, 2 June 2009 (UTC)
  • I think it was determined that regardless of the outcome of this discussion, the other version would be available as a gadget in each users' preferences. –Drilnoth (T • C • L) 14:15, 2 June 2009 (UTC)

• Support if there is just evidence that readers prefer this structure. I was previously unaware such a survey had been undertaken. If it has, then I support this proposal. Greg Tyler 16:12, 2 June 2009 (UTC)
  • I for one am not aware of any such study; the "usability study" referred to several times above contained a statement that the new editors in the study often missed the section edit button, and sometimes confused it for editing the section above instead of the section below. There was nothing in there about trying alternative positions to see if they were any better. Anomie⚔ 19:12, 2 June 2009 (UTC)
• Oppose. I honestly can't see what's to be gained by moving it and I don't see any issues with the current alignment. If it ain't broke, don't fix it. However, if it does go through, I support the idea of an opt-out version. Queenie 20:41, 4 June 2009 (UTC)

Even without considering any usability problems, there's the whole bunching issue. {{FixBunching}} is really quite a messy hack. OrangeDog (talk • edits) 22:49, 4 June 2009 (UTC)

It obviously is broken though. For example, I've had to click on the link in the Formal Proposal section to edit here. The issues with alignment/bunching are not common to all browser, but it is known to affect some, such as Mozilla Firefox. Mjroots (talk) 06:49, 5 June 2009 (UTC)

• Oppose- I've never seen this as that much of a problem and moving the link right after the section title is an eye sore and a readability issue. For example, if I reading aloud I would be tempted to read the edit link as well. It would just be in the way. This would only fix a few articles but I would support a different method to prevent it from overlapping.-- penubag  (talk) 17:15, 6 June 2009 (UTC)

• Support - I prefer to see the edit button immediately following the section header. In my experience, the righthand location tends to screw up from time-to-time, interfering with other texts or even images. Whenever it does this, it seems that fixing the problem for one browser seems to mess it up on another. (I have also suspected there might be a “skin” problem, but I’ve not checked for it.) Askari Mark (Talk) 02:28, 7 June 2009 (UTC)
• Oppose Click Recent changes some time and tell me if people are having a problem working out how to edit a section. WP is not a forum where we want people to add their opinion. Efforts should aim to make the encyclopedia read well. I don't want any klunky "edit me" text or button inside the article when I am reading it. Sure, new editors are totally lost. That's because they are new – a problem that won't be solved by moving the edit link. It's totally patronizing to imagine someone can't notice the link where it is. Johnuniq (talk) ]09:49, 7 June 2009 (UTC)
  • Just to clarify - are you seriously suggesting that we should make things harder to edit to prevent a few people from adding opinion? Please see the usability study, quoted several times above, which shows that new editors do in fact have problems with the positioning. Further, this very proposal is one of the designs that the usability team itself is developing.    M   18:09, 7 June 2009 (UTC)
    • One: So let Usability consider it. Two: We haven't changed anything yet, so to say "You're making it harder" is not only a poor choice of words, but also a modest use of hyperbole. Three: Which also depends on point 1. --Izno (talk) 14:19, 8 June 2009 (UTC)
      • Good, let them handle it. Meanwhile, let's not let "well, someone else will take care of it" stop us from making some sorely-needed progress. If this is the sort of opposition that the usability experts will be facing, then I'd like the precedent that this poll sets to be one that is in their favor.    M   15:24, 8 June 2009 (UTC)
        • But it might not come back in their favor, exactly because there are many people supporting this change, and not the change they will recommend. For all we know, they could say "get rid of the editsection links" or "you should make them as obtrusive as possible making them stretch the entire length of the section". Unlikely outcomes, but nonetheless possible. When they come back, we should make the move then to say "Yes, we want to go with your idea here" or "No, we think that's a terrible idea, can you cook something else up for us?". There is no deadline. --Izno (talk) 15:33, 8 June 2009 (UTC)
• Support. Improves usability (IMHO, at least—it's largely a personal preference issue). AGK 14:10, 8 June 2009 (UTC)
• Oppose for the aesthetic reasons mentioned. Further, I do not see the reason why we are polling on this when the usability initiative is already doing the same, and they're professionals. We are not. Consistent placement is important. --Izno (talk) 14:19, 8 June 2009 (UTC)
  • I believe this is being discussed here as a stopgap measure until a more permanent solution is implemented as a result of the study. Regardless, as I see it, reliance on a solution arrived at by the initiative crew could be compared to using a crystal ball, as could speculation that such a solution would be widely accepted – or widely rejected. The "reliance on professionals" argument is specious. The current implementation is semi-broken and should be fixed one way or the other. Ideally the position of the editsection button should be an option available under "My preferences". Sswonk (talk) 14:54, 8 June 2009 (UTC)
    • A stopgap measure for which obvious problem? Editsection is obviously not broken in its primary function; what are we trying to fix? We're working on the presumption that what we're doing would "fix" something, but I'm not seeing the "something" and I'm not seeing that it would positively fix it. Usability could decrease from the change! We could close a can of worms and then open up another! In its own way, the support is crystal-balling as well.
      I implore you to explain why you consider it fallacious. They were hired, by Wikimedia, to make the fixes that we don't know that we could. You seem to assume that I would fall trap to the argument from authority (which perhaps you assumed?); usability initiative is there to recommend changes, not force them on us. The change being considered here...
      As for the current implementation, it's not broken enough (from mine, and others' point of view) to expend the energy to fix any possible backlash against the idea once implemented. Its a documented issue, and you're more then welcome to remind the initiative of it, because as pointed out, they are breaking down a wiki-page to see what needs 'fixing'. Let them figure out what they want to say, and then we can take that into consideration. A bug, with CSS and not our own, with floating, isn't enough reason to get ahead of them and ourselves here. We've long had the issue of working with it, and we do have the hacks to deal with it necessarily. Not only that, but if you're getting image bunching problems, that could be a problem with the layout of the article... which I've not seen used as an argument. Consider what the MOS says about image layout: You should attempt to stagger the images instead. --Izno (talk) 15:18, 8 June 2009 (UTC)
      • You exaggerated my points a bit: I did not use the word "obvious" to describe the problem, although I did use it perhaps over-enthusiastically to support the change several days ago for my opinion of usability benefits, and I used the term "semi-broken", not "broken". I don't rest easy with complacency-based solutions anywhere but I'll leave it at that. However, I think your point about backlash is a very important one that deserves recognition. Will you at least agree with me that a preference-based, gadget choice which should be fairly trivial to implement in my estimation is desirable based on the comments here and more importantly on the widespread use across other language versions of a beside-the-header editsection button? BTW, I think we could use another "arbitrary break" after this mini-thread. Sswonk (talk) 15:39, 8 June 2009 (UTC)
      • (responding to Izno): Consistent placement of edit links is important, but right now the bunching problems that come up when you have longer infoboxes, side quotes, and images makes their placement inconsistent, whereas putting them next to the section headers consistently puts them in one place: At the end of the section's titles. I've been using my sample JavaScript for a week now, and I'm actually finding it easier and more natural to find the edit links now than I had before. I also haven't found that they get in the way acestetically... since section headers are bold and given more weight, and the edit links are just plain text, they don't really interrupt the flow of the article any more than they ever did. Also, you say "...the usability initiative is already doing the same, and they're professionals. We are not." If the usability study hadn't been done I think that this still would have come up. So do you feel that because there is currently a study going on, the discussion about and possible improvement of Misplaced Pages's interface should just stop simply because of their study? That doesn't really make sense to me... if they find that the change is problematic, then it can be undone easily, but why should we stop working to improve something because of a simple study? We wouldn't stop improving content if there was a study on Misplaced Pages's reliability. –Drilnoth (T • C • L) 15:50, 8 June 2009 (UTC)

• • • • • Sswonk: The javascript is obviously floating around, which is just as good as a gadget. I've no opinion either way.
          Drilnoth: You may be right that people may have opposed it anyway, but that's a non-issue. What I'm saying is that we shouldn't duplicate effort (especially when our "effort" is inferior implicitly), and that's what we're doing. Your comparison is inept, because we would already know the criticisms in that case. It's more like changing the interface when we don't know what those criticism are. --Izno (talk) 00:02, 10 June 2009 (UTC)

• I briefly considered ignoring this comment, but I've decided it shouldn't go without a rebuttal. A javascript may result in an equivalent format displayed on the screen, but for usability it is not "just as good as a gadget". A gadget provides a front end, GUI method to implementing a javascript. Your statement is like saying "DOS commands are just as good as clickable icons." Xerox PARC, Steve Jobs and Woz and the friendly folks at Microsoft all took a look at that sentiment from the usability persepective and they all disagreed with it many years ago. Sswonk (talk) 16:17, 13 June 2009 (UTC)

• Pollster For this section, 5 support, 4 oppose, 1 conditional support. Previous section 25:6. This brings the totals to an even 30 support and 10 oppose. This is since 27 May 2009, so 13 days or about two weeks since this poll began. As usual, see WP:POLLING, though I doubt this is a problem here since everyone has had something to say.    M   15:57, 8 June 2009 (UTC)

Edit links arbitrary break 2

• Strong support. There are some good objections which I think have been addressed: the link will no longer be consistent along the right - yes, this looks slightly worse, but is ok; and that we should let the usability people fix this - no, this is up to us to implement. Some other objections are really strange: a few seem as if the editors were aware of neither the points about bunching nor the usability study; at least a couple seem to oppose this because it would make it easier for the technologically inept to edit (right - we want this). The main objection now seems to be readability (that is, aesthetics). This takes a far back seat to usability (incidentally, I have found absolutely no readability problem with the new position while using the script). As for the reasons to do this, they are plenty:
  1. Moving the edit link fixes bunching, which is currently being addressed with the {{fixbunching}} hack. This is a very objective problem.
  2. Our current position violates the convention of making the 'actions' at the bottom (bottom right) of the text. This is the convention of many interfaces and nearly all discussion boards, which most people are familiar with (cf. 'edit, reply, quote'). The usability study has found that the current position causes new editors to click the wrong edit link, and presumably waste time looking for text that won't be there.
  3. Our current link is set too far apart from the heading text, which the study shows makes it easy to miss.
  4. It is clear that bringing the link beside the heading will solve a) bunching, b) wrong section editing, and c) poor visibility.
  5. It is not permanent, if the sky falls we can change it back.
  6. The new position is strange at first, but the editors who have reported back after trying it have given positive feedback.
  7. This is precisely the solution that the usability team is providing here, see a mockup here.
  8. This certainly is not just some new and slightly crazy idea: it has been implemented and tested on the second-largest Misplaced Pages, and it is working fine.

   M   17:13, 8 June 2009 (UTC)

Most of those would also be true for pretty much any positioning except the current one, but since we never properly tested anything else... Mr.Z-man 17:36, 8 June 2009 (UTC)

I failed to mention that this is another good point, and it would be nice to brainstorm something even better than this solution, but we've had 2 weeks with only one alternative proposed, the usability group has had time, as well as the german wikipedia. This seems to be the best thing we have. Something better and more radical would have died in the archives. At least small and clear steps like this are generating discussion.    M   17:47, 8 June 2009 (UTC)

I don't think 2 weeks is adequate time to develop, test, and vote on a significant interface change. This had the benefit of already being developed and tested on other wikis, so every other possible proposal was way behind from the beginning. The brainstorming should have been done before the poll started, but that part of the discussion only lasted a few days and didn't properly test anything. Its the best thing that's been proposed because its the only thing that's been proposed other than the status quo. There are several things that could be done that would be just as radical as this change, would also keep the links in a consistent horizontal location, and may not require JavaScript to implement, but nobody's willing to give them more than a passing thought, because jumping on the bandwagon of this is easier. Mr.Z-man 18:12, 8 June 2009 (UTC)

• Support. I tried the css code proposed by Mr.Z-man above (I only changed position to static), which places edit links at the beginning of section titles, and found it rather convenient. So, I support, this proposal, if there is an opt out option, which allows me to keep control over where my edit links are set. Ruslik_Zero 18:51, 8 June 2009 (UTC)
  • CSS and JavaScript will be usable to change the location regardless of the "default". I think that this proposal is to have the edit links immediately after section headers... I don't know if there was a typo in your post or if you wanted to support a version different from what is primarily being discussed right now; just thought I'd mention it. –Drilnoth (T • C • L) 19:36, 8 June 2009 (UTC)
  • Note that what I gave above was not a proposal, merely a start/proof of concept that that could be done while still fixing the bunching issue. It would definitely need more work and testing by someone with more CSS expertise than myself to be viable. My point was merely that there are more options than the one being presented here, that was just one of them. Mr.Z-man 19:59, 8 June 2009 (UTC)
    • Mr Z-man, as I've stated above, I'm open to other suggestions. I've asked above for other suggestions to be posted, but so far there have been none. As I've also stated above, I realise this will be a big change if implemented. It may be that the best way forward with this particular change will be to make it a user preference rather than an arbitrary change. Either way, something needs to be done, and as has been pointed out, the change I suggested is well tried and does work on otherw Wikis. Mjroots (talk) 20:28, 8 June 2009 (UTC)
      • Exactly, all the testing for this idea is done, which means any other proposal needed to do the development, testing, and polling in the time of the polling for this one. There were 3 days between the time the thread started and the poll started. That is not adequate time for development and testing. Mr.Z-man 20:37, 8 June 2009 (UTC)
        • Well, even if this does go through, what's stopping the development, testing and proposal of another method at some time in the future. Absolutely nothing, that's what! Mjroots (talk) 21:11, 8 June 2009 (UTC)
          • People are generally resistant to change, even more resistant to frequent change. Mr.Z-man 21:19, 8 June 2009 (UTC)
• Support moving the edit button to the end of the section header... --candle•wicke 23:34, 9 June 2009 (UTC)
• Weak oppose I prefer the consistency and unobtrusiveness of having the of the having the edit links on the right side. As for bunching, I do not think that a rendering problem with one browser on a minority of pages should be a factor in determining presentation style. A technical problem warrants a technical solution. Also, I do not believe a change in position would have a significant impact on the ability of a first-time to find an edit link. However, if this is a driving factor for change, I'd suggest an experiment: Write a temporary script that shows the edit links after the header for odd IP addresses and right aligned for even IP addresses, and review IP editing statistics after a day or so. -- Tcncv (talk) 01:17, 10 June 2009 (UTC)
  • I believe that bunching is a problem on every major browser, as well as a problem on most pages with an image. I'm not sure that it makes sense to say both that it would be more obtrusive, and also just as easy to miss. Perhaps you could give the script a try for a week or so?    M   00:42, 11 June 2009 (UTC)
• Support moving the edit link or button to the end of the section heading. This would improve layout problems on many articles, which ovrrides the unobtrusiveness concern, in my opinion. Finell (Talk) 16:26, 14 June 2009 (UTC)
  • Question Why are many editors talking about this as a proposal for level 2 (h2) headings? The same layout problem applies to all heading levels. I hope no one is thinking that they should jump back and forth (or, right and left) for different levels. Also, please note: we are discussing section headings; a header is something else. Finell (Talk) 16:26, 14 June 2009 (UTC)

What I intended is for all levels to be presented the same, with the button appearing immediately after the last character in the heading. Mjroots (talk) 18:55, 14 June 2009 (UTC)

• Strong oppose, but will move to Support if the button is GREY and not bright blue—If I understand correctly, the bright-blue "" would be shunted so that it's immediately to the right or under the section title. Bad idea from a visual perspective. En.WP has it much better positioned than the French and German projects, which have obstructive blue jostling with every title. It's as though all readers were WPian editors. They're not. About 0.000000001% are. My view is unchanged by the regrettable and occasional tangling of the edit button with images. Perhaps we could fix that problem as a separate issue. Tony (talk) 08:21, 16 June 2009 (UTC)

Tony, you understand the proposal perfectly. The problem of tangling of the edit button with images is precisely what the proposal is trying to fix. See West Kingsdown Windmill, an article I expanded today. Before expansion there were no bunching issues. After expansion, with an additional infobox, there are several. I've imported Drilnoth's script,bypassed the cache, and the bunching problems have disapperared. All edit buttons falling neatly at the end of the heading. Mjroots (talk) 13:41, 16 June 2009 (UTC)

Tony, please understand that this poll is only about the placement of the edit button, not its appearance. It will probably be made smaller than the current button, and perhaps in gray text. That will be decided after this if there is consensus to move the link. –Drilnoth (T • C • L) 19:14, 16 June 2009 (UTC)

• Support, it is far too easy to click the wrong link with the current setup. The workaround we use against bunched-up editing links is a wrong way to address the issue (we should not change the page layout to make non-reader elements (the edit links) appear correctly). Keeping the edit links with the section headers is much cleaner. Kusma (talk) 08:48, 16 June 2009 (UTC)
• Oppose per User:Anomie and User:Mr.Z-man. This poll is extremely premature. Garion96 (talk) 10:52, 16 June 2009 (UTC)
• Oppose per Tony. Also, in defence of {{fixbunching}}, it fixes other text layout too. If this does go ahead, an opt-out will be needed (and thus {{fixbunching}} won't be going away). Mark Hurd (talk) 13:43, 16 June 2009 (UTC)

Consensus seems to be that the existing situation should be retained, either as a user preference, or by making this proposal accessible via a user preference. Mjroots (talk) 13:47, 16 June 2009 (UTC)

• Comment Seconding Mjroots. I'm thinking that at 5 support, 4 oppose for the latest section break, with many well established comments on both sides, this proposal has gained a clearer consensus. Can a few editors comment on how difficult it would be to simply add a gadget that loads the Drilnoth javascript? I think that would serve two purposes, that is advertise this proposal as an option to a much larger group of editors that might not know about this thread, and also avoid any backlash against changing default behavior. Is adding a gadget feasible and non-disruptive enough, thoughts? Sswonk (talk) 13:58, 16 June 2009 (UTC)

  Adding a gadget is very easy, it just takes an admin to follow the instructions at WP:Gadget#Installation. Anomie⚔ 14:25, 16 June 2009 (UTC)

  Great. An added advantage to this approach that I neglected to mention is that the gadget would provide a quick and obvious method for new or otherwise interested editors from the non-English wikis such as French, German etc. who maintain accounts here to change the style of the editsection button to something they are familiar and comfortable with. Sswonk (talk) 14:57, 16 June 2009 (UTC)

  A gadget is planned regardless of the outcome of this !vote to allow the other version to be selected in preferences. –Drilnoth (T • C • L) 19:14, 16 June 2009 (UTC)

• Oppose, per DGG well above. SandyGeorgia (Talk) 15:49, 16 June 2009 (UTC)

Comment DGG has not !voted on the proposal. Mjroots (talk) 16:08, 16 June 2009 (UTC)

DGG commented above (I do hope you understand that consensus is not a "vote"?) SandyGeorgia (Talk) 16:10, 16 June 2009 (UTC)

• Conditional support only if there is a setting available at the same time that would allow me to move the edit links back to where they are now.--Rockfang (talk) 18:28, 16 June 2009 (UTC)
  • There should be an option in Preferences>Gadgets after this poll ends to allow the version which isn't the default to be used instead. So if consensus is for the change, you'd be able to go back to the current version with about four clicks. –Drilnoth (T • C • L) 20:16, 16 June 2009 (UTC)
• Support in the other languages where it appears on the left, I got used to it quickly. The en: system of it being on the right makes little sense once you get used to the left-alignment. TheGrappler (talk) 20:13, 16 June 2009 (UTC)
• Oppose. Mainly on aesthetic grounds (I simply prefer the section heading not to be diluted with functional syntax). If there is no other way of avoiding the technical glitches with a right-aligned "" link, then okay; but I'd be very surprised if the right-align-initiated problems couldn't be solved in other ways. On a purely practical point: following the left-alignment of the "" link, be prepared for a sustained larger number of school-kid-type edits on the intellectual level of "wazza was here". In any outcome, I would make the "edit" link much smaller—e.g. (or an icon of equivalent size).  HWV258  22:45, 16 June 2009 (UTC)
  • I really don't understand these objections on aesthetic grounds. This isn't a proposal based on aesthetics, it's a proposal based on usability. Further, with cleanup boxes, infoboxes, poor layouts, spelling mistakes, paragraphs of fluff, and occasional glaring errors, surely the position of the edit link is the least of our readability concerns. We might as well be arguing about making all of our links not blue. Since these aesthetic oppositions are somewhat common, yet always neglect the usability points, I would like to know what they think about it. And isn't it the point to make[REDACTED] easy enough for an 8 year old to use?    M   05:55, 18 June 2009 (UTC)
    • Its a proposal to change the UI, while usability is important, we shouldn't totally ignore aesthetics, that's just irresponsible. Mr.Z-man 16:48, 18 June 2009 (UTC)
    • "And isn't it the point to make[REDACTED] easy enough for an 8 year old to use?"—but not every eight-year-old. Call me a snob, but I'm happy to do away with the services of any eight-year-old who can't find on the right-hand-side of the screen.  HWV258  01:26, 19 June 2009 (UTC)
• Support, to fix the bunching issues and for rationality, but allow the user to pick both from settings. feydey (talk) 13:16, 17 June 2009 (UTC)
• Support Anyone editing a section is almost surely not a vandal. Why not make it easier for good faith anons? HereToHelp 16:37, 18 June 2009 (UTC)
• Strong Oppose. This misguided proposal confuses readability with usability. Readability for the overwhelming majority of users who have no desire to edit the article must always take precedence over the convenience of the very small number who do. --Malleus Fatuorum 21:39, 18 June 2009 (UTC)
• Oppose per DGG. –Juliancolton |  21:46, 18 June 2009 (UTC)
• Oppose per DGG and Malleus. NW (Talk) 23:12, 18 June 2009 (UTC)
• Oppose Readers come first, always. Dabomb87 (talk) 23:20, 18 June 2009 (UTC)
  • IMO, this is about the readers. We're trying to encourage readers who don't know that the wiki is editable to give it a few copy edits, correct a misspelled word, etc. Additionally, I didn't think that the links interfered with reading the section headers, even when I had just first installed my test script. –Drilnoth (T • C • L) 23:25, 18 June 2009 (UTC)
    • Actually, on testing the script, the edit links on level two headers (==) were not that bad. However, I found the edit links on level three and lower headers very obtrusive. Also, I've enabled the edit link for lead section; I didn't like seeing the edit link right next to the page title. Obviously, that wouldn't affect readers, but it did affect my decision. Dabomb87 (talk) 02:28, 19 June 2009 (UTC)
      • I'm pretty much neutral on the level 3 and lower headers, and I hadn't though about the level 1 head. That could probably be fixed so that it doesn't affect the header without too much difficulty. Also keep in mind that if this passes the edit link will probably be smaller and/or a slightly different color, so it might not be as in the way with level 3 and lower headers. –Drilnoth (T • C • L) 02:34, 19 June 2009 (UTC)
• Support. The main reasons to support this are both practical and aesthetic (because of the bunching problem, the floating edits are ugly and silly); the main reasons to oppose are aesthetic and a belief that the editing aspects of Misplaced Pages should not be so obvious. There is little doubt that the aesthetics of the bunched edits are ugly. While it is a matter of opinion that left aligned Edits are less appealing that right aligned Edits. It may well be that those who prefer the way they are now are aesthetically conservative by nature - it is simply a matter of opinion, and those aesthetically in favour of right aligned edits are on the sample of this poll, in the minority. As for "readers over editors", I would agree with that argument if we are talking about not placing tags such as {{Orphan}} and {{Copyedit}} on articles, but we are not - we are simply talking about moving the word Edit from a place where it is impractical and occasionally clearly unaesthetic, to a position where it is useful, helpful, aesthetically acceptable to the majority, and encourages readers to edit. It's a win, win, win situation. SilkTork * 19:23, 19 June 2009 (UTC)

• And yet, somehow millions upon millions upon millions of edits to WP have somehow happened with right-aligned hyperlinks. Go figure.  HWV258  09:06, 20 June 2009 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Gadget

MediaWiki:Gadget-lefteditlinks.js has been created. You can now activate the left edit links as a gadget in Special:Preferences. Please report any bugs at User:Drilnoth/lefteditlinks.js/doc. Thanks! –Drilnoth (T • C • L) 14:29, 20 June 2009 (UTC)

See also: User talk:Drilnoth#Gadget addition without discussion and Misplaced Pages:Administrators' noticeboard#Discussions need administrator closing, the former about my Gadget addition without a formal proposal and the latter about closing this as no consensus rather than "change". All comments at both are welcome. –Drilnoth (T • C • L) 18:22, 20 June 2009 (UTC)

Last I checked (I didn't count the recent additions), it was 3:1 in favor. Is that not consensus? How is it no-consensus when the issue of whether encouraging editing should be a priority (upon which many oppositions depend) hasn't been adequately discussed? (It is a priority, by the way - why do people think all that money's going to the usability study?) Defaulting to the current interface on usability or aesthetics is often a bad idea (there's that story of ebay having to slowly fade out its (ugly) yellow background because users complained when they got rid of it in one go).    M   08:53, 26 June 2009 (UTC)

I get about 40 support and 19 oppose total (counting the section since the last Pollster and assuming that Pollster was accurate for everything prior). --Cybercobra (talk) 21:41, 26 June 2009 (UTC)

Provide "New Section" header box on virgin talk pages

If you look at many discussion pages, you may have noticed that the first section-heading is often preceded by what looks like disorganized random chatter. The likely reason for that just struck me today. When you visit an empty talk page, for example Talk: Crotona Park, it just invites you to start a discussion.

A new user with a question or comment on her or his mind might just start typing the substance without thinking of giving it a title (or perhaps even knowing how). This is different from what the "New Section" tab shows and similar to what happens with a new article, which we want to start with an untitled lead paragraph (something that doesn't apply to most talk pages). "New Section" does provide a box for section headers, but that's actually slightly less necessary when earlier sections show editors an example and a method. Is there some way we could open empty talk pages with a section-header box, or at least instructions for how to enter "====" to start the first section? —— Shakescene (talk) 22:08, 2 June 2009 (UTC)

Support I just had to clean up such a talkpage conversation earlier today. --Cybercobra (talk) 22:48, 2 June 2009 (UTC)

: This is the greeting at the (now-empty) Talk:Crotona Park:

Editing Talk:Crotona Park

Misplaced Pages does not have a talk page with this exact title. Before creating this page, please verify that a subject page called Crotona Park exists.

* To start a page called Talk:Crotona Park, type in the box below. When you are done, preview the page to check for errors and then save it.

This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~).

...Comment: Even should we do nothing further (which I strongly believe we must), at least the last instruction should not be "To start a page called Talk:..., type in the box below" unless the box is changed to something closer to a "New Section" page. Otherwise, eliminate the box and instead direct the user to the "New Section" tab. (For example, "To start a page called Talk:..., please open the "New Section" tab above this panel.") —— Shakescene (talk) 03:09, 3 June 2009 (UTC)

I like the idea: it's definitely a problem; this is a solution. One little thing though - if all to start the page is a WikiProject, then this needs to be taken into account; on the other hand, if there's only WikiProject headers then you'll still need this thing (I think). Good idea generally though. - Jarry1250 20:37, 4 June 2009 (UTC)

I'm sorry, but I don't think I quite understand what you're trying to say. —— Shakescene (talk) 06:17, 11 June 2009 (UTC)

It's a good point about the WikiProject headers, which may have been placed in otherwise empty talk pages: any solution needs to take that into account and not just kick in for "virgin" talk pages per the proposal. PL290 (talk) 19:18, 12 June 2009 (UTC)

Support At minimum, the extensive, yet deficient, instructions that appear, as shown above, should be updated to the requisite effect, but ideally the system should automatically bring about the conditions under which the user, by default, starts a section when none is yet present (while also continuing to provide the means for WikiProject headers etc. to be added without creating a section). True, it would be easy enough for someone in the know to add a single section header later, on encountering the page, but by that time any number of separate conversations may have been jumbled together. PL290 (talk) 19:18, 12 June 2009 (UTC)

Support There should be a button there just like any other talk page. Reywas92 17:52, 11 June 2009 (UTC)

Slightly different proposal - How about instead of just adding a tab (which is a good idea anyways), the default is set to New Section? See http://en.wikipedia.org/search/?title=Talk:Crotona_Park&action=edit&redlink=1&section=new . Adding that &section=new to the default redlink will create the section title. People who are simply adding templates can click back on the edit tab. ▫ JohnnyMrNinja 18:23, 12 June 2009 (UTC)

I think that would quickly get extremely annoying for many users. Happy‑melon 18:40, 12 June 2009 (UTC)

No, that would get really annoying. – iridescent 18:42, 12 June 2009 (UTC)

I hesitate to say it, but no, that would actually get annoying. PL290 (talk) 19:18, 12 June 2009 (UTC)

I'm confused about what's so annoying (regardless of whether this is the best particular solution). Is it that it would greatly complicate the addition of Wikiproject, rating and other tags at the top? —— Shakescene (talk) 19:09, 13 June 2009 (UTC)

I don't see the annoyance either. I mean, talk pages are for talking, right? Wouldn't logic dictate that we should make it as easy as possible for new editors? I admit that I've added a lot of project banners to blank pages (I think my average edit-per-page is like 1.5). I've spent a fair amount of time simply hitting random until I see a page with a redlinked talk page. I can safely say that I wouldn't find it annoying to have to hit edit to add a template to a talk page. That's what you have to do to any other page, right? How would this be different? Maybe I'm confusing the reasoning, but is the feeling that talk pages should be optimized for adding templates rather than comments? ▫ JohnnyMrNinja 05:41, 15 June 2009 (UTC)

Note that the new section tab is already there on new talk pages. Mr.Z-man 05:56, 15 June 2009 (UTC)

• I do not think that this is particularly important. For example, for, I would say, most new talk pages (Pokemon, BLP, and Stephen what's his name), all you are adding is a talkheader, and there would be considerable confusion if you were given a section heading that you did not want. However, has anyone noticed (duh it is probably in the perennial section), that when you do click the "new section" tab, it is impossible to add an Edit summary, even if you click "Show preview"? 199.125.109.124 (talk) 19:59, 26 June 2009 (UTC)

• • I don't think you fully understand the problem. It's far from the most-urgent issue in Misplaced Pages but it's still real. A large number of talk pages (perhaps a majority) begin with unorganized clutter, often on several different subjects and in apparently random order, without any indication of their topic. And, unlike a box you can fill in yourself, the "talk header that you did not want" often gets imposed (sometimes years after the original posting) by frustrated editors like me who are trying to make some kind of logical, readable order from the talk page. The absence of an edit summary in new sections is something I've also noticed, and might well merit a separate section on this proposal project page. —— Shakescene (talk) 07:33, 27 June 2009 (UTC)

structuring a straw poll

¶ Just to keep this section from getting bot-archived without resolution, I was thinking of creating a straw poll here, and then using the results to form a more-formal Request for Comment (with attached technical requests). I was going to break the poll into:

1. leave things as they are,
2. leave things as they are, but with guidance to the "New Section" tab,
3. leave things as they are, but with instructions about creating a "==]==" header,
4. change the virgin (or open) talk page to include an automatic new section letterbox, as in Johnny's "Slightly different proposal" above,
5. any other suggestions.

Would this be a good format for a straw poll, or does anyone have other ideas? —— Shakescene (talk) 07:18, 21 June 2009 (UTC)

New 'Autopatroller' Usergroup

The autopatrolled usergroup is now enabled on the English Misplaced Pages as the 'autoreviewer' usergroup. Thanks go to Andrew for a speedy addition. A guideline on WP:Autoreviewer will be going up within the hour, but it should be no different than how the whitelist currently works. NW (Talk) 16:24, 22 June 2009 (UTC)

The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should the usergroup 'autopatrolled' be added for the English Misplaced Pages and be given out to editors already entrusted with this via an unstable bot-workaround?

For the past several months and years, several editors including myself have been working on patrolling the NewPages backend. What we do there is ensure that every new page is seen by a pair of eyes, so that we don't get another Seigenthaler incident. However, the amount we have to patrol is often staggering, and takes the entire group several hours to work through a day's log. Because the amount of articles we have to manually patrol is usually extremely high, we have to use a bot, User:JVbot, with a whitelist, to patrol some well-established editors' contributions. However, the problem with relying with this is that Jayvdb cannot always reliably run his bot, and so New Page Patrollers are left with situations where patrolling the articles before they fall of the backend without ever being looked at is almost impossible.

However, there is an easy fix for this, and it involves activating a userright that is already in use on the English Misplaced Pages. The 'autopatrol' userright, which is already given to bot accounts and administrators, could be given to users in an 'Autopatroller' usergroup. This is already done on many small wikis, such as the English Wiktionary. This is more reliable that the current system because everything happens on Wikimedia's servers; it does not rely on a private computer that is subject to breaks, downtime, and and coding update necessities. Rather than edit a protected page in Jay's userspace, any admin could assign the flag through Special:UserRights.

In summary, this proposal would replace an unweildy workaround with a feature already built into MediaWiki. There would not be any additional bureaucracy, but rather a simplification of the process to allow everything with NPP to work more easily. So, what do you all think? NW (Talk) 00:17, 18 June 2009 (UTC)

• Strong Support It is about time we had this. What we are doing right now mitigate the problem makes little sense now that a better solution is available. — Jake Wartenberg 00:27, 18 June 2009 (UTC)
• Strong support. Makes total sense. Durova 02:53, 18 June 2009 (UTC)
• Support - Those editors who are currently whitelisted for JVbot would acquire the autopatroller userright, thus making JVbot redundant. I can't see anything to object to in that. EdJohnston (talk) 03:04, 18 June 2009 (UTC)
• Support. This would make new page patrol much easier without actually increasing exposure to bad edits in practice - any bad-faith editor who could manage to pass scrutiny for the flag is clever enough to sneak bad edits through already. Let's make the best use of our patrollers' valuable time. — Gavia immer (talk) 03:29, 18 June 2009 (UTC)
• Support. BTW, what share of new articles (those that survive NPP) is created by the chosen ones on JVbot list? Is it really substantial?
  • On a second thought, JVbot whitelist itself must be cleaned up. Inclusion of User:Dirgni and User:Kisuga, for example, seems premature. NVO (talk) 05:20, 18 June 2009 (UTC)

Thanks, I'll check those two out. DS (talk) 11:47, 18 June 2009 (UTC)

• Question Is it necessary to create a new usergroup? Would not 'rollbacker' or 'autoconfirmed' group suffice. Ruslik_Zero 11:22, 18 June 2009 (UTC)

Packaging an autopatrolled right with autoconfirmed would be a horribly bad idea. We have a lot of autoconfirmed editors who simply cannot be trusted to consistently create valid articles -- for instance, pagemove vandals. And people apply for rollbacker because they need it, whereas being added to the bot's whitelist is because we the patrollers need it. It's based on our decision, not theirs. DS (talk) 11:47, 18 June 2009 (UTC)

• Oppose—this can easily, with great congruity, and with little trouble, be packaged with the rollbacker usergroup. ╟─TreasuryTag►Captain-Regent─╢ 11:27, 18 June 2009 (UTC)

Doing that would either make rollback a lot harder to get or lower standards for getting autopatrolled. Countervandalsim is a separate area of work from writing articles, and someone could know what they are doing in one area, but not in the other. The standards for getting on the list we have now is pretty high; most users on it have created upwards of 50 pages. Rollback is already a bit too hard to get for new users. So I really don't think these should go together. There really isn't any harm done by the extra flag. — Jake Wartenberg 15:58, 18 June 2009 (UTC)

• Neutral on creation of new group. Support bundling it with 'rollbacker', definitely. I really hope you're not suggesting, Dragonfly, that this group would be applied to users that the patrollers feel should have it, whether they want it or not, as a convenience for the patrollers. That's turning the permissions system completely on its head. We give out tools to people we trust not to abuse them. Do you trust rollbackers not to be creating invalid articles? Then they should have this permission. Happy‑melon 11:51, 18 June 2009 (UTC)

• The thing is, this is not really a tool that affects what article writers see at all; the only people this would affect would be patrollers. As for the rollbackers group; from my experience at rollback, you usually need less than 100 reversions to get rollback. I really don't want a grawp vandal to get rollback (which there are screenshots of people doing that) and then using 'autopatrolled' to get BLP vandalism past the NPP log. MrZ-man puts it really well when he says "I don't trust every rollbacker to write a valid article. Rollback is given to people to revert vandalism, people are added to the JVbot whitelist when they've shown proficiency in writing articles – the two are entirely unrelated." NW (Talk) 17:38, 18 June 2009 (UTC)

• Support as written. I would oppose adding it to autoconfirmed (not enough experience, not manually reviewed, non-revocable) and I would oppose adding it to rollbacker. Besides the fact that I oppose expanding rollback for anything other than its original intention (dealing with vandalism), I don't trust every rollbacker to write a valid article. Rollback is given to people to revert vandalism, people are added to the JVbot whitelist when they've shown proficiency in writing articles – the two are entirely unrelated. I would not be surprised if there were a significant number of rollbackers who have never written an article from scratch. While I have nothing against them, I don't believe that all of them should automatically get the autopatrolled right. The permissions system is only what we make of it. There's nothing in MediaWiki that says groups should only be added to people who ask; that's just how its worked here, mainly because of lack of reasons to do it any other way, but now we have one. Mr.Z-man 15:54, 18 June 2009 (UTC)
• Support with preference for a separate group (with pos. opt-out membership); possible support of also packaging it with other established groups (not autoconfirmed though). - Jarry1250 15:58, 18 June 2009 (UTC)
• Support, much more elegant than a bot-controlled method. –Drilnoth (T • C • L) 16:06, 18 June 2009 (UTC)
• Support Seems to be a good idea. Captain panda 17:41, 18 June 2009 (UTC)
• Support a separate "autopatroller" group. Oppose bundling it with "rollbacker". Bundling privileges into "rollbacker" not related to rolling back vandalism risks turning it into "admin lite". --Ron Ritzman (talk) 00:47, 19 June 2009 (UTC)
• Support as written. MER-C 02:52, 19 June 2009 (UTC)
• Support (as written) — Speaking from experience on an offsite wiki, this is very useful to have. Also, per Ritzman above. --Izno (talk) 05:11, 19 June 2009 (UTC)
• Support. Though giving this to rollbackers would also be useful. I also want to remind that if FlaggedRevisons are enabled, patrolling (in the main space) will be disabled, so this new group may be short lived. Ruslik_Zero 07:53, 19 June 2009 (UTC)

  That's a very good point. Brion wants to get FlaggedRevs deployed on enwiki before Wikimania in August, at which point patrolling will be disabled in flagged namespaces. Happy‑melon 08:49, 19 June 2009 (UTC)

  I've said it before and I'll say it again: FLAGGEDREVS WILL DROWN US. DS (talk) 12:40, 20 June 2009 (UTC)

  But the trial configuration includes patrolled revisions, making the group just as important. It will however be redundant to the "reviewers" group in that users in that group will have the "autopatrolled" right. — Jake Wartenberg 18:26, 19 June 2009 (UTC)

  I had the impression that the recentchanges patrolling feature is disabled with flaggedrevs (mw:Help:Patrolled edits), which we don't use, so it won't affect us, but AFAIK the newpages patrolling interface is not disabled (mw:Help:Patrolled pages), see here (10th point). In the configuration, the review/patrol flag marks pages as patrolled in the NPP sense, but it's not reciprocal. So it won't be redundant, the reviewers group will have much more clearance. There are three distinct meanings for patrol: NPP, patrolled edits and patrolled revs, I know it's confusing... maybe patrolled revisions should be renamed to reviewed revisions. I had thought of proposing this usergroup too, so I support it. Cenarium (talk) 22:20, 21 June 2009 (UTC)

• A suggestion. I think the group should be called 'autoreviewer' for compatibility with Flagged Revisions. Ruslik_Zero 14:03, 20 June 2009 (UTC)

  See my comment above. An autoreviewer group would have much more clearance than an autopatroller (NPP sense). Cenarium (talk) 22:20, 21 June 2009 (UTC)

• Support either name. After giving it thought, I strongly oppose granting this right to the rollbacker group: rollback is, and has always been, an anti-vandalism tool, and thus these two permissions have completely different roles. A new userright is preferable specifically for this task. PeterSymonds (talk) 14:09, 20 June 2009 (UTC)

Resolved – ThemFromSpace 21:33, 26 June 2009 (UTC)

• Misplaced Pages noticeboards
• Protection templates