Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

• 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 Wikipedia:Village pump (policy).
• Proposed new wikis belong at m:Proposals for new projects.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Suggestion to make Cancel button as noticeable (in same type of box as) the 3 boxes to its left

When I was first using Wikipedia (it can be overwhelmingly confusing at first if you're not used to looking at lots of mark-up!) I used to accidentally miss (not be able to find) the cancel button quite frequently, and sometimes ended up clicking on 'save page' or 'show preview' instead! (Then having to undo it, I think. It's all a bit of a blur, honestly, but I know I kept missing the cancel button.) So I think it might be helpful if the cancel button was as noticeable as the 'save page' and 'show preview' buttons, perhaps just by putting it in a box like the 3 currently to its left? (And maybe making it red, or pink, or something.) Just a thought. Thanks very much. (p.s. Wikipedia is great! I love it! Go Wikipedia!)--Tyranny Sue (talk) 04:31, 9 April 2009 (UTC)

I think making it a button isn't too bad, but coloring it different... I dunno.
Keep in mind that you can also always just hit "back" in your browser, or click on the "article" or "discussion" tabs at the top (depending on where you are). EVula // talk // ☯ // 04:36, 9 April 2009 (UTC)

I think this is a great idea to make it a 4th button (Save page/Show preview/Show Changes/Cancel edit) and would cut down on accidental newbie saves that appear as vandalism. Is there any way this can be advertised more for a larger audience to discuss? --64.85.214.183 (talk) 18:51, 11 April 2009 (UTC)

Great idea, aside from the coloring. Cancel is as much an action as the other three, and standard in most interfaces. –M^T 02:27, 19 April 2009 (UTC)

This is a great idea and really, why was it not included in the first place?! The very fact people have commented on it raises that simple question. In addition, if people make a mistake and don't correct it, it simply creates more work for everyone else!? I think the most relevant question is...Why isn't it a button, rather than why it should be a button.

Let's see some postive action on this Wikipedia ^©Wiki User 68 ^Talk_Work England  Portal 00:15, 24 April 2009 (UTC)

• Support fahadsadah (talk,contribs) 17:27, 26 April 2009 (UTC)
• Support — The inclusion of 'cancel' as a button would allow its selection via tabbing (at least in Firefox), which is the main method that I use to navigate from edit screen to action when editing (working on an edit, tab => summary line, tab-tab => minor-edit, tab-tab-tab => watch, tab-tab-tab-tab => save, etc.). Using the keyboard shortcut like this is faster than navigating to the action link by mouse. Until I can type with my mouse, I will retain a fondness for keyboard shortcuts. --User:Ceyockey (talk to me) 11:41, 3 May 2009 (UTC)
• Support, see above. –M^T 04:30, 5 May 2009 (UTC)
• Still interested in seeing this go through -- what would the next steps have to be? –M^T 22:23, 9 May 2009 (UTC)
• Support HarryAlffa (talk) 17:57, 11 May 2009 (UTC)
• Support changing it into a button; don't really support coloring it Nanowolf (talk) 07:48, 14 May 2009 (UTC)
• Oppose We have too many buttons already—the editing page is rather crowded. In addition, the cancel function is useless (for me, at least, as I prefer going back or simply closing the tab). Ruslik (talk) 18:28, 16 May 2009 (UTC)

Page crowding is not an issue since the proposed change in appearance will occupy no more space. PL290 (talk) 20:42, 16 May 2009 (UTC)

I disagree; the button will in fact take up more screen real estate than the simple link that exists there right now. As Ruslik points out, the page is crowded. However, the complexity (or perceived crowded-ness) of a page is not just a function of how many things are it, but also how those things are organized; if there is consistent organization (e.g. all page-level functions presented by buttons rather than some by buttons and some by links), more things can be added without the page becoming overwhelming. --User:Ceyockey (talk to me) 01:27, 17 May 2009 (UTC)

Quite so, I expressed it badly and should have said that, in my opinion at least, page crowding is not an issue with the proposal and that the proposed change will occupy hardly any more space. A button will indeed occupy slightly more space than the link but will potentially reduce page crowding for precisely the reason you give. PL290 (talk) 13:33, 17 May 2009 (UTC)

I neither oppose or support this, and I'm merely leaving a comment. Regardless of whether Cancel occupies more space, horizontally or vertically, it will not really affect the layout of the page at all. The table directly under the save/preview/changes line is wider than the save/preview/changes line itself. Therefore, despite taking up the additional pixels of a button instead of a link, the page layout would be, essentially unchanged. Even for low resolution users, the change would not make a significant change to the layout (such as wrapping the row of buttons down to a new line). The additional horizontal space used would be approximately 20 pixels or less (I haven't gone and figured it out exactly), and as I mentioned above, the table below it (with Insert, the hotlinks to special characters, reminder to sign pages, and cite sources) is already significantly wider than the line with the buttons on it. Phuzion (talk) 08:12, 23 May 2009 (UTC)

Addition to my comment: The text-based browser links, formats buttons in the following format: [ Button Title ] Links are just shown in an alternate color. This would take additional horizontal space (4 characters), but like I said earlier, the table below is still wider. Phuzion (talk) 08:16, 23 May 2009 (UTC)

• Support (except for colour)—Cancel should be a button having the same appearance as the other three, to visually group it with them as an action that can be applied to the current editing. PL290 (talk) 20:42, 16 May 2009 (UTC)
• Support Didn't even know there was a cancel button (used to just press my browser's "back" button). YOWUZA Talk 2 me! 18:16, 25 May 2009 (UTC)

Watched counter

The proposal in this box is shelved/withdrawn until the proposal in the next sub-section is resolved. (May be worth reading for background on that proposal, though)
The following discussion has been closed. Please do not modify it.
Wikipedia:PEREN#Create_a_counter_of_people_watching_a_page There are more good editors than vandals. Even if making the counter visible and the 'unwatched pages' page public resulted in massive abuse, editors would quickly remedy the problem by adding unwatched pages to their watchlist. Can an admin tell us how many pages there are on the unwatched list? Reasons for doing this, or why the 'vandalism' objection is invalid: Good editors would overwhelm vandals. Displaying "<5" for 0-4 would make this useless for vandals.[1] If there are still vandal concerns, an adminbot could be set up to ask recently-active editors to "adopt" articles. This would allow editors to find pages that needed "adoption". This would relieve the admins who are taking care of the unwatched list. What other reasons were given against this proposal? It might help if the PEREN page linked to the discussions. Without knowing what was said, the reasoning sounds like "the vandals would make this impossible", which is often a poor objection. –MT 03:50, 19 April 2009 (UTC) The list of unwatched pages is limited to 1000 entries, sorted alphabetically. It is rare that it extends beyond the letter A. Every time it is refreshed, there are a number of editors who dutifully watch hundreds of pages from it, yet every time it is refreshed with a new list. It really is like emptying the Atlantic with a teacup. I think the problem is hugely more widespread than you anticipate. Happy‑melon 09:36, 19 April 2009 (UTC) Not that they don't need watching, but how many of the first 1000 are redirects? Mark Hurd (talk) 11:26, 19 April 2009 (UTC) Given that points 1 and 2 would address the vandal problem, doesn't what you're saying just give us all the more reason to support this proposal based on points 4 and 5? –MT 13:51, 19 April 2009 (UTC) Another possibly 'simple' short-term solution is to provide another special page that lists unwatched pages by order of most recent edit and that can also still be limited to the first 1000. If that overlaps between runs, we'd be clearing the backlog from the more 'important' first. Otherwise we're no worse off. Mark Hurd (talk) 00:12, 20 April 2009 (UTC) Great idea. This would not only eliminate vandalism worries, but would also be extremely useful. This feature is a frequent request, is useful and informative, and aside from vandalism I don't think there are objections. We have the following options: Modify wgAllowPageInfo to display "<5 watchers" Change the list to order by last-edited rather than alphabetical, reduce displayed entries to 100, allow all to see it Change the list to order by least watched, then last-edited, reduce to 100, rename it to "least watched articles", allow all. I would support going directly to 3, but we can do a more gradual roll-out by implementing 1 and 3 (I think these are trivial changes, but perhaps a dev could comment) and then removing 1 when the list starts to shrink. Were there any lurking objections? –MT 00:53, 20 April 2009 (UTC) In the flagged protection and patrolled revisions trial implementation, special:Unreviewedpages, which lists pages that have never been patrolled, will indicate the number of active users watching the page. It's only accessible to reviewers. Cenarium (talk) 01:00, 20 April 2009 (UTC) This seems like its a lot more trouble than its worth. If you really want to help with vandalism, just get rollback and download huggle. I disagree that "Good editors would overwhelm vandals." really deals with the vandalism problem. This sounds like how wars used be fought, where each army would just stand in a line and shoot at the other one, and the bigger one would usually win. It worked, but not particularly well. Saying that fewer than 5 people watch a page still makes it nicer target for vandals, it just doesn't narrow it down quite as much. Since the people watching it might have left the project ages ago, it could still have 3-5 watchers but effectively be 0. Mr.Z-man 01:02, 20 April 2009 (UTC) Countervandalism activity is more than just RC patrol. Somebody needs to watchlist articles to catch the vandalism that the RC patrollers miss -- the majority of my vandalism reverts take place hours to days after the fact. --Carnildo (talk) 01:19, 20 April 2009 (UTC) I wouldn't like vandalism patrol, but I would like to make things much easier for editors and much more demoralizing for vandals. Your objection seems against the weakest part of the proposal. The implementation of #3 is a trivial change to an SQL "ORDER BY". The strongest part is editors being able to adopt unwatched pages. This is strengthened by the possibility of a "least watched last edited" page. Vandalism already targets unwatched pages (just click random and mess up an obscure article), this proposal would allow editors to target this already-vulnerable class of pages. –MT 08:07, 20 April 2009 (UTC) When your database contains several million rows, changes are rarely "trivial." The code for Unwatchedpages doesn't count the number of people watching the page at all right now nor does it use an explicit order, so you would need to add the "ORDER BY" and would also need a "GROUP BY." The other issue is that the list is only updated once every week or so. Given that we get about 11,000 edits per hour on around 6000 distinct pages, "most recently edited" might as well be random as it would be out of date within a few minutes. Based on a quick and dirty estimate using the number of pages in the list right now and how far it gets alphabetically, I would estimate that there's easily 60,000 unwatched pages. At 100 at a time, with updates once a week, it'll take 11 years just to work through all the pages with 0 people watching them, ignoring all the ones that are added in that time. Mr.Z-man 18:41, 21 April 2009 (UTC) I didn't and don't endorse a broken version of a recently-edited page. Given that wgAllowPageInfo doesn't use a field in the page table, I agree that it isn't trivial. It would require adding a field and index to the page table (cf. page_random, page_len, page_touched) that kept track of watchers. What sort of disruption would the addition of this field cause? Consider where unnoticed vandalism mostly occurs. The proposal would put into view these pages (which are highly vulnerable, seldom altered, and recently altered). This would allow editors to have a central place to patrol for vandalism (see Wikipedia_talk:Special:UnwatchedPages#Purpose. It would also allow editors to find pages to watch. There's a great reason Jimbo requested the unwatched pages, and given that that method is too overwhelming, there remains a great reason to implement recent least-watched pages. –MT 23:39, 21 April 2009 (UTC) Adding new tables to the database is relatively simple. Altering existing ones is generally avoided. I believe it requires stopping replication on, altering, then re-enabling each slave server one by one, then switching the master to update that. After updating all the databases, a script would have to be run to populate the new field. The page table on enwiki currently has 16,575,280 rows, and grows constantly. I've no idea how big the watchlist table is. If this is done, it might make such a special page possible (and able to be updated dynamically). The index would also probably have to be on page_latest as well if you want to be able to sort by most recently edited. Mr.Z-man 00:08, 22 April 2009 (UTC) Not forgetting, of course, that while the database master is being updated, the whole wiki goes read-only (unless they do something wierd like setting one of the slaves to be a temporary master, which could work I guess). This is the schema update script, yes? Happy‑melon 17:05, 24 April 2009 (UTC) \ Ah, pages isn't indexed by date. How does recent changes work then? (schema, large image). Perhaps it would be more appropriate to add this sort of field there. This would also involve adding a field, but might be less dramatic. The field would list the number of people watching the page at the time the edit was made, and could be used to generate our desired list. –MT 02:40, 22 April 2009 (UTC) Since RecentChanges would otherwise need to read from about five different tables every time it was requested, it actually stores all its data in its own separate table. Every new elegible edit or action puts a copy of its log into the recentchanges table as well as whichever permanent table it uses, and ever hundredth edit calls a function to clean out rows from the table that are older than the limit (currently 30 days). Happy‑melon 17:08, 24 April 2009 (UTC) Perhaps I should amend the proposal.–MT 19:38, 25 April 2009 (UTC)

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^T 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^T 02:36, 28 April 2009 (UTC)

I guess it should be the latter... –M^T 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 it 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 ^{(Contact me,Contribs)} 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): 97.104.242.113, on 05/30/2009"

But it would be a good idea for rollback

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^T 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 ^talk 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^T 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 ^talk 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^T 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^talk 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 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^chat_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal
• 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)

History tab at the top

It would be less jargon if the history tab at the top say "authors" or "edited by". History is abstract jargon. An "authors" tab would give subtle credit to the thousands of people who have built this encyclopedia. It's a nice thing to do! User F203 (talk) 19:35, 1 May 2009 (UTC) (note, after reading the instructions, this is the proper place for discussion as developers read here according to the instructions.)

"History" is exactly what it is. It's the history of every revision that has been made to the page, and that is not jargon. While I wouldn't argue against a special page to list authors—indeed, I would welcome such a development—I think that it would be misleading to give the history tab such a title, as "authors" or "edited by" is exclusive of a significant part of the purpose of the page. {{Nihiltres|talk|log}} 01:07, 2 May 2009 (UTC)

You raise a point that I never thought of! Why not have a separate tab for a list of authors? Having a list of authors is a good idea and makes Wikipedia honest (by giving credit to people). Not recognizing authors or hiding it somewhat is intellectually dishonest. User F203 (talk) 17:32, 2 May 2009 (UTC)

History is far, far more accurate a term; just because someone has edited a page does not mean that they are an actual author of the page (such as with vandals), whereas the page does show the history of the article. EVula // talk // ☯ // 17:34, 2 May 2009 (UTC)

(ec)::An easier way for the developers is to rename the tab "history/authors". Currently, the history tab is the shortest one so lengthening it is ok. Project page, discussion, and edit this page are all far longer in length.

As far as vandals, they are blocked so fixation with vandals while forgetting to encourage good authors is short sighted.

How about renaming it "authors/history"? Or have a separate tab for authors? User F203 (talk) 17:37, 2 May 2009 (UTC)

I don't see what the benefit of an "authors" page would be, though. Each edit is different; I shouldn't get the same credit for an article just because I italicized a movie title as the editor that wrote 90% of the article. I also don't see what's so arcane about the term "history" that it would need to be changed in the first place. EVula // talk // ☯ // 17:52, 2 May 2009 (UTC)

Note that no developer action would be needed to change the name of the tab. Any admin would just have to edit MediaWiki:History short if you ever got consensus for renaming it. Anomie⚔ 18:09, 2 May 2009 (UTC)

History is correct. What is an 'author'? Someone who changes 'was' to 'were'? Someone who adds OR or uncited material? Someone who adds stuff we find to be copyvio? I'm happy to be an editor. Dougweller (talk) 18:52, 2 May 2009 (UTC)

I agree with EVula/Dougweller. A vandal wouldn't be an author, nor would the person or bot who reverted the vandalism. What about people whose edits were so long ago that what they wrote has been rewritten so many times that it no longer exists in any form in the current version of the article? Mr.Z-man 19:06, 2 May 2009 (UTC)

If not an author, how about an editor? Some textbooks have editors. Or how about "Recent editors"? Rather than just say "No", how about some ideas! User F203 (talk) 19:42, 2 May 2009 (UTC)

If there's a consensus that it's inaccurate (there doesn't seem to be), I wouldn't be adverse to "Article history". "History" is ambiguous, and adding the qualifier (something like "Page history" might work also) would seem the best route. --Izno (talk) 22:05, 2 May 2009 (UTC)

Would strongly support changing it to "page history", that should help usability quite a bit. (Edit: I see this has been done before but was reverted as it was "redundant"; which I do not agree with at all) GDonato (talk) 23:37, 2 May 2009 (UTC)

I think "revision history" would be good too as that's what it says on the actual history page. I'd prefer it to "page history" or the current "history". Cool3 (talk) 00:02, 3 May 2009 (UTC)

Though I don't see the necessity of the change, I'm willing to admit that it's due to my familiarity with the term; "page history" is more descriptive, and is still an accurate name for the tab. I'd be fine with the change. EVula // talk // ☯ // 10:21, 3 May 2009 (UTC)

Or simply Revisions? --ClickRick (talk) 11:59, 3 May 2009 (UTC)

I agree with several of the editors here. Many ideas are better than "history". History of what? Wikipedia? Roman Empire?

Better terms than history include Page history, Previous versions, Old versions/editor list, etc. One advantage to some use of the word "editors" or "authors" is if someone writes "The Pope is dead", that vandals may be quickly reverted but someone may see it. That someone thinks that a hypothetical "Wikpedia Corporation" wrote it. If we have a tab with some reference to authors or editors or article credit or versions/editor list or something else, we protect the integrity and reputation of Wikipedia in spite of any dumb things an individual editor does.

Note that the common casual reader does not know all the jargon like admin, IAR, history, ban/block, etc. This is supposed to be an encyclopedia not a geek site. User F203 (talk) 16:18, 3 May 2009 (UTC)

I don't think lumping "history" along with "IAR" as 'jargon' is an appropriate assessment. While it is ambiguous, it is not obscure or requiring insider knowledge. We cannot protect against personal stupidity: if someone is sufficiently unfamiliar with the way Wikipedia operates that they do not understand the absence of "Wikipedia Inc." despite the "history" tab appearing next to a bolded "edit this page" link, then there is precious little we can do to change that. Certainly renaming one tab is not going to miraculously enlighten them; I don't really see how you think it will. "page history" would be an appropriate clarification. Anything that tries to paint the history page as a list of contributors is, IMO, fundamentally incorrect. Happy‑melon 17:42, 3 May 2009 (UTC)

Oh come on, your "history of what" examples are ludicrous. It's in the same cluster of tabs as "edit this page" and "move". It's pretty obvious that the tab isn't there for any content-related matters. EVula // talk // ☯ // 18:26, 3 May 2009 (UTC)

By the by, German Wikipedia has "Versions/Authors", which I don't much like. "Page history" would be OK with me, but I'm not sure how much more helpful it would be. (Not sure how we could find that out, either.) Rd232 ^talk 18:29, 3 May 2009 (UTC)

You might be looking for http://wikidashboard.parc.com/ 199.125.109.77 (talk) 00:19, 4 May 2009 (UTC)

• Been bold with MediaWiki:History short since my tabs still don't go off the screen at 800x600 and I'd expect most people are higher resolution than that anyway. GDonato (talk) 13:06, 4 May 2009 (UTC)
  • Then let me be the first to raise objection. I think adding "page" is redundant (What else should it be the history of? And why not also change "edit" to "edit page", and move to "move page"?), my main objection as an editor is that it's taking far too much room. And yes, I think that the tabs should be mostly optimized for editors, not for readers, since they don't care. I could of course change it back via javascript, but would prefer just reverting the message back to how it was.
    Amalthea 13:19, 4 May 2009 (UTC)
    • On a minor note, "edit" does already say "edit this page" and as for "What else should it be the history of?": I agree but we overestimate peoples' common sense :( GDonato (talk) 13:27, 4 May 2009 (UTC)
      • See also discussion at MediaWiki talk:History short which resulted in it being shortened from page history to history... –xeno ^talk 13:30, 4 May 2009 (UTC)
        • Ah, didn't realise the longer version was the default, GDonato (talk) 13:38, 4 May 2009 (UTC)
      • Well, what do you know? Turns out I'm already using javascript to shorten the edit tab. :) Amalthea 13:42, 4 May 2009 (UTC)
  • I've reverted the change... This thread cannot reasonable be taken as "consensus" as most people probably ignored it being pretty much a dead proposal (no offense to proposer). Please make a new proposal that clearly delineates what will be done. –xeno ^talk 13:21, 4 May 2009 (UTC)

Just dropping by to also object; the tooltip explanation (and the many help pages, etc.) are sufficient. Shorter is better. Sorry. JesseW, the juggling janitor 18:04, 4 May 2009 (UTC)

There is a request to "make a new proposal that clearly delineates what will be done". I think this could be rather heavy handed. Rather than say "change to ---", I thought the current situation was not ideal and there could be improvements.

Discussion is useful. Some points brought up, I didn't know before. User F203 (talk) 19:09, 4 May 2009 (UTC)

The History tab is part of the GFDL license, and a different title would be non-compliant. Please read Wikipedia:Text_of_the_GNU_Free_Documentation_License. Even if we are dual-licensed, we need it to stay compliant. Sorry. ▫ JohnnyMrNinja 00:02, 5 May 2009 (UTC)

This is interesting, but misguided. I don't think any articles on wikipedia have a history section. The content of an article is the stuff under the title. Interpreting legal documents takes a level of expertise that cannot be verified on a wp talk page. –M^T 05:15, 5 May 2009 (UTC)

WM seems to believe that linking to a history section is compliant. We do not contain a full list of authors in the text of the article, it is in the history section of the article, which is accessed by the tab. If this does not qualify as a "section", then WM is in violation of the GFDL, so it doesn't matter what it is called. If WM is not in violation of the GFDL, then we shouldn't deliberately violate it. ▫ JohnnyMrNinja 05:35, 5 May 2009 (UTC)

So then every non-English Wikimedia project is in violation of the GFDL because they don't have the history tab as "history" in English? Mr.Z-man 15:34, 5 May 2009 (UTC)

lulz. For the English-language Wikipedia (that's where we are now, right?), any time a document (article) is modified the date and the author must be added to the "History" section. Please read the (English) GFDL and tell me if this is not correct. It is very specific about the title of every section so that they can be easily identified on any GFDL document. ▫ JohnnyMrNinja 18:04, 5 May 2009 (UTC)

Wikipedia does not have front and back covers, and this is explicitly stated. It's usually best not to raise complaints based on your own legal interpretations here at all, though if you can find a reliable source that makes exactly the point you're making, this should be acceptable. –M^T 23:40, 9 May 2009 (UTC)

Support revisions. If you're an editor, add a javascript. The default interface is for anonymous users. Shorter is not better. A number of people mistake 'history' to be yet another section of the article - a section on its history. The word 'history' should be avoided; and 'revisions' or 'old versions' is the way to go. –M^T 05:15, 5 May 2009 (UTC)

"A number of people"? How many? Seriously, I can't imagine that this is that perplexing of an issue. EVula // talk // ☯ // 05:45, 5 May 2009 (UTC)

I agree with M. Would it be possible to have it show up as "revisions" when one is not logged in, and then as "history" for logged in editors? -GTBacchus^(talk) 05:49, 5 May 2009 (UTC)

You need to pretend that you're dealing with impatient and dumb 7 year olds - not because most users are stupid, but because they don't have time to put up with poor interfaces. You're trying to find out about some country. You see discussion (which isn't even about the country, it's just a bunch of tedious arguments) and history at the top. Great, they must have split it up. But no, you're in some weird list now. From a few months ago: User:AxelBoldt/Wikipedia_usability_problems#History_tab. –M^T 08:39, 5 May 2009 (UTC)

How about "Update log"? --Philcha (talk) 17:14, 5 May 2009 (UTC)

That implies a register of changes, where each change was to bring it more up-to-date; many changes are, of course, to add information, or present existing information more clearly, irrespective of freshness. I might support a change to "Log", although I'm not convinced "History" works ineffectively. –Whitehorse1 18:10, 5 May 2009 (UTC)

Revisions has about 5 supports, 3 on this page and 2 in the linked. I think that unless a point against it comes up ("not the right word", etc.) it should be our candidate for replacing 'history'. I support replacing history, and I support replacing it with revisions. –M^T 02:31, 7 May 2009 (UTC)

Log is inappropriate; it has a similar, but distinct meaning in MediaWiki. On the other hand, the page history contains entries that are not, strictly-speaking, revisions (records of page moves, protections, etc). I don't think "revisions" is any more correct than "history"; probably less so. Happy‑melon 10:42, 7 May 2009 (UTC)

I would oppose the change on the basis that I oppose changing a very visible part of the interface based on the opinions of only 5 people. Mr.Z-man 13:50, 9 May 2009 (UTC)

This seems to be a meta-opposition :) I'm sure that a proposal like this wouldn't get passed in any case until many people (including you) have voted. Under what conditions would you approve? Do you reject any changes to the interface at all? Is this change baseless? –M^T 23:40, 9 May 2009 (UTC)

I wonder what opponents think of the variant of using three words (already done by "edit this page") added yesterday in a potentially confusing sequence of mis-edits by me. My point is that "history" is not the "wrong" word but context is the problem because there are multiple, simultaneous contexts here (a website... an encyclopedia...). So the sense in which "history" is being used is not clear unless you already know. I've suggested "page edit history" or "page revision history", not unthinkably verbose given the existing "edit this page". I've added a new section for this in the straw poll; perhaps this is of interest to those who have so far opposed. PL290 (talk) 06:51, 17 May 2009 (UTC)

History tab straw poll

"The wording of the history tab should be changed to authors"

• support –M^T 23:48, 9 May 2009 (UTC)
• oppose "authors" because in some ways the word is even less enlightening than "history", but I agree that it might be possible to find clearer word(s) than "history". How about "changes"? [See below.] —— Shakescene (talk) 19:25, 10 May 2009 (UTC)

---

"The wording of the history tab should be changed to revisions"

• support, most preferred –M^T 23:48, 9 May 2009 (UTC)
• Inclined to support but I prefer (the still-imperfect) "changes" See new proposal below. —— Shakescene (talk) 20:00, 10 May 2009 (UTC)

---

No change

• Seriously, History is the most simple and clear way to phrase this. If you don't like it, you can use javascript to change it - you should find a guide on how to do that over at the "edit" --> "+" gadget. --Philosopher ^{Let us reason together.} 13:38, 10 May 2009 (UTC)
  • (I'm sorry but that misses the entire point. Someone who can use a gadget already knows what "history" means. What's being sought is clarity for the new user, not satisfying the personal linguistic preferences of an established one.) —— Shakescene (talk) 20:00, 10 May 2009 (UTC)
    • And your comment misses my point, which is that "history" is the most simple and clear way to phrase this (for the new user). --Philosopher ^{Let us reason together.} 02:23, 13 May 2009 (UTC)
• support. My suggestion would be edit history except that that has repetition and noun/verb issues. Mark Hurd (talk) 15:10, 10 May 2009 (UTC)

noun/verb tabs are already in the ratio 3:2, so let's not argue no change on that basis. PL290 (talk) 21:31, 16 May 2009 (UTC)

Although I now see that you refer only to the noun/verb issues concerning the word "edit" within your own phrase "edit history". PL290 (talk) 21:40, 16 May 2009 (UTC)

• If it needs clarification, expand it to "page history". I haven't even see evidence that this is necessary. Happy‑melon 19:22, 10 May 2009 (UTC)
• Support - Unnecessary. Garion96 (talk) 19:28, 10 May 2009 (UTC)
• History is fine, better than proposed alternatives. 'Authors' is unrepresentative and 'revisions' is too technical for the general public and a bit boring. I find history more attractive. Cenarium (talk) 19:43, 10 May 2009 (UTC)
• Support - "History" is clear enough in the context of the interface - it's right next to "edit this page". However I could see the advantage of a short explanatory message/link at the top of the History page so that any confusion is immediately clarified for people expecting something else. (In fact, I'm a bit surprised we don't seem to have this already.) Rd232 ^talk 19:51, 10 May 2009 (UTC)
• Comment: when voting no-change, please keep in mind that this isn't for registered editors, but for those who are brand new and have never clicked 'history'. It may be appropriate to say "support, but I'd change my mind if it can be shown that 'history' is actually confusing for newcomers" or "support, they'll just have to get used to it", rather than just "support". –M^T 20:27, 10 May 2009 (UTC)

  Or you could simply assume that people commenting have read the discussion above and don't agree that a change is necessary. Garion96 (talk) 20:38, 10 May 2009 (UTC)

  I don't mean to imply they haven't. I'm just trying to encourage more feedback, rather than just support/oppose. –M^T 20:45, 10 May 2009 (UTC)

  This is why we are conducting a straw poll, not a vote. If convincing evidence suddenly comes to light that some of the reasons for the 'no change' !votes are simply invalid, then they can be discounted; it is the quality of argument that matters. No one has simply posted "support", they have presented arguments that you need to successfully dispel if you want consensus to swing towards this proposal. Happy‑melon 20:48, 10 May 2009 (UTC)

• No change is necessary. Even the few hypothetical readers who click "history" at the top of Canada and think they are getting a history of Canada will quickly be educated when they get to the next page that clearly demarcates "Revision history of..." and also has a link to Help:Page history. –xeno ^talk 18:34, 11 May 2009 (UTC)
• Oppose - Cenarium sums up my thoughts well. Mr.Z-man 02:41, 13 May 2009 (UTC)
• No change. Seriously, this is still here? There's nothing broken, so please don't fix it. — Gavia immer (talk) 03:02, 13 May 2009 (UTC)
• No change. Arguments for other labels tend to reach for reasons to change that are very minor, see Xeno above. Sswonk (talk) 04:05, 13 May 2009 (UTC)
• Mark Hurd mentions "edit history" but is worried about n/v ambiguity. Never-the-less, I support "edit history" unless enough people agree with PL290 that "page revision history" is not to long. "Editing history" comes close but doesn't improve on "edit history." Kdammers (talk) 11:25, 17 May 2009 (UTC)

Kdammers, I'm sure you'll have considered this aspect, but the "edit history" noun/verb issue is compounded by the fact that the tab is one of a group containing "edit this page" whose "edit" really is a verb. So it's not only n/v ambiguity, but also n/v clash between two tabs in close proximity that would start with the word "edit". Hence my now-soapboxed "page edit history", sharing two words with "edit this page" and thereby emphasizing its relationship with the latter . PL290 (talk) 16:41, 17 May 2009 (UTC)

• No change — I take it as part of the Wikipedia vernacular that "history" is short for "page history" or "revision history"; the short "history" has its meaning clarified by context. --User:Ceyockey (talk to me) 00:58, 21 May 2009 (UTC)
• No Change. As others have said "history" is exactly what it is, in the sense of the past of the article. It also follows current use in software, as in e.g.: Photoshop. Hairhorn (talk) 23:51, 24 May 2009 (UTC)
• Don't change anything > per Hairhorn, and just convention. It's clear what it means, and it's not broken. ╟─TreasuryTag►hemicycle─╢ 10:01, 25 May 2009 (UTC)

Yes, it's crystal clear what it means—to all of us, now we know—but per M, keep in mind that the efforts being made here are on behalf of newcomers. I suggest it's not at all clear to a newcomer what the isolated word "history" means, on a web page of an encyclopedia containing articles about world history. PL290 (talk) 12:50, 25 May 2009 (UTC)

• No change - "History" covers the meaning quite well. All tabs apply to the page, so its meaning is not ambigous. — Edokter • Talk • 17:02, 26 May 2009 (UTC)

---

"The wording of the history tab should be changed to 'page edit history' or 'page revision history'"

• Support - "History" is not the "wrong" word but context is the problem because there are multiple, simultaneous contexts here (a website, an encyclopedia...) so the sense in which "History" is being used is not clear till you know. Spell it out: "page edit history" or "page revision history" are not unthinkably verbose given "edit this page". PL290 (talk) 21:08, 16 May 2009 (UTC)

How about "editing history": would that be clear, intuitive, grammatical and accurate? —— Shakescene (talk) 23:41, 16 May 2009 (UTC)

Definitely better than "history", but still easily misinterpreted simply because of the wide range of grammatical styles in general use on websites for such things. For example, the Microsoft home page (right now, at least) has a left navigation bar item called "Using your computer", and "editing history" could easily be misconstrued as being a source of information about how to edit the history (whatever "history" might be)—or even the means to commence that activity. Whereas, "page revision history" disambiguates, both grammatically and contextually. If desperate to save another 4 characters, "page edit history" would be an alternative, and perhaps I like it even more since it contains both the word "edit" and the word "page", giving a stronger relationship with "edit this page". PL290 (talk) 06:51, 17 May 2009 (UTC)

Sorry for the lack of response, but I don't think anyone is taking this poll or discussion seriously at this point. This proposal will likely never go through for the reason that while the number of support v. oppose may be equal (which I highly doubt is the case), the people who are inclined to support will not all like the same word(s). But in all honesty, history is the best name, any confused people will figure it out, this isn't Simple English WP, let's drop this now? ▫ JohnnyMrNinja 17:46, 17 May 2009 (UTC)

---

"The name of the history tab should be changed to 'previous changes', 'previous revisions' or 'previous edits'" [new choice, May 20]

Propose: If a new user sees "edit this page", then the purpose and nature of an adjacent tab reading "previous edits", "previous revisions" or "previous changes" should be intuitively clear and unambiguous. —— Shakescene (talk) 03:36, 21 May 2009 (UTC)

Support: any of "previous changes", "previous revisions" and "previous edits" would be an improvement, but most especially "previous edits" which, by containing "edit", establishes the tab's relationship to the "edit this page" tab, which, IMO, is the whole point. PL290 (talk) 08:05, 21 May 2009 (UTC)

---

"Change both 'edit this page' and 'history', to 'edit article' and 'article history' respectively" [new choice, May 25]

Propose: Citing an earlier point, "history" on its own is not the wrong word, but context is the problem: there are multiple, simultaneous contexts here (a website, an encyclopedia containing articles about world history... an editable article), so the sense in which "history" is being used isn't clear. PL290 (talk) 09:45, 25 May 2009 (UTC)

---

End of the line

Comment: this straw poll has a confusing structure that doesn't allow simple tabulation. I am seeing something near 13 poll voters asking for no change and ~5 poll voters asking for something else. Since the poll has been conducted for over two weeks, I think it is safe to conclude that those numbers clearly point to a consensus against any change. The tooltip of the tab link and content of the history page make it very clear to even a first time viewer what the page is about, and unless there is substantial argument against I think reasonable editors will all agree that no change is mandated by votes or consensus at this time. Comments can certainly be added to the thread, but in my view this part, the "History tab straw poll", has reached the end of the line. Sswonk (talk) 14:29, 25 May 2009 (UTC)

This straw poll is as good as dead. It was initially intended to be a way to decide on a good alternative to propose, not as a vote on the issue. Most of the people voting have no evidence that this does or does not affect new users. We should have voted on whether or not the preferences of established users should be considered (they should not), gone from there to figuring out if crappy terminology on our part makes editing difficult (it does - see the usability study), and finally implemented whatever solution was best. Instead we're asking users who would be entirely unaffected if we called the tab "kl;rc", and might even prefer that, since it's shorter.   M  18:05, 25 May 2009 (UTC)

Disabling "create a book"

Per the early results of the usability study (ctrl-f "Creating a New Article") and the reported "mess" [2] [3] at CSD that is the result of this usability issue, I propose we disable this additional section, until a more usable alternative is created/proposed. —TheDJ (talk • contribs) 20:41, 6 May 2009 (UTC)

Have a look at User:Zetawoof/BadBooks also. I've been going through these for a while. It's full of crap. Good stuff too, yes, but mostly crap. DS (talk) 20:43, 6 May 2009 (UTC)

I fully agree with you. Our "books" section has nothing to do with building an encyclopedia and everything to do with financial gain. The section is totally divorced from the mission of building a better encyclopedia and only commited to selling the better encyclopedia; selling free content. This was ill thought-out and poorly implemented from the top-down with little to no opinion from the community whether we wanted this feature and whether we support the Wikimedia-PediaPress financial partnership. Wikipedia isn't a vehicle for advertising, neither from its users or its parent corporation. The resulting mess of this uncoordinated and poorly thought out plan to make a quick buck is a total shame to the mission of building a neutral, verifiable encyclopedia. As a user-built encyclopedia we have the final say in this matter and I think there's sufficient evidence to show that the "create a book" feature, the "books" namespace, and the thinly disguised marketing propaganda that goes with it have no place here. ThemFromSpace 22:31, 6 May 2009 (UTC)

This is not about the books functionality, it is about the placement of some of the Books tools. —TheDJ (talk • contribs) 23:51, 6 May 2009 (UTC)

I might support temporarily disabling the feature for usability reasons, but strongly disagree with the anti-corporatism of Themfromspace - the feature provides downloadable PDFs for free, and printing articles is critical for getting them into the hands of people without Internet access. But let's not polarize this discussion and stick to the issues. Dcoetzee 23:08, 6 May 2009 (UTC)

Mmm. I've nothing against the PDF-creation thing per se, but the implementation we have of it just now does seem to be actively counterproductive in a way we didn't anticipate. Shimgray | talk | 23:13, 6 May 2009 (UTC)

I love the PDF generation myself. That link (which is in the toolbox and not in the "create a book" section. can stay as far as I am concerned. —TheDJ (talk • contribs) 23:51, 6 May 2009 (UTC)

If you're taking about the "Add wiki page" link, it's already been changed to "Add page to book" in SVN. --brion (talk) 23:52, 6 May 2009 (UTC)

As far as I am concerned, we are talking about the entire "p-coll-create_a_book". It's a lot of extra material with little gain to a small set of users, and confusing to a large group of users to boot. Like has been suggested before, It's better as a Gadget or something. I don't believe the group of users that is affected by this problem is gonna be helped with "Add page to book", I have doubt in their ability to differentiate between Wikipedia and "a book", they might think wikipedia IS a type of book. —TheDJ (talk • contribs) 00:02, 7 May 2009 (UTC)

I honestly have no clue what the hell the "create a book" stuff did. It got rolled out while I was on a wikibreak, near as I can tell. EVula // talk // ☯ // 03:22, 7 May 2009 (UTC)

Support. Let's not pollute the sidebar beyond the mess that it already is. This needs to be thrown into special pages. –M^T 03:33, 7 May 2009 (UTC)

Pretty much the first thing I did after seeing this development was to hide it in my CSS. I love the functionality to generate PDFs of articles. I support having the functionality available, and I'm neutral about WMF and other companies profiting from it. I see absolutely no reason why it needs to be flashed in the sidebar for every logged-in user. If people want to access Special:Book, let them either know where to look for it, or to find it through an appropriate introductory page (Wikipedia:Books or Help:Books) that explains what the hell this confusing feature is and how to use it properly. Happy‑melon 10:49, 7 May 2009 (UTC)

Yes, please. The list I created, which currently contains only books which contain less than two articles, or which contain only project-space pages, currently encompasses over a thousand books. This amounts for well over 50% of all created books — it's clear that a lot of users are misunderstanding what the Books feature is for. One or more of the following things needs to happen:

• The Book sidebar needs to be either deemphasized heavily, or hidden until users start the process of creating a book by explicitly visiting Special:Book. As the usability study noted, the current verbiage suggests that this is the correct process to create a new page with. Either it needs to be made even clearer how pages are created, or this feature needs to be toned down a lot.
• The "Books" feature should be renamed back to its internal name of "Collections". A lot of users are ending up under the impression that the Books feature is used to write books, and appear to become confused when adding chapters doesn't give them any way to edit those chapters (because, of course, that isn't how the books feature works). A link to Wikibooks ("If you're trying to write a new book, go here instead") wouldn't be out of place either.
• Logged-out users should not be prompted to create an account to save books. The PediaPress integration can still function correctly without saving a book, so there's no need to invite a user to save a book which (in all likelihood) won't be useful to us.
• As I've mentioned elsewhere, it's much harder (in terms of process) for us to delete a "junk" book in userspace than it is for a user to drop by and create one. This should probably be rectified.

Zetawoof_(ζ) 11:03, 7 May 2009 (UTC)

I think part of the reason for the bad usability is that we've always made it relatively difficult to create new articles. This is purported to serve a purpose, like avoiding orphaned pages, but I think it's counterproductive. Why not just have a "Create a new article" link in the sidebar? For the books feature, I'd suggest a wording like "Combine articles into a book." Dcoetzee 11:41, 7 May 2009 (UTC)

Did you see the part above where I said it's already been changed? Thanks. --brion (talk) 16:33, 7 May 2009 (UTC)

I like the idea of renaming it "Collections". Seems much more accurate and helpful. Rd232 ^talk 03:49, 8 May 2009 (UTC)

• We have *waisted* thousands of hours of volunteer's time for the maintenance of this system, for very little benefit to Wikipedia. I think we definitely need some additional restrictive measures, for example:

• Users who are not autoconfirmed are not allowed to store books in project space through Special:Book, I think we should also apply this for userspace. There's no benefit in allowing inexperienced users to create books in userspace, the vast majority of books created by them are tests or inappropriate (including a vast amount of blpvios and copyvios).
• Do not allow to create a book with only one page. Cenarium (talk) 13:44, 9 May 2009 (UTC)

So it is a problem

OK, I see that a significant amount of people share the same feeling here. Now to do something constructive. The question becomes what... If we disable this element in CSS, than basically the whole books functionality ceases to function. That is a rather drastic and dramatic move that I would rather try to avoid. I propose therefore we request the following changes to the devs:

1. The books/collections sidebar becomes disabled by default
2. A link is added to the toolbox (alla Cite this page) to Special:Books
3. When you visit Special:Books, you can ENABLE the sidebar for books (would be ideal trough a persistent preference option, but otherwise can be done with JS and a cookie).

This would make this entire functionality much more lean and mean in my opinion. I will post a request in bugzilla for these changes to be implemented. If this takes to long, then we can request the extension be disabled, or we ourselves change the CSS to hide the books sidebar, until this functionality is implemented. I think this would significantly avoid many of the problems we discussed above. A good idea? —TheDJ (talk • contribs) 20:05, 9 May 2009 (UTC)

• Support turning off the sidebar. Already in special pages, is poorly understood, and causes too much needless work. Also support turning it back on again, but this is much less important –M^T 01:11, 10 May 2009 (UTC)
• Support This way it won't utterly confuse readers and inexperienced users. Anonymous and logged-in users can choose to enable it for the session. For logged-in users, we could also have an option in preferences (or even accessible from Special:Book) to enable it indefinitely. Cenarium (talk) 19:17, 10 May 2009 (UTC)
• Support... all we really need is for an extra class to be added to the books sidebar when the user actually has books in their collection. That way, we can trivially hide the toolbar until a user activates the system through Special:Book directly. The preference option should also be added - should be easier with the new preferences - documented at Special:Book as you say. We can add the toolbox link ourselves. I also think we should hide the toolbox for the time being; that would put huge pressure on Pediapress to implement the requested features with urgency. Happy‑melon 19:36, 10 May 2009 (UTC)

• I filed bugzilla:18756. Tomorrow I will set the CSS to hide the sidebar. —TheDJ (talk • contribs) 23:20, 10 May 2009 (UTC)

I've been hiding the books sidebar for a while using javascript User:M/monobook.js - might save you some time. –M^T 23:29, 10 May 2009 (UTC)

• Oppose - instead I propose to collect and discuss ideas how the usability could be increased and implement them. Regarding above issues:
  • The confusion found during the usability study was fixed by Brion who altered the label (see above)
  • Stored books can only be created by autoconfirmed users for some time now (as a result of the CSD discussions linked at the top of this thread).

I don't see the requirement for any expeditious actions. We don't shutdown Wikipedia because it currently misses add/delete-page buttons (which seems to be the problem in the first place with above issues), do we? --He!ko (talk) 13:04, 11 May 2009 (UTC)

Please note that He!ko is managing director of Pediapress (ref) and has made no or few edits outside this topic. Cenarium (talk) 15:08, 11 May 2009 (UTC)

Please note that our concerns are not limited to the "label" of the one option, as stated above. The usability study, simply confirmed ONE of the concerns that several editors have had since the extension was enabled. I have felt a growing annoyance of this extra sidebar among the editors. We see a problem, and we want to fix it. I appreciate the work that you and your company have done for this extension Heiko, but for the English Wikipedia, it is "Yet Another (non-critical) Function", and to boot one that rather suddenly appeared in our sidebox. Our standards as editors are high, and increasingly more so. If people don't want to wait a month for this to be fixed, but rather act now, then we can surely consider this. (Note that we are also discussing a new link for users to create articles, as well as pondering about ideas to work on the Search results page from our side. All points that have come out of the usability study. —TheDJ (talk • contribs) 18:47, 11 May 2009 (UTC)

Disabling the little toolbox if you find it annoying is already trivial, and creating a gadget to do so would make it even easier. As per the below, I'm in favor of exploring an alternative UI, but you're arguing for disabling the feature entirely until certain conditions are met, which, given the actual scope of the problems, seems like a strong overreaction -- especially considering how many useful books have already been created using this feature.

What I'm suggesting is that we try to develop a consensus on the UI and book creation workflow before there's a roll-out to logged out users; I assume there wouldn't be any problem rolling out the "PDF version" link to all users at this time.--Eloquence* 01:43, 12 May 2009 (UTC)

• Oppose. To recap:

1. The label "Add wiki page" has already been renamed in SVN to "Add page to book" as a result of the user testing.
2. Books-created in user space are automatically tagged with noindex to exclude them from search engines
3. Books can only be created in Wikipedia: space by autoconfirmed users.
4. The discussion regarding CSD does not indicate that everyone actually feels that test books in user space are a problem: some people do, some people don't.
5. Hundreds of useful books have been created using this feature: clearly it is something that users want to be able to experiment with.

It doesn't therefore seem reasonable to me to want to disable the feature right now, based on a small discussion with a handful of people. That being said, I'm in favor of having a constructive conversation about the usability and workflow of the book feature. I propose targeting the following functional changes:

1. Have an explicitly toggled "Create a book" mode which, once activated, can be as prominent in the UI as it needs to be, and which is activated with a single link in the sidebar. (This is similar to the suggestion above, except that it wouldn't require an additional page visit.) That would save the space in the navigation bar currently occupied by the book-box, which may not be of interest to many users. (It's currently only shown to logged in users anyway.)
2. Add an "internal save" function which doesn't create pages. Deprecate the current user-space book feature.
3. Continue to allow sharing in the Wikipedia: namespace for autoconfirmed users.

The disadvantage of this approach is that it would deprive us of useful books created by new users. In the longer term, we could have a "Submit for review" feature, or some other form of semi-public sharing which doesn't create pages, to allow new/anonymous users to submit their book suggestions.

These are changes we can target over the coming weeks, but I don't see any emergency that would require the feature to be immediately disabled.--Eloquence* 18:24, 11 May 2009 (UTC)

Zetawoof mentions that this feature has caused over 1000 junk books to be created, well over 50% of books. How is cleanup being handled? What process was used to establish a need to add that sidebar to the Wikipedia interface?   M  01:21, 13 May 2009 (UTC)

I've suggested a path going forward above. As regards what has happened so far, I simply disagree that what you're describing is a problem. We're talking about pages in userspace that are already automatically tagged with no-index. They're not in the normal path of a reader's Wikipedia experience. If you feel compelled to clean them up, you're free to do so, but nobody forces you to do it, and it doesn't present a significant advantage to Wikipedia's utility to do it. I acknowledge the argument that a different type of save operation that doesn't create perceived clutter is desirable: hence my suggestion for an internal save feature. But let's not overstate something that's a minor nuisance at worst, while completely omitting the actual utility and value of the functionality we're talking about.--Eloquence* 01:45, 13 May 2009 (UTC)

The fact that only pediapress and the foundation are defending this sidebar so far, does say something however. I have not yet removed the sidebar, partly, because doing so would cause our 30 day cache for CSS to hamper our ability to instantly reinstate it. If we don't have to wait months for this to be fixed, then we can probably live with it for a while longer. —TheDJ (talk • contribs) 02:14, 13 May 2009 (UTC)

It's probably well over 50%, actually. The 1000/50% figure is just counting books which can be automatically identified as lacking content - there are probably a lot more test books that manage to squeak above the barrier (by, for instance, including two random articles) but which still don't have any useful content. Zetawoof_(ζ) 21:45, 13 May 2009 (UTC)

The only reason those pages are noindexed is because I added the noindex template to {{saved book}}, due to the relatively high number of spam, blpvios and copyvios this system generates, but users generally remove content while editing the "book", and can very well remove the template {{saved book}} or the category, thus the page is no longer noindexed or traceable. The only way to reliably track those pages would be to parse the database for user pages containing the string /books/... So again, more work for us (we ought not to let that kind of pages hang around). Test pages in userspace are generally allowed, so test books are not the major problem, it's when they are edited to become something else. Aside from inappropriate pages, maybe even worse happens: we loose potential articles here (I also modified {{saved book}} to try to direct new users to the introduction to editing, but quite inefficient, as some users do it several times).

Changing 'add wiki page" to "add page to book" will not solve the usability problem. Most users will still believe that's just a funny way to say create a new article, or just don't get what is meant. The term book in this sense is very unnatural. Of course, some 'useful' books have been created, when you have a new tool, you want to experiment it. But we've got more problems than positive results so far; this effect to confuse users is dramatic, it can only diminish the chances for them to edit articles or successfully create ones. Not at a single point in the process, it is explained how it works, just a link to the help page is given, and as usual, only a few will click it.

To be more successful, you need to give a good explanation of the feature to users before letting them play with it. So you'd need to link to Special:Book, in a toggle named to something like "make a collection of articles"; as "create a book" would only confuse users. But simply activating the interface on one click would still cause the same problems, you need to explain the feature beforehand at Special:Book, than let it be activated. An internal save may be better in some regards, but we have to consider the server resources it will take, and what other components will suffer from it. We already regularly have watchlist or log lags, most serious recent example here, I'd prefer not to put a new strain on the servers for that. In the mean time, the right course of action seems to deactivate this non-critical feature, until the usability problems are solved. I don't see why we should give high priority to a feature that would be used by probably less than 1 out of 10.000 users, which introduces right now usability problems affecting many more; while we have in parallel software requests on which the community finally agreed upon, aimed to address critical issues for which the WMF said to be firmly engaged, that are visibly given lower priority. Cenarium (talk) 23:28, 13 May 2009 (UTC)

• Support turning off the sidebar. Hopefully later we can have a centralized discussion on the books feature as a whole, but anything done to keep this as separate from the rest of Wikipedia as possible is a plus. As of now, since what is written in the books may not correspond to our policies and guidelines its presense in the toolbar is deceptive. ThemFromSpace 02:27, 13 May 2009 (UTC)

• I have a little experience here, I was aware of this project, and I think it a good one. Yet the implementation confused me. I have relieved to find that others feel similarly. "Create a book" does not by itself have a very obvious meaning--this needs to be done properly. It should be immediately disabled until it can be implemented in a tested manner. DGG (talk) 06:07, 13 May 2009 (UTC)

• So currently the proposal (to hide the "create a book" sidebar box with CSS for the time being, until the feature can be reimplemented in a more user-friendly and less disruptive manner) has the support of six editors and opposition from the managing director of PediaPress and the Foundation's Deputy Director (both in their capacity as editors, AFAIK). I'm going to spam this discussion elsewhere for more input. Happy‑melon 17:21, 13 May 2009 (UTC)

• Support. Really, really bad idea, and if for some reason the opposition picks up strength, I'll go into detail. - Dank (push to talk) 17:31, 13 May 2009 (UTC)
• Support turning off the side bar. Frankly, I don't see the point of the function at all, but at the very least it shouldn't be in a side bar. The WP definition of book is not the same as the normal definition so having a "create a book" link is bound to lead to massively confusion (and has.) --ThaddeusB (talk) 17:38, 13 May 2009 (UTC)
• Support removing the sidebar. There needs to be more discussion on books, including specific style, guidelines, policies, etc. I don't think most users even know what they are. hmwithτ 18:00, 13 May 2009 (UTC)
• Oppose per arguments above. Griffinofwales (talk) 18:13, 13 May 2009 (UTC)
• I'm still interested in knowing more about how this feature was implemented, and how we managed to miss that this would be a problem for users and editors. (Incidentally, I turned this back on in my .js, and the first thing I did was accidentally 'add a page to book'. I expected some sort of complicated submission/confirmation page, like much of the rest of the wikipedia interface.)   M  18:16, 13 May 2009 (UTC)
• Support - Unlike the simple PDF download link, the "Book" feature seems rather poorly executed and is of only marginal utility on Wikipedia. I'm not convinced that it warrants a spot in the sidebar. There needs to be a lot more documentation on how the system works. Looking at a random sample of 15 books in userspace, all but 3 seemed to be either test pages or spam. Hundreds of books have been created, how useful any of them are is questionable. Changing the label is not going to magically fix all the confusion. Just because they won't show up on external search results is no reason to allow userspace to be an unmonitored dumping ground for spam and other garbage - WP:NOT#WEBHOST still applies. Mr.Z-man 18:27, 13 May 2009 (UTC)

  "Hundreds of books"? Thousands, actually. There are around 2200 pages transcluding {{saved book}} right now, plus a bunch more which have already been deleted. Zetawoof_(ζ) 21:45, 13 May 2009 (UTC)

• Support per above. --Kbdank71 19:06, 13 May 2009 (UTC)
• Support, per my comments above and elsewhere. There might be a good idea in the Books system, but the current implementation is incredibly confusing and practically invites misuse. Zetawoof_(ζ) 21:45, 13 May 2009 (UTC)
• Support We need to better think how to use this tool to help build an encyclopedia and not just throw it out there without any guidance. Chillum 01:39, 14 May 2009 (UTC)
• Support, I'm sure that there's a use for this tool, but as alluded to above, it hasn't actually been discovered yet. Lets have a think about how the Books tool can be used, and if a good reason is brought up, then we can add it back in at a later date. Lankiveil ^{(speak to me)} 08:40, 14 May 2009 (UTC).

This consensus seems indisputable to me. I have therefore hidden the sidebar box. Now we can start to think about what actually needs to be done before we're willing to reenable the feature. I think it's fair to say that the PediaPress tech team will give whatever we request their full attention :D </evil laugh> Happy‑melon 09:08, 14 May 2009 (UTC)

I have added caution banners to related pages. —TheDJ (talk • contribs) 12:46, 14 May 2009 (UTC)

I'm coming in rather late to this but I'd like to add my request. For our private wiki, we'd really like the PDF functionality, don't want the book functionality. I saw several people above expressing similar sentiments. Can we not have a PDF only version for Wikipedia? --Robinson weijman (talk) 19:56, 14 May 2009 (UTC)

• I'm coming in late, too, but I support the hiding of this tool in the sidebar. It was sprung on us without any real discussion (so fast that the Userpage was deleted as a G11 when it was first created) and the function is poorly understood. Protonk (talk) 21:16, 14 May 2009 (UTC)

Moving forward

Ok, so we have hidden the sidebar, and now have some breathing-space. How do we proceed? What needs to change? How does the feature need to be improved? End straw poll, start new discussion.

I for one think that TheDJ is on the right track with saying the feature should have to be 'activated' through Special:Book before appearing in the sidebar. I also second Robinson weijman's request above to separate the per-page PDF renderer from the book interface proper. Thoughts? Happy‑melon 21:23, 14 May 2009 (UTC)

Agree with the PDF point. We could use a brief explanation in this section about how the books feature currently works. (Incidentally, does it track by the revision? Because I don't want to see vandalism in a 700 page tome, nor do I want to 'pre-review' it, since this is presumably what I was doing right before I clicked 'add'.) I think that the only time you need to add a page to a book is after you're aware of what a book is, so it should be initially disabled, and possible to enable in prefs (like every other feature) or via a link from its wp page. I think that this was the main concern, and that most people agree on this. A separate issue is how prominent the feature itself should be in the interface. Should we have a link to WP:BOOKS (err-that's not it, what's its wp page?) on every Wikipedia page? I think that the toolbox could use a link to prefs/gadgets, though overall I think the sidebar needs to be substantially reduced. The idea here is that if we moved a few of the gadgets to more prominent locations, we'd see more misuse, since only the more experienced editors tend to find their way into prefs. How much experience is needed to use this feature?   M  22:42, 14 May 2009 (UTC)

I believe in the "release early, release often" principle. So release the PDF version now (since there is little problem with this) and then we can consider what to do with the books. That way, if we do include books, the quality of those books will be better because we'll be doing bug fixing up until that point. And if we don't include books, it'd be a shame to have wasted time discussion the pros and cons of books when people could have used the PDF functionality in the meantime. Let's release PDF now. --Robinson weijman (talk) 14:16, 15 May 2009 (UTC)

Have people lost interest in this? It's been days since anyone has commented here. Release the PDF only version now! --Robinson weijman (talk) 05:48, 19 May 2009 (UTC)

C'mon people - let's make a decision, please. Any objections to PDF only? --Robinson weijman (talk) 05:36, 20 May 2009 (UTC)

It seems reasonable to allow people to make and download PDFs. Leaving cruft in the project namespace or userspace, especially when it's mostly test pages, seems bad. Stifle (talk) 11:58, 20 May 2009 (UTC)

Oh, it seems I've been misunderstanding. I thought what was suggested was to implement the "PDF version" link separately to the whole Collections functionality, so the per-page renderer could be enabled while Special:Book was disabled in software. But actually you want to be able to create collections on Special:Book, and render/download them, but not be able to save them on-wiki? I can see the merit of this approach: ultimately, do we care how many books PediaPress print? No, the only issues are accessibility/usability, and repercussions on-wiki with the buildup of random crappy books. So step 1: ask that the extension be altered to allow saving of books be restricted to arbitrary groups, and request that no such groups be assigned for enwiki. Sensible? Happy‑melon 13:19, 20 May 2009 (UTC)

I would prefer if any registered user were able to save a book (collection) temporary on a pseudo-page (in special: namespase). This page could then expire after some time. This would solve the problem of "crappy" books, while allowing users to have saved versions of their collections, so that they could modify them later (before expiration). Ruslik (talk) 13:37, 20 May 2009 (UTC)

I didn't even know you could save wiki books (whatever that is) on Wikipedia. I just want to be able to download a PDF of a page, a selection of pages or a whole category, as was possible in the book software. And I'd like this as an extension I can download for my own wiki (or included in core MediaWiki code). --Robinson weijman (talk) 19:13, 20 May 2009 (UTC)

I think that is a tad beyond the scope of this discussion. If you want stuff for you own wiki, you are welcome to ask their developers this, or do it yourself of course, but it should not be part of this discussion. —TheDJ (talk • contribs) 20:44, 20 May 2009 (UTC)

Fair point - that's what I meant with "And..." So, I would like PDF downloads for Wikipedia and then I would use it for my own wiki. --Robinson weijman (talk) 20:51, 20 May 2009 (UTC)

Ruslik's got a point. Having books saved as normal page text is the fundamental problem. Let's be honest, does anyone actually think that we're ever going to say "look, readers, at this collection of books we've created for your delectation"?? That sounds like Wikibooks to me. The Collection extension is for personal use, IMO, it's for users to create books that are useful to them. Or is that just my opinion? Thoughts? Happy‑melon 09:24, 22 May 2009 (UTC)

Probably, but on the other hand, it shouldn't be IMPOSSIBLE to share a 'book' either I guess. —TheDJ (talk • contribs) 10:32, 22 May 2009 (UTC)

Can someone please explain why we are talking about books now? Can we not first agree to get PDF functionality running, try that for three months, and then if all goes well restart the book discussion? Why is there a need to release these together? --Robinson weijman (talk) 19:07, 22 May 2009 (UTC)

Now I'm really confused. What do you mean when you say "PDF function"? Do you mean "click a link to view a PDF version of a single page"? If so, this is already available (and active) on enwiki, appearing in the toolbox underneath "permanent link". We've agreed that the software should be modified so that this feature can be made available separately to Special:Book. Or do you mean "construct a list of pages and be able to view a PDF version of the whole ensemble"?? That is a book; the question we're discussing is whether you should be able to 'save' that ensemble and come back to it later, or if it should be discarded when you navigate away from Special:Book. Happy‑melon 15:38, 23 May 2009 (UTC)

I mean the current book PDF functionality: that I can make a PDF from one or more pages, or from a whole category (or any combination). Thanks for the info on single PDF pages - I did not know that. --Robinson weijman (talk) 05:53, 24 May 2009 (UTC)

Then why the heck is the entire Book feature turned off instead of only the Save function? I just want to create a book and save it to my local drive. If the issue is wiki drive space and abandoned books, etc. this should not have stopped my ability to actually make a book for myself to save as a PDF on my own hard drive. Turn off the Save feature, turn the Book feature back on and then continue the discussion... Davealexander (talk) 16:00, 24 May 2009 (UTC)

Because that is not possible with the software as it is currently written. When we have a consensus on what needs to be done, we will get the developers to implement it. The extension is supported by PediaPress, who have quite a strong incentive to get it back up as quickly as possible, but it's not fair to them to bend over backwards to accomodate us when we haven't even decided what we want done. Happy‑melon 17:26, 24 May 2009 (UTC)

Good point, but I think a consensus is emerging. PDF save to hard drive now (how many times have I said this?!) is something everyone agrees on. So let's release this now. Sigh. Sorry to be a pain but I really am quite tired of this endless conversation. --Robinson weijman (talk) 17:42, 24 May 2009 (UTC)

I think you're right, on this aspect at least. Template:Bug Happy‑melon 17:58, 24 May 2009 (UTC)

So, how can we address the title of "Moving forward"? That is - what next? --Robinson weijman (talk) 14:56, 25 May 2009 (UTC)

Well, we wait until that bug is resolved. If PediaPress want any clickthroughs from us, they'll do it PDQ. Now, when they've made the change I requested, we will be able to assign the right to 'save books to the wiki' to an arbitrary usergroup, if any. We should have a consensus by that point about who, if anyone, should have this permission. Personally, I don't think it's at all useful (books look like this when saved on-wiki), and should be left totally disabled. But that's just MHO; what do others think? Happy‑melon 15:16, 25 May 2009 (UTC)

I don't see too much harm. These seem like... mini-categories or portals? I do think that they might help for organizing certain topics. It would be nice to see some progress here. At the very least they could release a gadget that people could enable to turn things back on using js.   M  17:50, 25 May 2009 (UTC)

We can disable saving in the user namespace altogether, and allow it in the project: namespace for autoconfirmed users. That should limit shared books to stuff created by bona fide community members.--Eloquence* 19:41, 27 May 2009 (UTC)

A bit off-topic, but relevant to the PediaPress issue is that Render PDF and Preview/Order a Book produce two VERY different items. The PDF rendering is extremely inferior to the PediaPress rendering. The PDF rendering does not give true paragraph break lines; the paragraphs sort of run together and look like a solid page of words. The PediaPress Book setting gives you a full and complete Table of Contents AND an auto-generated Index while PDF does not. Why the difference? Just because I want to print it on my desktop printer instead of pay PediaPress I get an inferior file? I think the rendering of a PDF should be the same for both methods.Davealexander (talk) 19:36, 25 May 2009 (UTC)

That's something you'll need to add to the bugzilla. Stifle (talk) 14:53, 28 May 2009 (UTC)

I'm not convinced that this is the case: the results from clicking the "PDF version" for a random article, verses creating a book with that article and then rendering it, seem identical to me. Can you show some specific examples? Happy‑melon 15:36, 28 May 2009 (UTC)

You can see the differences at a web page I made -- http://www.transactual.com/bookvspdf.html I think the real issue I am trying to raise is this: Am I correct in assuming (and I am assuming here) that PediaPress created both the PDF rendering and Book rendering modules and disabled some of the features for the standard PDF rendering so that if you want an index or table of contents (or prettier fonts or nicer spacing or footnotes at the bottom of each page instead of crammed at the end -- and there are a lot more examples of how these two documents differ) you have to buy their physical book? That's how it appears to me. You cannot save their book rendering to your local drive. All you can do is preview it -- and then purchase it.Davealexander (talk) 02:57, 29 May 2009 (UTC)

I have to say I'm not seeing them. The collection renderer doesn't generate a book ToC or index when the book has only one page either. I think it's the same engine, it would be silly for them to have written two separate renderers for the same task. And you can download and save the collection render in exacly the same way as the per-page view: it's even served from the same directory system. The real test is to compare a per-page view with a collection render for a collection that only contains that same one page; when I did that, I couldn't distinguish between the two PDFs. Happy‑melon 10:15, 29 May 2009 (UTC)

The pages I showed on the web page were from the collection render and the PDF render, both from a collection with 23 pages. The PDF collection render did not generate an index or TOC while the book render did. I think it's silly, too. But they are doing it.Davealexander (talk) 23:58, 29 May 2009 (UTC)

Note that you can still render or order printouts of books already created; you just can't create new books at the moment. Stifle (talk) 14:53, 28 May 2009 (UTC)

I can still create, render, save and send books to be printed from my user page. You just can't do it when you're not logged in and it's gone from the left nav boxes.Davealexander (talk) 02:40, 29 May 2009 (UTC)

Suggestions for the Go/Search box

The as-you-type feedback in the Go/Search box may be the greatest improvement to the WP interface in years. Here are some suggestions to make it more useful to WP editors:

1. Make the displayed list a bit longer, say 20 entries instead of 10.
2. On my Firefox browser, the feedback pop-up only shows 7 of the 10 lines; I must scroll to see the other 3. I couldn't figure out how to change its size. So, if that is under WP control, please make the feedback popup window taller. If space is the issue, consider moving the Go/Search box further up.
3. To help editors, please distinguish real articles from redirects in the feedback list (e.g. by italic, bold, color, or a '#' suffix.) Better yet, show the target of redirects, e.g.
   natrium
     → sodium
   This feature could be a user profile option, and/or enabled only while editing an article.
4. Provide somehow a way to pick one of the feedback lines and paste it into the edit window, with [[..]] markup, instead of jumping to that page.

All the best, --Jorge Stolfi (talk) 07:47, 17 May 2009 (UTC)

I will agree that the current MWsuggest feature is rather primitive. As for your points:

1. This would increase server load. But, of course, there's WP:DWAP.
2. The search portlet panel is not going to be moved, I believe, judging by earlier discussions. The rationale behind the choice of its height is mysterious.
3. Redirects should be italicised, like at Special:AllPages. Showing of the target would be cool, but what about things like Thick-film dialectric electroluminescent technology → Thick-film dielectric electroluminescent technology?
4. Why?

— This, that, and the other [talk] 07:57, 23 May 2009 (UTC)

If you want to edit the search box, make more results, ect, why not just make a userscript? If you want to publcize it, you can put it in Wikipedia's user script gallery. ⊕Assasin Joe ^talk 22:42, 26 May 2009 (UTC)

4. Why? Because usually when I find an entry there I would like to open it in a new tab. I have my browser (Firefox 3.0.10 on Windows/XP) set up to open links in a new tab when I right-click, but that doesn't work with this drop-down list. Copying the link to the clipboard would be a second-best choice to enable me to do this. Phil Bridger (talk) 20:12, 28 May 2009 (UTC)

Suggestion for wikilink syntax: trimming the article name

There are many articles with qualified names, such as "English language" or "pipe (computer science)". To link to those articles within normal text, one must usually type the first part of the name twice, e.g. [[pipe (computer science)|pipe]]. So, why not provide wikilink syntax to display only a prefix of the article's full name, e.g. [[Pipe|| (computer science)]] or [[pipe[ (computer science)]]]. The last form could be extended to allow replacement of middle parts, e.g. [[Pierre [Edouard Leopold|E. L.] Verger]] that links to "Pierre Edouard Leopold Verger" but displays as "Pierre E. L. Verger".
All the best, --Jorge Stolfi (talk) 08:16, 17 May 2009 (UTC)

Did you know that you can just type [[pipe (computer science)|]] and it automatically converts to [[pipe (computer science)|pipe]], without you having to type anything twice? That appears to be what you're looking for. ╟─TreasuryTag►contribs─╢ 08:27, 17 May 2009 (UTC)

• <dumbfounded>Oh.</dumbfounded> --Jorge Stolfi (talk) 16:34, 17 May 2009 (UTC)

Just for future reference, it is called the Pipe trick. Mark Hurd (talk) 05:18, 22 May 2009 (UTC)

You know, I proposed this also when I was a newbie. Maybe it needs to be publicised better. — This, that, and the other [talk] 08:13, 23 May 2009 (UTC)

Central bibliography

Let's consider this in isolation from any implementation details. The vision of Wikipedia is to provide free access to the sum of all human knowledge. Human knowledge includes knowledge of published works. Wikipedia contains, embedded within article text, a large number of definitions of published works. The question then seems to be: once published work knowledge has been accumulated in this way,

• does Wikipedia provide sufficient user access to the sum of that knowledge, and
• does Wikipedia provide sufficient internal access to that knowledge, by allowing reference to it from inline citations in multiple articles?

From a current discussion on a certain proposed implementation, it appears the answer is no.

---

I propose that a mechanism be set up to allow access to the sum of all knowledge of published works, as a central bibliography, to both

• users, who can then view and search the central bibliography, and
• editors, who can then reference entries in the central bibliography from inline citations, specifying variable information such as page numbers as they do so.

PL290 (talk) 16:01, 18 May 2009 (UTC)

I really don't see how one can propose a new system without giving a thought to implementation. From my experience, in the vast majority of cases, it results in a bunch of people supporting and getting excited for something that never materializes. I've given some thought to an overhaul of the ref system myself, I have some notes at mw:User:Mr.Z-man/cite. Note that the a system to search references is one of the more difficult aspects of the implementation. Mr.Z-man 18:31, 18 May 2009 (UTC)

The goal of Wikimedia as a whole (and what Jimbo was talking about in that quote) is indeed to create "a world in which every single human being can freely share in the sum of all knowledge". Wikipedia is one component of that, we are an encyclopedia. Encyclopedias are not indiscriminate lists of things, such as books. When we're finished, we will have encyclopedic articles covering every notable work ever published. That's legitimate encyclopedic content. I don't think a List of all books ever published is legitimate content. That's what a library is for. Happy‑melon 18:34, 18 May 2009 (UTC)

Quoting Jimmy Wales is not the same as quoting Wikipedia policy. We follow policy, not what Jimmy said in some interview. And WP:NOT is quite clear: we're not a directory, and we're not an indiscriminate collection of information. Or, to put it at its most basic, we're an encyclopedia. Yes, we could, if we changed policy, spend huge amounts of time trying to build a central bibliography (do you have any idea how many tens of thousands of journal articles and books and newspaper and magazine articles are published every month?), at the cost of neglecting our core mission of improving articles. No, we shouldn't bother. -- John Broughton (♫♫) 20:43, 18 May 2009 (UTC)

Fair comments. I stand enlightened. I'll focus my thoughts then on only the "reference-sharing-across-articles" aspect, which was the trigger for this proposal in the first place. There seem to be further points still being made about this in the other discussion, so I'll see what transpires there. PL290 (talk) 18:52, 19 May 2009 (UTC)

I am working on a crude prototype of this thing. Check the draft article User:Jorge Stolfi/Oxocarbon test, Template:@@ and the subpages of the latter. Things to note in the draft artcile:

• The "♦" buttons link to the entry in the repository, instead of the entry in the reflist.
• The [E] buttons at the end of each entry in the reflist, to edit the entry in the repository.
• The way references are entered in the drft article's source.

There are many things missing still, e.g. a button to omit/show the Reflist section, hovering popups, etc.. Please be patient, I am still learning how to write templates... All the best, --Jorge Stolfi (talk) 06:14, 21 May 2009 (UTC)

I haven't had a chance to study it in great detail yet, but it looks extremely promising as far as I can see. (As an aside, does an "out-of-body reference" result in an "out-of-body experience"?!) On a more serious note, do you envisage that it will support multiple references in an article to the same work, e.g., by passing a page-range argument to the template? (For an example of why this is needed, see The Beatles, section Notes and section References. PL290 (talk) 07:50, 21 May 2009 (UTC)

Perhaps in conjunction with {{rp}}, mentioned above by John Broughton? PL290 (talk) 07:55, 21 May 2009 (UTC)

A combined solution using {{rp}} and {{@@}} sounds quite interesting. I'm going to let this sit in the back of my head for a while before saying more. Kudos to the editors who have contributed to both. --User:Ceyockey (talk to me) 01:20, 22 May 2009 (UTC)

My prototype User:Jorge Stolfi/Oxocarbon test is broken at the moment because I can't figure out how to expand the {{{1}}} in <span title="{{{1}}}">...</span>. The #tag function works for ":ref" but not for ":span".) Hints would be appreciated... --Jorge Stolfi (talk) 06:20, 22 May 2009 (UTC)

I think, I fixed your problem. Ruslik (talk) 17:37, 23 May 2009 (UTC)

DBpedia, or related projects, would be more likely candidates for this idea. Wikipedia would then access their data.

Side-note: This thread reminded me of http://ottobib.com/ which might be of interest to anyone that hasn't seen it yet. -- Quiddity (talk) 02:27, 26 May 2009 (UTC)

Frankly, I think you are right, Quiddity. The centralization of bibliography does fit in quite well with conversion of Wikipedia to a more computable format. I find the solution that Jorge has put forth to be innovative and useful, but I do think it quite unlikely that any but the most experienced editors might adopt it in practice. --User:Ceyockey (talk to me) 01:21, 28 May 2009 (UTC)

Many thanks to Ruslik for helping me fix the prototype. Please check User:Jorge Stolfi/Oxocarbon test again.
Note that any logged-in user can choose between the "old" and "new" reference display styles by changing the "Date and Time" option in his/her user profile. (Is there a prize for ugly template hacks? 8-) Logged-out users should see the page displayed in the "new" style.
The "old" style is like the current one, except that each entry in the references list has buttons [E][e] to edit the entry ad its half-line version.
The "new" style supresses the "References" section and instead displays a "♦"-link to each ref-page, with the half-line versions displayed in the hover pop-up.
This is about as far as I can get with my current knowledge of wikihacking. Hope it helps. All the best, --Jorge Stolfi (talk) 07:45, 27 May 2009 (UTC)

Autoprotected user space pages

During the process of rewriting the way editnotices work, it was suggested that user editnotices should only be editable by the user himself (and admins), similar to what already happens with .js and .css pages. With the AbuseFilter, this could now be done quite easily.
However, seeing that the autoprotected .js and .css pages are already often abused to store other content (huggle.css, a subsituted signature, ...), and that those pages display wikicode differently than normal pages, it might make sense to allow additional user subpages that can only be edited by the user himself (and admins).
I have two questions:

1. Do we want anything of the kind in the first place? Should any pages in addition to .js and .css be protected in such a way?
2. If so, what would be a good way to distinguish such pages? E.g., any user space subpage of User:Example/protected/, or any user space subpage starting with ".", or any user space subpage ending with " (protected)" or ".protected". User talk subpages would never be protected that way.
   Or should it stick to editnotices?

Personally, I would support such autoprotected pages. There is a use for them already with huggle.css and the like, and while I don't see huge amounts of editnotice vandalism, vandalism to editnotices can be far more disruptive since

• they are unwatched, possibly not even by the creator if the vandal creates it
• it is only noticeable when editing, and the talk page owner might not edit his own talk page if he prefers to reply on his correspondents talk page, so subtle vandalism can go undetected for a while
• due to MediaWiki oddities I'm not going to explain here (WP:BEANS) vandalism on editnotices can disrupt the MediaWiki interface (there's a reason that they were originally only allowed in MediaWiki namespace)

Opinions? Amalthea 13:40, 20 May 2009 (UTC)

String support for this proposal. I think that the user and user talk editnotice pages (in their present locations!) should have this protection, as should pages like "User:Example/protected/*". The "." notation would make sense to Unix people, but not to people who are familiar with Windows. עוד מישהו Od Mishehu 07:08, 21 May 2009 (UTC)

What kind of string?? :D Happy‑melon 15:23, 21 May 2009 (UTC)

Strong support: irrespective of editnotices (which I confess I'm not yet familiar with), if the editnotice rewrite can bring about the ability for users to maintain any vandal-proof content in User:Example/protected/ or suchlike, then that is a very useful achievement. PL290 (talk) 08:16, 21 May 2009 (UTC)

Support, preferably the User:Foo/protected/* notation. Happy‑melon 15:23, 21 May 2009 (UTC)

Strong support (with string cheese) Following the work that lead to this, it seems sensible. WE need to get a lock on this before the system proliferates. ---— Gadget850 (Ed) ^talk 22:48, 21 May 2009 (UTC)

Oppose. This is a wiki. Contrary to popular belief, pages in ones userspace do not belong to the user. This is a community and such pages should only be protected as needed (such as after several periods of vandalism), and most of them don't need it. - Rjd0060 (talk) 01:02, 22 May 2009 (UTC)

Very bad idea. There's a reason this feature hasn't been integrated into the software. We're a wiki. Misusing the Abuse Filter like this isn't appropriate. --MZMcBride (talk) 01:06, 22 May 2009 (UTC)

Just out of curiosity, what is that reason? Anomie⚔ 14:39, 22 May 2009 (UTC)

A wiki allows anyone to edit (nearly) anything, including userspace, and we are a wiki.   M  15:21, 22 May 2009 (UTC)

But we don't allow anyone to edit anything in the MediaWiki namespace, or any page in userspace ending with ".js" or ".css", or the Main page, or "high-risk" templates, and so on. What all those have in common is that screwing with them will cause major issues; this proposal is intended to do the same for user things that are not js or css. Which, IMO, means you have missed the point. Anomie⚔ 20:01, 22 May 2009 (UTC)

CSS/JS pages are protected due to security reasons. What is the use case for normal pages to be automatically protected? Mr.Z-man 02:21, 22 May 2009 (UTC)

Change policy: There doesn't appear to be any good reason why specific pages in user space shouldn't be protected for a user. The guideline mentions, almost incidentally, that "pages in user space still do belong to the community", giving examples of bot access, GFDL etc., but it states that "by convention your user page will usually not be edited by others". This is indeed a wiki, but user pages are already treated as a special case: the talk page has a different relationship, and you do have more latitude in user space than elsewhere. Change guideline/policy to allow some protected pages in user space. PL290 (talk) 05:53, 22 May 2009 (UTC)

• Changes to policy generally need some sort of reason. What's the use for this? Mr.Z-man 06:27, 22 May 2009 (UTC)
  • The possibility of vandalism is the flipside/downside of freedom of edit by all. In the case of (some) user space, there is no point in allowing freedom of edit by all. By some, perhaps, yes (such as admins), but not by all. So the use for this change is to remove the possibility of vandalism where freedom of edit by all is irrelevant. PL290 (talk) 08:16, 22 May 2009 (UTC)
  • Config files for software, Twinkle, Huggle, etc. Editnotice loaders where vandalism is less noticeable and potentially more damaging. Pages like this. There are a wide variety of reasons why having a secure directory would be a big improvement. You're right, MZ, that this will never be implemented in core software, but that doesn't translate to it automatically being a bad idea, or that using other means to make it happen is "misuse". Happy‑melon 09:15, 22 May 2009 (UTC)
  • Yes, what Happy Melon said. Such configuration files should be on wiki, and they should be protected from editing by others. For example, Huggle's configuration file contains edit summaries which will be automatically applied, and which are hard to take back if used in a vandalized state. And I believe I've described above why I think user editnotices should be protected as well. Amalthea 09:55, 22 May 2009 (UTC)
    • Why should they be on wiki? As far as I know, the only reason huggle's config is on wiki is so that admins can disable it in the case of misuse. Twinkle's config should be in a normal JS page, because it is JS. Just because you say they will be great for X, Y, and Z, doesn't mean other users aren't going to use them for A, B, C, D, and E. Now you've got pages people can use for spam and vandalism that can't be tagged for deletion by normal users, userspace POV forks that only the user can edit, and a new way to make violating WP:NOT#WEBHOST even easier. Mr.Z-man 15:27, 22 May 2009 (UTC)
      • Depending on the application: For Huggle to allow disabling it here, for the off-site statistic tool Melon mentioned to allow an easy opt-in signal. Twinkle's config can remain in .js, yes, but another tool I'm currently working on has a lot more meta content (edit summaries and user notifications) that would benefit from wiki formatting and will be placed outside .js space.
        As mentioned below and above, talk pages would still remain unprotected, so they can still be used for any tagging. And if it is a concern that those pages will be abused for content creation, or used for anything except meta content, it would be easy to remind editors with an editnotice showing on all those pages. Amalthea 17:00, 22 May 2009 (UTC)
        • Yes, I'm sure vandals and spammers will be deterred by an editnotice telling them to stop. This would also allow users to "hijack" existing pages by moving them into a protected subpage of their userspace where only an admin could move it back. I'm sure with some more time, I could come up with some really WP:BEANSy ways to abuse this. Mr.Z-man 19:16, 22 May 2009 (UTC)
          • Vandals and spammers abusing them can be dealt with as they are dealt with now, with the only difference that the talk page needs to be tagged instead of the subject page. Editnotices would help with more subtle, good-faithed abuse of such pages. And vandals can already hijack pages by moving them into the .js/.css area of their user space. No change there either. Amalthea 19:37, 22 May 2009 (UTC)
  • Another example: User:Erwin/AfDNote, and other templates placed by bots without human intervention. Those snippets should be on-wiki so that they are changeable without needing to bug the bot owner, they often need to be protected, and the bot owner should usually still be able to change them himself. Amalthea 11:08, 23 May 2009 (UTC)
• Note that a change in policy would be insufficient for the purposes discussed above, as those purposes require the corresponding user subpages be preemptively protected rather than just be protected on request. Anomie⚔ 14:42, 22 May 2009 (UTC)

• Comment. I do not think there is any need to create protected page in the user namespace. (css/js pages are a special case.) On the other hand, semi-protection may be desirable in some cases such as edit-notices. Ruslik (talk) 13:47, 22 May 2009 (UTC)
  • Semi-protection would be useless for the purposes discussed above, including the edit notices. It's trivial for a vandal to create an account, make a few innocuous edits, and wait a few days to get autoconfirmed if they already know enough to vandalize these user edit notice pages. Anomie⚔ 14:35, 22 May 2009 (UTC)
• Oppose, there's no argument that I can see for this to be made a general feature. Support protecting the editnotice. Should userspace (as defined by the user) be protected? No, because this prevents editors from putting deletion notices on attack pages and other junk. If you want a protected page, create a .txt file. Unless better reasons can be provided...   M  15:21, 22 May 2009 (UTC)

  The proposal is to protect a particular branch of userspace - I support a particular subdirectory - in the User: namespace only. notices such as CSD templates can be put on the talk page, as is already done for normally-protected pages. I don't think (certainly hope you're not) you're serious about the "create a .txt file", as this is obviously not a solution to the usecases posed. Huggle config is not a cascading style sheet. Why are we required to hack the interface to such an extent in order to give it the required level of protection? Happy‑melon 15:30, 22 May 2009 (UTC)

  Or if tagging the talk page isn't good enough, there's also WP:ANI, WP:AIV, and so on. It's not like tagging the page is anywhere near the only way to do anything. Anomie⚔ 20:01, 22 May 2009 (UTC)

• I'd be more comfortable having a list of protected pages (e.g. an editnotice page, a Huggle page, a Twinkle page, whatever) rather than creating a generic protected directory. I'm not sure how many cases people have in mind, but it doesn't seem like it ought to be a long list. This way there would also be a clear understanding that using those protected pages for other purposes (like content) is not okay. Also, I would support using Robots.txt to noindex all such pages. Dragons flight (talk) 16:19, 22 May 2009 (UTC)
  • To get robots.txt to noindex them would I believe require that they all share one prefix, which means they couldn't technically live in user space anymore, but would have to go to e.g. WP:Protected user content/Amalthea/Huggle. Not particularly pretty, and I don't think there's much harm in indexing them anyway? Spam there would get deleted just as quickly or slowly as it will at any other user page.
    I don't know how long an exhaustive list of such pages would be. Certainly manageable, but open ended. If it is done that way I'd suggest to place them in a clearly marked subpage tree anyway, e.g. at /protected/Huggle.
    I do think however that, with a proper guideline, editors can be convinced to only use these pages for meta content. To make sure, an editnotice as a reminder could easily be created to show on those pages. Amalthea 16:44, 22 May 2009 (UTC)
    • You're right about Robots.txt (I sometimes forget how limiting its syntax is.) Dragons flight (talk) 17:18, 22 May 2009 (UTC)
      • Incidentally, Google and Yahoo both support an expanded Robots.txt syntax that allows expressions like "/wiki/User:*/Huggle" to be blocked where the "*" is any string of characters. So one could block the big boys if one really wanted to, but it is probably not a big enough concern to get hung up on. The main point here is that I feel it is better to have pre-discussed list of things deserving pre-emptive protection rather than an open directory where anything goes. Dragons flight (talk) 17:26, 22 May 2009 (UTC)
  • I agree with Dragons flights. A protected directory is a bad idea. The limited uses of this make it possible to utilize the Title blacklist (yes, another hack) for things like Editnotices if you really want them semi-protected. The issue is that if a protected directory is created, it will be used for things beside configuration pages. Which is unacceptable. --MZMcBride (talk) 16:47, 22 May 2009 (UTC)
    • The titleblacklist will only work with semi-protection, as you say, which is not enough for script configuration pages, and I believe is also not enough for edit notices. Personally, I'd prefer disabling editnotices loaded from user space to leaving them unprotected. Amalthea 17:16, 22 May 2009 (UTC)
      • Uh, I never understand why there is so much paranoia surrounding editnotices. They can get vandalized. Who cares? So can nearly any article, user page, user talk page, policy page, etc. If you had a {{notice}} at the top of your user talk page, it could get vandalized too. People seem to have this crazy idea that because it goes above the edit form it's somehow sacrosanct. I don't get it. --MZMcBride (talk) 17:20, 22 May 2009 (UTC)
        • I've said so above: vandalism through them can be sneakier and less noticeable, and they can wreak havok with the interface to a point where a page cannot be edited anymore until the change is reverted. Since the devs show no inclination to fix this, it needs to be prevented here. Amalthea 17:24, 22 May 2009 (UTC)
          • Vandalism that disrupts normally editing can just as easily be done to articles using CSS hackery. The unclosed tags thing, well, meh. There seems to be all this talk of possible misuse, but I don't see any actual evidence. Is there a editnotice-vandalizing brigade? --MZMcBride (talk) 17:28, 22 May 2009 (UTC)
            • Except that you can add "action=edit" to the URL manually to get a clean edit form. Can't really do that when it's an editnotice causing the problem. Anomie⚔ 20:01, 22 May 2009 (UTC)
  • I think Dragons Flight has the right idea. I also would love to see Robots.txt used, I have seen far too much use of userspace to host fringe/deleted/promotional articles and it is never easy to get them deleted. I've seen such articles show up on the front page of Google searches. I wouldn't expect the casual reader to realise that they weren't ordinary Wikipedia articles. Dougweller (talk) 17:07, 22 May 2009 (UTC)
    • If you want to prevent that then you will need to get the whole user space noindexed again. The pages this proposal is about has little to no impact on that – you say it yourself, you find them at google already. Amalthea 17:16, 22 May 2009 (UTC)
• Comment A number of people above have raised the concern that users could use this for article forks, attack pages, and so on. If that's really that much of a concern, just make it a part of the policy that things in there may be deleted by any admin without warning if it wouldn't pass WP:RFPP, and in the "ou can't edit this" message shown to non-admins who are trying to edit it point them to some appropriate place (e.g. WP:ANI).
  Someone also complained about the possibility of a vandal moving an article into their protected space, forgetting that AbuseFilter can easily deny any move into or out of the protected space if necessary. Anomie⚔ 20:01, 22 May 2009 (UTC)
• Oppose Opens more cans then it closes. Makes user pages a bit too owny imo. Q ^{T C} 22:06, 23 May 2009 (UTC)
• Support if this is only to protect editnotices. A /protected/ or *protected idea would lead to abuse of protection. MC10 | Sign here! 02:31, 24 May 2009 (UTC)

Contest proposal

A proposal has been posted for a contest between all 200 country WikiProjects. We need to know how this contest should be run, and what problems to look out for.

The Transhumanist    17:21, 20 May 2009 (UTC)

Unwatch from watchlist

Background: whenever a watched page that hasn't been edited recently pops up in my watchlist, that may well be my signal to remove it from the list. For example, I have the "Add pages I edit to my watchlist" preference enabled because when I edit an article I come across, though that article is not one I currently intend to spend further time on, I'm always interested in any initial reaction to my edits. When the article pops up at a later time, it would be an improvement if I could remove it then and there with one click, rather than having to view the article and click "unwatch" there.

Propose: Add a further link to watchlist entries, so that after the article name, the existing links (diff; hist) become (unwatch; diff; hist) PL290 (talk) 08:36, 21 May 2009 (UTC)

Oppose > it's already too cluttered in there. However, if you turn on popups (like me!) there's an unwatch-link that appears when you hover your mouse over any link to any page, from any page, and loads of other useful stuff besides. ╟─TreasuryTag►contribs─╢ 08:39, 21 May 2009 (UTC)

I have use a script (not mine) that adds a link at the beginning; see my monobook.js for that (it's the free code section near the bottom; I customised the original version, which I'm sure you can find somewhere, by reducing it from "unwatch" to "-". - Jarry1250 ^{(t, c)} 08:53, 21 May 2009 (UTC)

Comment: If you go to the top of your watchlist, you'll see "View and edit watchlist" and "Edit raw watchlist", which may not be so quick as a single click, but can be done without having to open the article (template, talk page, etc.) itself in order to click the "Unwatch" tab. I hang onto the discontinued Netscape Navigator 9 browser (available from http://www.oldversion.com) specifically for Wikipedia editing, since I can put my Watchlist in the "mini-browser" sidebar and use it to open each watched page (or diff) in whatever order seems best. —— Shakescene (talk) 09:10, 21 May 2009 (UTC)

Firefox 3 editors can bookmark their watchlist, then right click the bookmark and check "Load this bookmark in the sidebar", which I think creates a similar effect. - Jarry1250 ^{(t, c)} 09:14, 21 May 2009 (UTC)

No no no no NO -- It's already too easy to hit the rollback, but at least others can take care of fixing it if you miss it. Adding unwatch in there...no. If you only need to unwatch a specific article, just click it, is it so hard? If you need to unwatch a bunch, you can use either of the two edit functions on top. ♫ Melodia Chaconne ♫ (talk) 11:20, 21 May 2009 (UTC)

Incidentally, after a couple of accidental rollbacks using my dodgy laptop touchpad I hid the rollback button on my watchlist. I think it's worth it. - Jarry1250 ^{(t, c)} 12:07, 21 May 2009 (UTC)

Sugestion: Have you tried using User:Js/watchlist.js in your monobook.js? It adds a link on the watchlist to toggle unwatch links (as an "x"). Ost (talk)

You can also get there via Popups. OrangeDog (talk • edits) 21:34, 21 May 2009 (UTC)

To get this to work, do I have do anything other than add importScript('User:Js/watchlist.js'); to my monobook.js? Tried it with both that line and a full copy-paste of the code, but neither altered my watchlist (yes, I bypassed the cache). Steve ^{T • C} 07:57, 22 May 2009 (UTC)

Thanks for the tips; I can see I'm going to have fun now I know about monobook.js.

Steve, watchlist.js works fine for me whether I use copy/paste or importScript. It's not obvious it's there though, till you click the single 'x' that appears first of all (see bold text in my "screenshot" below). Once you click the 'x', more 'x's appear, one by each watchlist entry. Slight pity you have to click the first 'x' every time the page is loaded; maybe I'll look into tweaking the .js to do it on load etc. now I know about monobook.js. I like the watchlist.js way better than the Popups way which takes you to another page instead of remaining on the watchlist. But I can see there's plenty of other good stuff in Popups (et al) which I'll now start to play with.

Watchlist options

You have 78 pages on your watchlist (excluding talk pages).

Below are the last 28 changes, as of 17:08, 23 May 2009.

Show last 1 | 2 | 6 | 12 hours 1 | 3 | 7 days all | Only new | x | <- click this 'x' to make the others appear

As a parting thought, there's always plenty more to learn about WP... so with new editors in mind, perhaps my original proposal still applies. One thing that's becoming clear to me from discussions here is that advanced editors can tweak the hell out of the UI, and I confess I'm not terribly convinced yet by the reasons for opposing. Too cluttered? one 'x' character (which could even be optional). Accidentally clicking? Why single out unwatch as so terrible a new risk? It doesn't damage anyone's edits, and with the watchlist.js approach, the line even remains right there, struck out, so you can just watch it again straight away. All the same, those new editors I'm now arguing for can always do it the slow way, so I can't pretend it actually matters very much; in fact, no, leave it as it is: it was a useful trigger to get me to start looking at monobook.js, so it could have the same effect on others. PL290 (talk) 17:52, 23 May 2009 (UTC)

Great minds think alike. I came here to ask the same thing. I stumbled across popup ages ago, it's amazing, but the whole point of the request is for a single click unwatch - it's a simple task so it's a pain to go through a page load or multiple clicks. However, watchlist.js does the trick! This has also inspired me to find the list of scripts at WP:JS. Watch out wikipedia, this digger's automated! Bigger digger (talk) 13:05, 24 May 2009 (UTC)

For anyone that doesn't like User:Js/watchlist.js, I recommend User:Alex Smotrov/wlunwatch.js as an alternative. It doesn't require clicking that first 'x', so it's a bit more convenient. — Gavia immer (talk) 15:11, 24 May 2009 (UTC)

I liked Js', but the lazier the better for me!, thanks Gavia! Bigger digger (talk) 15:36, 24 May 2009 (UTC)

OoK's expediency

Entities must not be multiplied beyond necessity.

Honestly, I turned suspicious of the Outline of knowledge existence within Wiki. The main problem is maintenance of associated tons of articles, the majority of which essentially duplicate the main ones and will flood Wikipedia soon. The namespace will be inflated to additional thousands articles, some of them, like hot issues, will natuarlly require extra attention (vandal patrol, bots etc.). Another issue is that outlines may oversimplify some articles akin to what was predicted in Fahrenheit 451.

Since OoK's transclusion to some non-WP venue may be problematic, I offer warranting the outlines just for long, difficult articles (such as existing Outline of medicine). brandспойт 12:17, 21 May 2009 (UTC)

Outlines articles are lists; it's rather unclear to me how a list can "oversimplify some articles" (by which I assume you mean "oversimplify some topics). And even if a list doesn't link to all the articles it could, it can still be a good starting place, since there are plenty of wikilinks within Wikipedia articles that will take readers to related articles. Plus the best solution would be to improve the outline/list, not delete it.

It would be helpful, for further discussion here, if you would point out two or three examples of problem outline articles. Could you do that?

Also, I'm having real problems trying to figure out what you mean by "associated articles" that duplicate "main ones"; could you provide an example of an "associated article" and the "main one" that it duplicates? And please don't use "the namespace" when you mean "article space" or "mainspace"; and please don't use "Wiki" when you mean "Wikipedia"; a wiki is not the same thing as Wikipedia. -- John Broughton (♫♫) 15:10, 21 May 2009 (UTC)

I don't propose deletion, but (not emphatically of course) facilitation somehow since I'm afraid it is rather impossible to manage all outlines amid pending issues. To point problem spots: many topics are too limited (either in terms of our knowledge or per se) to create outlines, such as the Outline of Adamstown, Pitcairn Island or Political scandals of São Tomé and Príncipe. And in particular nearly all existing articles on countries use the same request pattern, so we have even Fjords of Rwanda and other phantom or funny links.

John, I am perfectly aware of the words I'm using like nampespace not merely of articles, but also talks etc, and Wiki, written with capital letter as Wikipedia's lovely diminutive :) brandспойт 19:30, 21 May 2009 (UTC)

Okay, I'm starting to understand. Regarding duplication, List of São Tomé and Príncipe-related topics and Outline of São Tomé and Príncipe are two list-style articles with large amounts of overlap. And the second article has a lot of redlinks for things like Political scandals of São Tomé and Príncipe (your example) and Glaciers of São Tomé and Príncipe; the first probably could be easily sourced but the second is far more doubtful.

Still, I'm inclined to doubt that Wikipedia is going to be "flooded" anytime soon with thousands or tens of thousands of articles, requiring huge amounts of work, because these outline articles exist: If that is going to happen, why hasn't it already? These outlines have been around for quite a while; doesn't Ockham's razor say that the most likely future is similar to the past? (And in the past, these outlines have not caused problems, correct?)

In short, you seem to be proposing a controversial solution (deleting a lot of outline articles) to solve problems that you can't actually show now exist. Nor is there any reason to believe that the problems that you're worried about will ever appear. And if they do, we can deal with them then. -- John Broughton (♫♫) 15:01, 22 May 2009 (UTC)

We (WP:WPOOK) recently noticed that there are outlines that aren't called "Outline of". So we've started gathering them to Category:Outlines where they can be more easily spotted and dealt with. They will probably eventually be converted to a standard outline format or merged with an "Outline of" article. To be determined on a case-by-case basis, by usual wiki-procedures, of course. The Transhumanist    03:43, 25 May 2009 (UTC)

There's a guideline draft being written for outlines. It explains a lot of this stuff. See Wikipedia:WikiProject Outline of knowledge/Outline of knowledge. The Transhumanist    04:06, 25 May 2009 (UTC)

By the way, if you're opposed to the contest being proposed at Wikipedia talk:WikiProject Countries#Country outline contest proposal, you really should post your objections on that page, not here. -- John Broughton (♫♫) 15:15, 22 May 2009 (UTC)

Banner shells

Over at Template talk:WikiProjectBannerShell there's a proposal to make a mass-conversion from {{WikiProjectBanners}} (which is collapsed by default to {{WikiProjectBannerShell}}, which is uncollapsed by default, for WPB templates that only have a small number of banners inside. Please come and discuss!!. Happy‑melon 18:19, 22 May 2009 (UTC)

New pages, created by novices, should include noindex by default

Proposal summary

Pages created by users who are not autoconfirmed should, by default, include a noindex template. The template should only be removable by an autoconfirmed user

What problem is being addressed?

Brand new users, many unfamiliar with the guidelines of Wikipedia, create pages that violate many rules. Many of these pages are indexed by search engines such as Google. Links to Wikipedia pages often score very high in the Google page rank system, thus these pages are very often one of the first presented to a person using a search engine. In the case of some rule violations (poor grammar) it is only mildly troubling that such a page would appear in a search engine. However, other violations, such as copyright violations, and libelous statements against living persons, are far more serious. While established editors can and do run afoul of the rules, pages created by the newest Wikipedians are more likely to be troublesome.

I did a very unscientific review of a few recently created pages. Results here:User:Sphilbrick/Sandbox for support of proposal The sample size is too small to draw broad conclusions, but does illustrate some of the issues. In short, I reviewed a number of new pages created by users with fewer than ten edits, and found eight with concerns. Six of the eight are already found in Google, and can still be found, even though, in some cases, the underlying page has been deleted.

What are the benefits?

Under my proposal, none of the eight pages identified would be found using a search engine (outside of Wikipedia). One of these pages is flagged for a copyvio, and all but one of the others reflects poorly on Wikipedia.

While this benefits is admittedly modest, I estimate that dozens of pages with problems are created each day by nonautoconfirmed users, and these pages are finding their way into search engines. If a better estimate of the potential count is needed, I can do a more rigorous analysis, but I'll note that my review covered fewer pages than are generated in a single day, so it is highly unlikely the number is less than thousands in a year. (However, I don't know how long it takes for a deleted page to drop out of Google, so I don't have an estimate of the number of problems pages in existence at any time.)

What are the costs?

I see four types of costs:

1. Implementation time
2. Education time
3. Template removal time
4. False positive cost

My list is somewhat long, but each is minor. IANAP so I don't know precisely what is necessary to implement this, but I assume that when a user creates a new page, it fires off an algorithm that would need modification. The algorithm needs to determine whether the user is autoconfirmed, but my understanding is that this happens every time a user does an action, so is no cost. The algorithm would have to create the new page in a slightly different way for the two types of users, but I think adding a template should not be a major cost. (Does the system already add a non-patrolled template, or is that handled a different way?)

If the proposal is implemented, user manuals would need a rewrite. Not zero, and I may be under-estimating the places affected, but not major.

If the proposal is implemented, someone will have to remove the template at some time. However, most of these pages will have templates relating to other issues, so removing this template when the other problem messages are removed should be a minor addition of time.

Finally, there is a possibility that a new user will create an excellent article relating to a breaking news item, and users of search engines will run across the article later than they would under the present approach. While it needs to be mentioned, I find it difficult to believe it could be a meaningful problem. New pages relating to breaking news are highly likely to be patrolled, and it seems very unlikely that such a page would escape review by an autoconfirmed user with the ability to remove the template for more than literally minutes.

Background

This proposal was inspired by a discussion in Technical here. This proposal stands on its own, but interested readers might want to read the link to see, for example, why removal based upon a time limit was criticized, or why a proposal that it would take an administrator to change the status was a problem.

Alternative

I feel that the noindex template rule should be stronger than simply users who are not yet autoconfirmed. I would prefer something like a few hundred edits and a few months. However, creation of a new class of users is likely to be a big deal, so I chose to make the distinction using autoconfirmed. I do note that Tor users have rules applied at a different point - 90 days and 100 edits. If that status is easily available, I would find it a better choice.Sphilbrick (talk) 23:31, 22 May 2009 (UTC)

Are new pages created by random users not already detected in some way? Have there been actual cases where this has posed a problem - complaints, that sort of thing? One main objection probably is that adding noindex would deprive us of an important tool for finding these types of pages (that is, Google and other engines).   M 

Responding to your main objection - one of the aspects of the proposal is that any confirmed editor can remove the noindex tag, so in the case of acceptable articles, the delay would be minutes or perhaps a couple hours. Unless you meant that you wanted to find these offending articles using a search engine outside WP - but I'm failing to understand why.Sphilbrick (talk) 12:59, 23 May 2009 (UTC)

• Looking at your sample articles, I think you may be making too big a deal out of this. No-indexing of pages (which currently can't be done with articles at all), should only be done when there are the potential for serious problems. Some of the articles you picked out are just bad writing. Ijare may not be particularly helpful, but its not harmful. David Collier (producer) may be terribly written and an unsourced BLP, but the article itself is entirely positive. I don't really see anything wrong with Women's Action Alliance, for an article by a new user, its not that bad. Arthur Do is written like a CV, but other than that, not bad. Liam Bunston was a crappy autobio, but not something particularly terrible. No-indexing exists to hide potentially problematic content within our inner-workings from Google, not to hide our minor messes. Mr.Z-man 06:19, 23 May 2009 (UTC)

For those new to the discussion, the reference to "sample articles" is the list in my first pass review. I've supplemented my review with a more comprehensive review - my third pass covers all articles created in the first eight hours todaylatest.Sphilbrick (talk) 18:27, 23 May 2009 (UTC)

I agree that the harm is, at most, modest in the selected articles. The Women's Action Alliance is a good example of how the proposal works well - yes, it would be caught in the net, but I anticipate that within hours (maybe even minutes), some editor would decide it is good enough and remove the tag. I do suggest, however, that badly written articles do contribute to harm, by adding to a perception that one can find a lot of crap in WP. That said, my main goal is to filter out a fair number of the more egregious problems, such as Fstg, with the possible copyright violation. Ironically, while it is tough to search for pure copyright violations, the filter I propose would also fiter out some abysmal writing, while not filtering out decent contributions for more than a very limited amount of time.Sphilbrick (talk) 12:59, 23 May 2009 (UTC)

No, the harm for most of those articles, using the definition generally applied when discussing Wikipedia articles, is 0 (some of the articles are so overly positive, the harm is probably negative). When most people speak of "harm" coming from an article, its harm to a 3rd party, generally the article's subject. Harm to Wikipedia's reputation from poor writing is not considered. We should not try to hide the fact that we have poorly written articles. If anything, we should highlight them so they get improved faster. Mr.Z-man 15:53, 23 May 2009 (UTC)

• I think it's a good idea. The examples may not be very striking but the potential for more serious effects is clear from the proposer's narrative. If it's really "highly unlikely the number is less than thousands in a year", a number increased by an unknown factor by Google's old-page cache, then I'd have thought it's worth doing something about along the lines suggested. The only reason not to do so appears to be if implementation cost is prohibitive (which I don't think opponents are so far saying). PL290 (talk) 10:08, 23 May 2009 (UTC)

• I would be fine with the software automatically noindexing all new pages for a fixed period - say 3-5 days. This gives time to actually get the article started, and to speedy delete it if it is speedy deletable. It does little damage for the world to wait a few days to read about it. Time-sensitive topics like current events may be an exception. Dcoetzee 13:35, 23 May 2009 (UTC)

  Well, the software wouldn't know what was time-sensitive and what wasn't... --Izno (talk) 16:48, 23 May 2009 (UTC)

Actually, why not set up a 7-day noindex "honeymoon" for all new articles? Autoconfirmed threshold of 10 edits is ridiculously low; has anyone ever reached a thorough understanding of basic policies on their eleventh edit? NVO (talk) 17:57, 23 May 2009 (UTC)

From your edit summary I think you intend only all new articles by novices here, not all new articles? This sounds promising, as the proposal is specifically addressing issues caused by novices (para. 1). PL290 (talk) 18:14, 23 May 2009 (UTC)

I agree that the ten edit threshold is ridiculously low. As noted in the Alternative section, I'd prefer something like 100 edits and 90 days. However, the benefits of this proposal are modest, I want to ensure that the costs are modest, so i deliberately chose a threshold which wouldn't require new programming. If the programmers tell me that a higher threshold is as easy, I'd prefer a higher threshold. Sphilbrick (talk) 18:31, 23 May 2009 (UTC)

All new articles; at least, all unpatrolled. Perhaps, if some sort of reviewing is ever introduced, all articles until they are properly reviewed. NVO (talk) 19:43, 23 May 2009 (UTC)

I'd support something in this direction, on the basis that (a) new articles are generally some form of draft; waiting long enough for improvements or deletion should not be a problem for a website seeking to be an encyclopedia; (b) the idea that current events articles should be excluded from this noindexing squarely forgets WP:NOTNEWS. (In fact, so many current events articles should be on Wikinews anyway - and with new licence changes, we'll be able to transwiki content from Wikinews to Wikipedia as appropriate, once the significance of the current event is clearer and something resembling a encyclopedia article rather than a news report is more likely to result. Only real problem with this is that - in my experience - Wikinews procedures are impenetrable, versus the child's play of creating a new WP article.) Rd232 ^talk 19:18, 23 May 2009 (UTC)

While I maintain significant doubts about the desirability of noindexing pages, were a consensus to agree with the basic idea of this proposal, I'd suggest that new pages which have not been patrolled (that is, via a modification of the existing new page patrol system) be the ones to be noindexed. Obviously acceptable articles would be quickly patrolled, while backlog would not cause unacceptable pages to become indexed without review. The large backlog already present might be a problem, but it's an approach worth considering should people find noindexing of articles otherwise acceptable. {{Nihiltres|talk|edits}} 21:06, 23 May 2009 (UTC) (iPod edit)

I'm still not sure what this proposal would solve. Has there been any problem with a search engine indexing new articles?   M  19:58, 24 May 2009 (UTC)

The problem it will solve is not advertising our first drafts, spam, tests, and miscellaneous unreviewed junk to the world, via said search engines. Rd232 ^talk 20:08, 24 May 2009 (UTC)

I understand this much, but what policy or principle or consensus does such advertisement violate? We have drafts, and vandalism, and all sorts of junk, and I don't mind 'admitting' it to the search engines.   M  20:14, 24 May 2009 (UTC)

The issue is that new articles are more likely to be junk than old; or at any rate older articles have been around long enough to have a chance to get reviewed. Generally, people don't publish first drafts; Wikipedia does. Why advertise them as well? Noindexing may even discourage (however slightly) vandalism, spam, and general junk creation; and if not, the junk will have less effect on the world, being much less visible. Rd232 ^talk 20:30, 24 May 2009 (UTC)

"Why advertise them as well?" should be "Why not censor them?", and there has been no need demonstrated. Further, no evidence that new pages really are bad has been provided. (I just checked 10 new pages, and they were all remarkably good.)   M  20:55, 24 May 2009 (UTC)

Allowing Google to index them is not advertising them. "Adverting" implies we're going out of our way to promote them. The default is to allow indexing; we just let Google do its job. The main argument in favor of this seems to be "poorly written articles make us look bad" - and they should. We shouldn't try to hide our flaws to give people a false impression of our quality. Personally, I support putting articles in need of cleanup on the main page as a way to get more people involved in editing. Mr.Z-man 05:26, 25 May 2009 (UTC)

I'd understand your argument if we were talking about, say, no-indexing articles tagged and categorised as "bad" in various ways: hiding flaws. This is not that: it's the equivalent of saying "no, you can't see my first draft!". And frankly saying that google-indexing isn't advertising is splitting hairs - it is the major way such new articles are found. Finally, this isn't just about looking bad, it's about being bad: by (in an important sense) publishing first drafts via google, we're not allowing ourselves enough time to review and remove junk which should not be published. Looking at it purely as a "looking bad" issue implies an expectation that new articles should be perfect, and that the failure of such articles to be perfect shouldn't be hidden from the world. Put another way, the whole point of Wikipedia is to write a collaborative encyclopedia; why not give ourselves some time for collaboration to take place on new articles, before announcing the result to the world, via google? Rd232 ^talk 11:53, 25 May 2009 (UTC)

Because we want to collaborate with the world. Every reader is a potential editor. This proposal is to hide content from the general public that does no real harm. I cannot support that. And again, "announcing" and "advertising" are action verbs, both suggest that we're taking some action, when we're not. This is not "splitting hairs", its an important distinction to make. You seem to be twisting things around to make it sound like we're taking some action to force Google to index them when we're simply not stopping them from doing so. No-indexing them would be taking an action; it would be changing the default. Mr.Z-man 15:19, 25 May 2009 (UTC)

(a) I'm not twisting anything: choosing not to act, once you know there is a potential action (here, noindexing) is still a choice. (b) again, we're not talking about hiding all bad content (however defined) or for an unlimited period - only new "first drafts", temporarily. Seeing as there is no deadline, and WP:NOTNEWS, there is no reason to allow publication (if you prefer) before content has had a chance to be reviewed. Again, WP is a collaborative effort; why should things be published before any collaboration has had time to develop? This change fits all kinds of aspects of WP:NOT, and allows the WP community time to exclude WP:NOT violations. Why is this controversial? Are there other issues people are thinking of but haven't mentioned? PS Of course we still need new editors, but by definition this change is about weeding out topics not meriting inclusion, which by definition we don't want to attract people to and don't want to waste time on. Articles a week or two old will still be published to search engines, and still need improvement, and still attract editors hoping to help. Reminder: WP is an encyclopedia not a news source: why is it a problem for new draft entries to be reviewed internally before they're made more widely available externally? What's the deadline here? Rd232 ^talk 12:58, 26 May 2009 (UTC)

Policies and guidelines shouldn't be treated like articles

It seems to me that policies and guidelines are treated too much like regular articles in that, first, anyone (or if the page is semi-protected, any established user) can edit them, and even more problematically, changes are decided by talk page consensus. Why should it be assumed that editors who happen to be involved on a particular project talk page at a given time are representative of the community consensus? This is especially troubling in light of such pages existing to describe rather than dictate accepted practice. Then there is the recurring question of whether No consensus regarding the status quo is grounds for a removal or whether decided consensus is needed for any change to such a page.

One solution would be to fully protect all guidelines and policies so that only admins can edit them. I anticipate the counterargument—that such matters are decided by the community and not merely the admins. However, admins are supposed to be those who have the trust of the community at large, and should be trusted to make such pages representative of community consensus. Moreover, they would figure to be the ones most aware of what is widely accepted or rejected in practice, therefore are most apt to make sure that is accurately described. PSWG1920 (talk) 16:25, 23 May 2009 (UTC)

I'd definitely like to see some movement towards greater stability in the various guidelines and policies. Full protection is definitely worth exploring, given that these are the rules that govern our conduct. However, we'd have to ensure that the intent of this is crystal-clear, being to ensure stability, and that the "admin-only" lock is in regards to posting changes, not making them. --Ckatz^chat_spy 16:39, 23 May 2009 (UTC)

On the principle of WP:NOTLAW, a change is never actually made (unless it comes from the top, i.e. Jimbo Wales), but rather evolves. Policies and guidelines exist to describe what has already evolved. That is my concern with talk pages deciding what the policies and guidelines should say. PSWG1920 (talk) 16:52, 23 May 2009 (UTC)

Nope. The issue has little to do with open editing. I've been around for quite a while now and I discover new policy pages all the time. (Wikipedians love instruction creep.) The rules are descriptive, not prescriptive. They describe best practices. Any user should be able to use common sense and not ever have to read a policy page. If they're updated or changed, that's fine. But the spirit is what is important, not the specific wording being used. And, of course, any major changes to major policies are usually well-advertised. --MZMcBride (talk) 16:49, 23 May 2009 (UTC)

It's in the nature of WP that policy pages are descriptive. For them to be prescriptive would require a change to policy pages to be systematically enforced; this doesn't (and perhaps can't) happen unless the community (a) knows about it and (b) agrees with it. Only in the case of certain admin actions is there much chance of policy change preceding practice (because there are many fewer admins than editors, especially in relation to specific admin tasks). Anyway full protection is unnecessary, because editors on talk pages generally know that proposals for major changes need to be advertised way beyond the talk page. Failure to respect that generally gets reverted. Rd232 ^talk 19:10, 23 May 2009 (UTC)

However I think general semi-protection of at least well-established policy/guideline pages is worth exploring; IPs in my experience contribute little to the main policy pages, as do new accounts - but they do produce vandalism which (a) makes it harder to read the history to see how policy pages have evolved and (b) discourages people from paying attention to policy pages, because changes are too often junk or reversion of junk. Since changes should be discussed on talk anyway and they can still propose changes on talk, the cost of excluding IPs and new accounts from such pages is very low. Rd232 ^talk 19:10, 23 May 2009 (UTC)

See also WP:EP#Editing policies and guidelines. Rd232 ^talk 18:15, 24 May 2009 (UTC)

The [edit] 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 [edit] 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 [edit] 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 [edit] 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 wikipedia (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 "[Edit]" in a useful, non-disruptive place without stacking. On the other hand, putting [Edit] 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\^C 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 wikipedia 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\^C#

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 Wikipedia. Dendodge _T\^C 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\^C 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 ^talk 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 Wikipedia 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 ^T 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 [edit]

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 ^T 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). ···「ダイノガイ千？！」^{? Talk to Dinoguy1000} 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 [feature/function X]. 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 Wikipedia editing more difficult, so that less smart people will be discouraged from editing and just stick with reading Wikipedia. For those who may have missed the statistics: total edits here at the English Wikipedia 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 Wikipedia 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 [edit] 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 [edit] 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 Wikipedia. (A gadget for old users would be nice, too, in case we're more trained than we think.) HereToHelp ^{(talk to me)} 21:25, 26 May 2009 (UTC)

(ec) That was cryptic—the word "[edit]" 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\^C 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\^C 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\^C 00:02, 27 May 2009 (UTC)

No, it doesn't go against the original proposal, which was to move the [edit] 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 Wikipedia:Centralized discussion, not raise the issue on Wikipedia 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 Wikipedia 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

That the [edit] 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 Wikipedia. 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)

• 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 [edit] 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 [edit] 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 Wikipedia 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 ^T 13:53, 27 May 2009 (UTC)

I think the successful use on the German Wikipedia 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 Wikipedia 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 [edit] 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 ^T 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 Wikipedia 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 ^{T C} 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)
• 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 Wikipedia), 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 Wikipedia and think it looks horrible. Powers ^T 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. ···「ダイノガイ千？！」^{? Talk to Dinoguy1000} 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. ···「ダイノガイ千？！」^{? Talk to Dinoguy1000} 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 [edit] 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 ^T 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)
• 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\^C 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 [click to edit section] 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 ^T 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 Wikipedia 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 Wikipedia 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 Wikipedia 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 Wikipedia. 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)

• 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)
• 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)

New Proposal: Save a Copy of Wikipedia as of certain date AND SELL FOR PROFIT

Wikipedia,

I am sad to report dishonesty is infiltrating into Wikipedia as some who are larger corporations see the "advertising value" to Wikipedia. This means the usual deterrence to bad posts (undesired, unbalanced posts) is going to spread like crazy from here.

1) Keep Wikipedia online same as it is 2) I would pay 200 bucks gladly even for digital ( no medium) because the decay is obvious- those with truer wiki-wiki win in long run 3) This is the first step in a process to move wikipedia into peoples phones, desktops, lives while mobile- so more money there.

End

PS: You guys are arguing about the word "Pfat" and the whole Wiki crystalline beauty is rotting. Please save it- well beyond me.

Hmm... WP:1.0 work for you? --Izno (talk) 02:44, 25 May 2009 (UTC)

(Not necessarily corresponding to the OP's numbers)

1. Spam and attempts to manipulate Wikipedia are not new problems. We've been dealing with spam for years now. Given the popularity of Wikipedia, its actually a lot more dangerous for corporations to abuse it than it was before. WP used to just be yet another site that could be manipulated for SEO purposes, now if a big corporation or a politician gets caught at it, its negative PR in the news.
2. The longer Wikipedia goes, the more review articles get, so Wikipedia is likely getting better with time, not worse. While spam is an issue, there's nothing to suggest its leading to the slow death of Wikipedia.
3. Why on earth would you pay $200 for free content on some 20 cent DVDs? You might do it (for some rather misguided reasons) but I doubt a lot of other people would.
4. Most new mobile phones have internet access, and again, its fairly difficult to get people to pay for something we give away for free (and making people pay for it when we can give it away for free is somewhat contrary to our mission)

Mr.Z-man 05:17, 25 May 2009 (UTC)

1. VERY Strong Oppose This would destroy the point of Wikipedia being a "free encyclopedia". YOWUZA Talk 2 me! 16:36, 26 May 2009 (UTC)
2. This proposal is now moot with the new Books application ;) Anyhow, strong oppose to selling free content for corporate gains; in any way, shape, or form. ThemFromSpace 17:32, 26 May 2009 (UTC)

Suggestion to resolve the whole "sexual image censorship" eternal kerfuffle

I realize I'm a relatively new Wikipedian by account, but please bear in mind that I have been around here under various names and IPs since 2004, although I don't wish to provide names or links going back that far, since I don't think it's all that relevant. I'm just saying this to show that I'm not some random schoolteacher showing up here and saying this.

That said: What of a system in which sexual, graphic or highly medical images are tagged with a warning on their Image page (so that it doesn't interfere with articles) and there is an unobtrusive link on the Wikipedia front page to "browse Wikipedia without graphic images" that would set a cookie in the user's browser to block images with such a tag. Can this be done? I realize that WP:NOT censored, but this seems less like censorship and more like any of the voluntary methods a user can undertake to block sexual images, only facilitated by the Wikipedia software. One potential problem I can see is that I'm not sure how it could be implemented without possibility of removal for say, a school or family computer -- it seems like students and children would easily be able to turn it off. If this idea is liked, though, maybe someone brighter than I would have an idea to resolve that problem...?

--Lesath2 (talk) 16:33, 26 May 2009 (UTC)

The problem is, someone could easily add the warning maliciously/remove it. Good idea though. YOWUZA Talk 2 me! 16:38, 26 May 2009 (UTC)

WP:DISCLAIM. This is quite a perennial proposal. ♫ Melodia Chaconne ♫ (talk) 17:06, 26 May 2009 (UTC)

The issue is, as ever, how do we decide which content should be handled in this fashion? There are many groups reading Wikipedia who think that sexually-explicit images are a minor problem in comparison to images-of-Mohammed/images-of-the-Holocaust/etc/etc. Should we build a similar system for such media? If so, how can we avoid accepting the responsibility for controlling access to any arbitrary content? It's the zero, one, infinity argument: the only way to control the situation is to adopt the zero position: we do not censor any content, for any reason, except our own editorial policies. That way, no one can come along and say "you have a button for not seeing images-of-X, but not for images-of-Y", and equally "You said clicking this button would hide images-of-X and it didn't, now I'm pissed off" is similarly avoided. This is the only viable position to take. Happy‑melon 17:19, 26 May 2009 (UTC)

No it isn't. We can give a disclaimer about the content control system, and then give buttons for whatever people want buttons for. Default show everything (obviously - WPNOTCENSORED), but allow people to hide sexual imagery, nudity, Mohammed cartoons, or pictures of spades. Why not have some kind of content classification (in the usual flawed messy WP way), and allow users to choose what they want to see? Rd232 ^talk 17:33, 26 May 2009 (UTC)

If someone wants to install a personal filter to block Muhammad too, then I have no problem with this. What is a problem, though, is that if we help people make even voluntary filters like this, then we'd end up helping people make voluntary filters for other types of content that should not be censored. An alternative is to request that the school board catalog the specific images that are inappropriate, and block those directly. I doubt that this is a good idea, though, since nothing should prevent a child from getting what is essentially sex education information.   M  17:32, 26 May 2009 (UTC)

I imagine that if we gave a school a list of all 4 million+ images on commons and asked them to pick out the ones they wanted hidden, they'd probably just laugh. Its far easier for them to just do a less precise filtering with keyword based web filtering software or block Wikipedia altogether. Mr.Z-man 17:58, 26 May 2009 (UTC)

There are several problems with this well-intentioned proposal.

1. Unfortunately, even with a disclaimer as Rd232 suggests, if we take that first step toward filtering certain kinds of content, we then become responsible if one example of that kind of content gets through unfiltered. If we say "here, browse Wikipedia without explicit images" and a penis picture sneaks through to little Johnny's computer, we've got big problems on our hands, disclaimer or no. As it is now, we can say "Wikipedia has explicit images; sorry!" and not worry about whether our filters are airtight.
2. Then there is the problem of determining what exactly counts as "graphic". We make content-based distinctions all the time on Wikipedia, but I think the last thing we need is yet another type of one. Is File:Gray1166.png graphic? Is File:Gray406.png? File:Da Vinci Coition of a Hemisected Man and Woman Luc Viatour.jpg? They're illustrations and therefore ok? Then what about File:CSC Herme Masturbate-a-Thon Logo Original for Wiki.jpg? See how hard difficult it is? Who makes these decisions?
3. Why stop with images? What about graphic text? Or links to sites with pictures or text that would be filtered were they on Wikipedia. What about wikiquote:Marquis de Sade?
4. And as Happy-melon points out, how many different filters should we create? Should we create one that blocks access to information on homosexuality? On sado-masochism? On Nazi imagery? (The German government would like that one.) If not, what makes nudity and explicit sexual images a valid target but Nazism not?

I'm sorry, but starting down this path opens too many questions. We've got an encyclopedia to write. Powers ^T 19:04, 26 May 2009 (UTC)

I think all those can be addressed. For example, 1 is easily discounted (if the disclaimer is enough when we don't even bother, a disclaimer for when we try but sometimes fail is surely enough). 2. we make decisions equally difficult all the time (eg what counts as a reliable source). 3. and 4. are fairly absurd FUD attempts to put a ratings classification for images in the same court as censorship; we'll have to trust, as with everything else, that something sensible comes out of the collaborative WP process. (And if it doesn't, only those who specifically choose to will see the results.) All that said, I have no interest in either creating such a system or using it; I just don't think it's inherently unworkable. Rd232 ^talk 21:24, 26 May 2009 (UTC)

I think you dismiss issue 1 too easily. It sounds illogical, but it is often true that trying and sometimes failing is often worse than not trying at all, at least from a PR standpoint. For 2, yes, we do make equally difficult decisions all the time, but I don't see the case for adding another category of difficult, and in this case especially contentious, decisions to our remit. I don't appreciate the accusations of FUD; 3 and 4 were not intended as that, just as examples of more lines that we will have to contentiously draw. 4 also raises a very relevant question -- why sexual content and not other kinds of potentially objectionable content? It's not FUD to ask why sexual content is being called out as a candidate for filtering. Powers ^T 13:40, 27 May 2009 (UTC)

OK, sorry, "FUD" came off too dismissive. Rd232 ^talk 16:48, 27 May 2009 (UTC)

• We need to leave this issue to others, such as the providers of web filters. Any concerned parents, schools, etc. can use those products to control what content is available to children, and I'm sure they will do a much better job than Wikipedia. We are a world-wide encyclopedia so shouldn't be deciding what may or may not be offensive in any particular culture; for example, in one country a split second flash of a nipple is considered offensive enough to cause a national scandal, but the rest of the Western world just laughs in incomprehension. Phil Bridger (talk) 21:48, 28 May 2009 (UTC)

An idea to consider... (moved from User talk:Jimbo Wales)

Hi there Jimbo! Its me, again. I noticed that Wikimedia Commons has held a Picture of the Year compition in the last three years which seems to be working out pretty well. I was thinking if Wikipedia could possibly hold an Article of the Year compitition, or something similar to it. What is your opinion about this suggestion? Ross Rhodes (T C) ^Sign! 15:45, 26 May 2009 (UTC)

• Oppose. The last thing we need is yet another barnstar-strewn mutual backslapping festival. See also the previously rejected Article of the Month proposal. – iridescent 16:10, 26 May 2009 (UTC)
• Support - I rather enjoy barnstar-strewn mutual backslapping festivals--Jimbo Wales (talk) 16:16, 26 May 2009 (UTC)

  As long as everyone understand how (in)significant barnstars are (which, I think, they do), sure, what's the harm? I would suggest separate contests for different classes of article, since it is rather difficult to compare articles on very different subjects (eg. Titanium vs History of Sheffield vs The Wiggles [I haven't looked at the actual articles, I picked them based on the subjects]). A final round to choose the overall article of the year wouldn't hurt, but it should be taken even less seriously than the rest of the contest. --Tango (talk) 16:28, 26 May 2009 (UTC)

  When concerned with FAs or article writing, most of those high-volume awards contests have a high tendency to decrease their quality, and often disrupt the entire process. Our most respected content writers had to fight restlessly to get the infamous awards center down, see the mfd debate. There's also the rejected and deleted Wikipedia:Featured Article of the Year. So, I'd say be very careful with that... It could look innocent at first sight, but then it becomes a big problem and a major waste of time and resources. And if this is something that won't be recognized by the community at large, which previous experiences shows to be likely, I don't see the point. Cenarium (talk) 17:07, 26 May 2009 (UTC)

  I imagine that problem can be fixed pretty easily by saying that the version of the article that existed before the contest started is the one that counts (yet another thing FlaggedRevs would help with!). --Tango (talk) 17:30, 26 May 2009 (UTC)

  If we require articles to be FAs, they should already be FAs before the contest, to minimize the disruption of FAC. But even if the version to be considered is fixed, some users may disregard that. Another source of concern are political or controversial articles that will create contention when !voted on, and even more if chosen as 'AOTY'. Cenarium (talk) 19:45, 26 May 2009 (UTC)

• Sounds like a great idea - better proposed on the village pump though. Majorly talk 16:30, 26 May 2009 (UTC)
• Support. As it was my idea. Thanks for supporting me on this Jimbo! Ross Rhodes (T C) ^Sign! 16:54, 26 May 2009 (UTC)

Just a note that it's not by supporting here that you'll have consensus for anything. Cenarium (talk) 17:07, 26 May 2009 (UTC)

• Support barnstar-strewn mutual backslapping festival. Hopefully there will be some cringe worthy drama involved as well. Let's roll. ChildofMidnight (talk) 17:11, 26 May 2009 (UTC)
• Support if and only if Samuel Johnson is given the award of greatest Wikipedia page of the century, along with Johnson the title of greatest Brit ever. Ottava Rima (talk) 18:27, 26 May 2009 (UTC)
• Support Obviously a good idea. But I suggest rather than article of the month, do article of the quarter--Jan-Mar, and so on--and then there could be a fun vote for the article of the year based on the four finalists. Anyone can submit their article, for the first year, even older ones, and then after a year, limit it to articles that made FA during that cycle. rootology/equality 18:36, 26 May 2009 (UTC)
• Support I rather like the idea of a "barnstar-strewn mutual backslapping festival" as well. ⊕Assasin Joe ^talk 19:40, 26 May 2009 (UTC)

• This is a user talk page, not a place to gather consensus for a project. If you want to propose this, use the village pump for example. Cenarium (talk) 19:45, 26 May 2009 (UTC)

Can I just move this information to the page; instead of having to start the voting again. Ross Rhodes (T C) ^Sign! 19:46, 26 May 2009 (UTC)

I was about to answer: No, the proposal needs to be fairly presented. We see this from time to time, proposals on Jimbo's talk page that get his support or not, and then we wonder how to handle it adequately or we have objections because of that (BLP survey for example). Note also on the situation this edit by Jimbo; starting a discussion with 'Jimbo supports this' would be unfair and not allow to adequately generate consensus. This thread can't be moved without skewing the discussion, because this is a user talk page, not a common place for community discussion (even if, for good or bad, sometimes it happens here). Cenarium (talk) 20:08, 26 May 2009 (UTC)

• Many problems: 1) We add 500 to 600 FAs per year: what editors are really going to read all of those articles to make an informed decision? 2) What will prevent this from being simply a popularity contest, with the editor who has the most friends receiving the honor? 3) To what aim is this award mentality? Could not the same effort go into reviewing articles? 4) Does anyone really believe that any one article of those 5 to 600 can be considered "best"? Misplaced effort. SandyGeorgia (Talk) 20:12, 26 May 2009 (UTC)

• Oppose As this has been moved... First, the way it's been proposed is skewed, thus invalid to generate consensus for creating this project. I've explained this above. As I said also, this will create massive controversy and drama for political or controversial articles. And it's pretty established that those kind of award contests have an adverse effect on the quality of content and related processes, see the mfd debate for the "award center" for one of those (one of the 'myspace' series episode from last year). It took many user's time to deal with this and finally get it down, no need for another massive waste of time and resources, and generator of drama and controversy. That would be interesting in an ideal world, but knowing how Wikipedia works... Cenarium (talk) 20:29, 26 May 2009 (UTC)

• Strong Oppose We don't have enough reviewers for FAC. The last thing we need is a diversion of that limited pool for an exercise that is fraught with myriad problems. For example, who gets to vote for this? All Wikipedians or only FAC reviewers? If it is the former, then what does one do about perfunctory votes/comments of the kind, "I have read all the articles and find Article X to be head and shoulders above the rest?" For another example, will this contest be restricted to FAs or will other articles allowed as well, and how many? Ten, twenty, all FAs of a given year? As it is, arguments about the quality of individual FACs in their respective reviews can run into pages and pages; imagine, then arguments about comparisons of A with B, A with C, ..., A with Z, B with C, and so forth ... Wikipedia is an encyclopedia, whose service to the community is provided often in the uncelebrated articles, sometimes on small topics, written by multiple authors and even anonymous IPs. Examples are: Pronoun, Relative clause, Gravitation, Theory of relativity, Vinegar, Wine, Cabernet Sauvignon, Whiskey, Introduction to genetics, DNA replication, Elm, Cumin, Marathon, Long jump, and so forth. None are FAs, and many only B class articles. In contrast, many FAs seem to be newspaper style feature articles on obscure topics that no one reads or consults? Why are we celebrating them? Fowler&fowler«Talk» 20:43, 26 May 2009 (UTC)

• Neutral at the moment. Main arguments in favour seem to be (a) it'll be fun (maybe) and (b) it'll be good publicity (probably), and hence might help attract new editors. Against: (a) it'll inevitably have a strong element of arbitrariness/randomness (b) it'll take time and energy away from improving articles through established processes (c) it won't be fun, it'll be a tiresome pile of argumentative work. I suggest that a way to avoid the downsides would be to form some sort of elected committee to choose a limited number of FA candidates, and then have a general vote on those. Just A Bit Of Fun then, with limited messiness. Rd232 ^talk 21:03, 26 May 2009 (UTC)
• Comment I don't see why people keep bringing up FAC. I don't think this has to have anything to do with that. And yes, it's a popoularity contest to some extent (like AfD and RfA and every other process we "vote" on. There needs to be a set of rules for nominating. A set of rules for voting. And wa la: let the fun begin. My suggestion would be to have a category for new articles (created that year) and improved articles as there seems to be a bias of awards and recognition towards new content rather than fixing what's there. I don't see why an article has to be FAC to be awarded this honor, that is its own well established process. And as far as concerns over it being a distraction, it's only a distraction if you choose to participate in it... ChildofMidnight (talk) 21:11, 26 May 2009 (UTC)

  On commons, pictures are chosen among featured ones. This is an assurance of quality, and of course would probably be seen as an advantage if not required for selection. Thus people would try to make their articles featured or at least of good quality for the selection, which will likely disrupt those processes per past experience. It will also create controversy and drama when controversial or political articles will be nominated (let's take an example: Barack Obama). And it will be forced upon us, even if we don't want to participate. But such a process must also be representative and recognized by the community at large to have a real value, which probably won't be easy to get. Cenarium (talk) 21:28, 26 May 2009 (UTC)

• Neutral to weak support I can see the inherent problems in this but if we could get it to work would be good I think. I like something similar to RD232's suggestion as well. dottydotdot (talk) 22:25, 26 May 2009 (UTC)

Oppose First of all, the widely varying subject matter of FAs means that it is nearly impossible to determine what is "best". Second, why waste so much time reading throught the 2,500 FAs to see which is best, especially when editors can be doing many more productive things, such as reviewing potential FAs or cleaning up old FAs. Third, why the emphasis on awards? This would probably turn into a popularity contest to some extent. Dabomb87 (talk) 23:43, 26 May 2009 (UTC)

Oppose Like Jimmy and many above, I like barnstars. But linking them in such a manner with featured content is baaad, for reasons enumerated above. Agree with Dabomb: a bit of misdirected energy we could spend on improving Wikipedia in tangible ways. --Der Wohltemperierte Fuchs ^(talk) 00:21, 27 May 2009 (UTC)

• Support. I'm usually not a fan of contests, but this sounds like a good idea. I share Dabomb's concerns, though if it encourages the creation of quality content, I'm all for it. –Juliancolton | ^Talk 01:08, 27 May 2009 (UTC)

Question If there is already a contest for photos, what is the difference? Isn't that a subjective contest also? I don't really understand the opposes. Those who want to participate can, and those who choose not to don't have to. Seems like a nice way to focus on what a great article is all about and I think the discussions of which articles should be nominated and why and which ones people will vote for as the best and why, will be enlightening. Will there be bias of all sorts? Absolutely, but that's where discussion and process come in so we can work out a consensus result that will certainly not be without controversy, but that will engage editors in focusing on "Beauty" so to speak a la Zen and the Art of Motorcycle Maintenance. And all editorial decision making is subjective to some extent after all. ChildofMidnight (talk) 01:49, 27 May 2009 (UTC)

That's what concerns me: the amount of time that would be spent finding and deciding on the "best" article. If this were a simple "list all the FAs and let's vote" thing, I would say go for it. However, this process seems to require a substantial amount of time to find a set of superior articles, discuss how the articles will be chosen, and determine how the best of those articles will be selected. Is this really worth that time? Dabomb87 (talk) 01:58, 27 May 2009 (UTC)

Also, I don't look forward to the prospect of "cringe worthy drama". We have enough of that. Dabomb87 (talk) 02:01, 27 May 2009 (UTC)

Is there anything on Wikipedia that doesn't create a certain amount of cringe worthy drama? If 10 co-noms had to sign on to nominate an article into the competition, and the nominess were narrowed down after editors were allowed to select one or two to advance to the next round, and then if everyone was given a vote or two on the final outcome, I think it would be positive. People would read and edit the articles. It would also hone community wide skills on what an excellent article is all about. I'm sure there will be some controversies, but I think a focus on great article creation and writing is inherently positive for anyone who wants to participate in it. I personally wouldn't want to see it focused on FAC only articles, but I see the reasoning in favor of that. If FAC articles have an advantage, I think that's great, but this process should be independent. I think the discussion of which articles should "advance" or be selected would be very enlightening. It sounds like fun. Which article would you nom? :) ChildofMidnight (talk) 03:47, 27 May 2009 (UTC)

• Support Though perhaps only "timely" Featured Articles should be considered? That is, the chosen article should be about a major happening or emblematic thing during that year. E.g. for the period of the last 6 months, it could be the financial crisis, if the article on that was of Featured status. Kinda like Time Magazine's "Person of the Year", except not restricted to just people and with only topics having Featured articles being elegible.--Cybercobra (talk) 21:56, 27 May 2009 (UTC)
• A big problem with this is public perception. We're not any more a little site nobody cares about, where we can play unheeded. If we want to legitimate this title, it will have to be widely advertised - and approved - in the community, and the result will be quite widely known in the community, and beyond: it will be picked up by media. And what will people think of this ? How should we present this ? What will be the consequences on Wikipedia and the Wikimedia Foundation ? For example, if it's Barack Obama, we'll be accused of favored treatment, supporting him, much more so than we have already been (which attracted, and keeps attracting regular disruption). But this is true not only for this article, if we choose Halo 3 for example, will we be accused of making its promotion ? Certainly, and same for U2 and many others that could pretend to this place. It's not like FAs of the day, article of the year is a title, and will be seen as such. Doesn't it go against our NPOV policy, to choose an article and honor it more than others ? The public will also expect a selection criteria: so as mentioned above, what should it be ? how do we make the choice ? based on quality ? most of our users are not expert in content writing, and as pointed out, comparing the quality of hundreds of articles is infeasible, and such comparisons are not very relevant or valid anyway. So it would be random, or indeed based on popularity. And about creating a pre-selection committee: WP:BURO. I don't see how we can organize this in a workable and widely acceptable way. Cenarium (talk) 23:08, 27 May 2009 (UTC)

The proposal has seven or eight "supports" and six "opposes." It isn't going to fly. Fowler&fowler«Talk» 10:18, 28 May 2009 (UTC)

• Oppose, mostly per User:SandyGeorgia. Looking at a picture takes a few seconds. Forming an informed opinion on one maybe a few minutes. Reading an article is at least one order of magnitude more work. I don't see how we will get a result beyond a pure popularity contest. --Stephan Schulz (talk) 21:15, 28 May 2009 (UTC)
• Since this has now changed from being a query on Jimbo's talkpage to apparently a full-fledged vote, endorsing and reiterating my earlier oppose comment. Quite aside from the sheer pointlessness of an award where the only people who qualify will be the group who generally care least about awards, it's based on the ridiculous premise that it's possible to rank articles on completely different topics to the same criteria. How do you rank Richmond Bridge, London, Carrington Moss, Posting system and Jerry Voorhis (the last 4 FAs to be promoted at the time of writing) against each other? I might take Jimmy Wales's opinion that this kind of thing isn't counterproductive a little more seriously if he'd ever actually uploaded a Featured Anything or written an article more than one paragraph long. – iridescent 21:31, 28 May 2009 (UTC)

Wow! Those articles have very serious problems. I would not be comfortable nominating even one of them. Which raises serious concerns about the FA process and also suggests to me a contest with community wide input would really highlight what makes a great article. I'm not sure what FA focuses on, I suspect it's rather technical, because having material that is clear and well written doesn't seem to factor in at all. ChildofMidnight (talk) 02:55, 29 May 2009 (UTC)

Proposed enhancements to table sorting (rowspan/colspan support)

Hello all. I've been working quite a bit with tables and noticed that one of the long-standing issues that has been on the table sorting todo list is "don't break on colspans/rowspans (bug 8028)". A recent scan of the article mainspace yields about 1000 articles having tables with broken sorts. (See Broken table sort articles.) I suspect that there are many other articles with tables that would benefit from sort capabilities, but where sorting has not been enabled due to rowspan and colspan issues.

Well. I've taken on the task and have put together an enhanced version of the wikibits sorting algorithm that implements rowspan and colspan support. To summarize, the enhancements do the following.

1. Before sorting, rowspans will be exploded, so that each row is self contained and can be moved without corrupting the table structure.
2. During sorting, colspans are recognized and counted when retrieving column values, so that the proper sort value is retrieved from each row. Each column in a colspan range is treated as having the same value. Colspans are preserved – they are not exploded.
3. After sorting, some cell ranges may be recombined under certain restrictive conditions. In particular, cells that were previously exploded may be recombined. Also, class="autorowspan" may optionally be applied to column headers or the entire table to enable more aggressive rowspan combines, such as combining cells in the newly sorted column that were not originally combined.
4. Multirow headers containing rowspans and colspans are also supported. Each cell will get its own sort icon. Sort icons may be inhibited from being added to selected header cells by adding class="unsortable" to that cell.
5. Sort icons in headers that span multiple columns will perform a multi-column sort.

To see a demo of the enhancements, you will need to add the statement importScript('User:Tcncv/sorttables.js'); to your User:Xxx/monobook.js file (or whatever skin you use). Several sample tables are located in User:Tcncv/Table Sort Demo. You can also test your own tables (or those identified in the list referenced above) by copying them to a test page and changing the table class from "wikitable sortable" to "wikitable tsx_sortable" or "wikitable tsx_sortable autorowspan".

I will eventually submit this for formal review by the code gurus in Bugzilla, but I would like to first submit it here for review and comment. In particular, if you see any unexpected behaviors or bugs, or have suggestions for different behavior, please let me know. Also, If you like what you see, please say so, since such interest may influence whether or not these enhancements are accepted and implemented.

Thank you. -- Tcncv (talk) 02:48, 27 May 2009 (UTC)

I loved this when I first saw it and I don't love it less now. Haven't found any bugs yet (but I haven't looked at many tables other than the ones on the test page). —JAO • T • C 12:54, 27 May 2009 (UTC)

I've just looked at some of the samples, and this looks great! I've been wanting something like this for a long time. –Drilnoth (T • C • L) 17:35, 27 May 2009 (UTC)

I'll Take the above responses as two votes of support. -- Tcncv (talk) 00:22, 28 May 2009 (UTC)

Sounds good—I'm installing it now. Dendodge _T\^C 00:24, 28 May 2009 (UTC)

One minor issue I see is that the first column in the Olympics medal table shows a downward arrow, rather than the correct symbol, when sorted in reverse alphabetical order. Despite that, I love this script, and hope it can be implemented sitewide soon. Dendodge _T\^C 00:36, 28 May 2009 (UTC)

That was actually a bug in my browser, which I've just realised occurs with all sortable tables. I can find no issues with the script. Full support Dendodge _T\^C 21:42, 28 May 2009 (UTC)

If you let us know the browser type and version, perhaps we can isolate the problem and possibly include a workaround in a future version of the wikibits script. -- Tcncv (talk) 22:11, 28 May 2009 (UTC)

By "bug", I mean my browser was playing up (FF3, it plays up often), so displayed the alt text of images rather than the images themselves. Sorry for the trouble I caused. Dendodge _T\^C 22:20, 28 May 2009 (UTC)

OK. It looks like the current implementation will set alt-text to up arrow (↑) and down arrow(↓) but does not have a separate alt-text character for unsorted. I don't see why not. Perhaps the an up/down arrow(↕ or ⇅) would be appropriate. I've tentatively added the second arrow. -- Tcncv (talk) 02:58, 29 May 2009 (UTC)

Dead external links

It would save time and annoyance if external links that have "died" could be shown in red, similar to non-existent subject pages. This seems to be a natural task for a bot. It would scan all external links periodically. Since access time is slow for many links, and links are often down temporarily e.g. for maintenance, it might be best to retry a dead link after, say, 12 hours before marking it red. Then keep trying it and return to blue immediately it responds. Cuddlyable3 (talk) 07:17, 27 May 2009 (UTC)

I don't know if there is a bot doing this, but we do mark them with {{dead link}}. The Checklinks tool will scan an article, help to find alternative links and mark dead links. ---— Gadget850 (Ed) ^talk 09:43, 27 May 2009 (UTC)

Remember, (new) dead links on Wikipedia are soon to become a thing of the past. - Jarry1250 ^{(t, c)} 10:48, 27 May 2009 (UTC)

As for the millions of existing links, many of which are bad, I looked at the relevant section of the Editor's index (WP:EIW#LinkRot), and found mentions of three bots to find bad links: User:EchoBot, User:Stwalkerbot, and Wikipedia:Bots/Requests for approval/ShakingBot. The first two bots, both of which have been inactive for quite a while, posted messages on article talk pages when a dead external link was found; the third bot, which never was approved (inactive request), would have flagged bad external bots in the article itself. And then there was a bot to actually fix bad external links - User:RefBot; the Editor's index says that this is "not operational due to restrictions on owner – ArbComm cases". -- John Broughton (♫♫) 13:24, 27 May 2009 (UTC)

Old chestnuts

I think there should be a guideline for these proposals and their responses. It seems silly to have to keep filling up these threads over and over again with the same distracting explanations about whether or why you should or shouldn't say the users are just stupid and can put up with it or I've got used to it so why can't they. I think it would be better if you could just cite the guideline and carry on. Laughing Jean Genome (talk) 11:14, 27 May 2009 (UTC)

If you don't like em, don't read em. There's always the possibility that someone will bring something new to the table. Trying to regulate discussion in such a way is kinda the antithesis of what WP is all about, even if it's not related to the articles themselves. ♫ Melodia Chaconne ♫ (talk) 11:38, 27 May 2009 (UTC)

I like 'em, I wanna read 'em, once! Once, and clearly, not again and again while people are trying to discuss something else. You say someone may bring something new to the table: that's my point too. I want to see it when they do. The other distracting discussions belong at another table. I want to see it when people bring something new to either table but not both at the same time! Laughing Jean Genome (talk) 12:27, 27 May 2009 (UTC)

Have you seen WP:PEREN? That seems to be exactly what you're looking for. — Gavia immer (talk) 16:55, 27 May 2009 (UTC)

No I hadn't seen that, but it's not what I'm looking for thank you! What I meant is when the proposal is a new idea, not one of those perennial ones. Someone then chimes in saying they had to get used to the system like it is, so why shouldn't the newcomers have to get used to it too. That kind of thing. Then, others have to explain again why that's not a valid objection, and how we should focus on whether the proposal will help the newcomers. So threads are getting clogged up with this kinda stuff when it could be said once, in a guideline. That's what I meant about bringing suggestions to two tables. The proposal is one table and the guideline is the other. Why have the guideline discussion turn proposal discussions into spaghetti threads! Laughing Jean Genome (talk) 17:51, 27 May 2009 (UTC)

Tabs at top of page

This has no doubt been brought up before, but instead of having:

• page - discussion - - edit - history - move - watch
• page - discussion - - edit - history - move - watch

wouldn't it be more logical and helpful to have something like:

• page - edit - history - move - - discussion - edit - history - - watch
• page - edit - history - - discussion - edit - history - move - - watch

so that (a) you get immediate access to the history/edit pages of both main page and discussion page, regardless of which one you're on; (b) it doesn't look like the discussion is just one of the options under the main page, equal with edit and so on?--Kotniski (talk) 11:53, 27 May 2009 (UTC)

I think the point here is that your changes would be an improvement to simplicity of use, but they are also confusing to someone wishing to edit the article or see the article's history and is confronted with the buttons. The large number of buttons is also (more) distracting. It's just a case of whether the improvements outweigh the downsides, and I don't think they do. - Jarry1250 ^{(t, c)} 11:59, 27 May 2009 (UTC)

Perhaps the less immediately relevant ones could be displayed differently, for example using a less prominent typeface, or by doing something like:

• page - e - h - - discussion - edit - history - move - - watch

?--Kotniski (talk) 12:04, 27 May 2009 (UTC)

I have ten tabs at the top of my pages already; oversighters would have even more. This change would be of little benefit to new or inexperienced users (would be confusing as Jarry says, "e h" is jargon that newbies can't be expected to intuitively understand) and for more experienced users, the downsides of taking up valuable tab real-estate probably outweigh the advantages of easy access. If you want to add tabs to your own skin, you can easily do so in your JS files. Happy‑melon 12:14, 27 May 2009 (UTC)

Well actually, it was more new users that I had in mind. My experience as a new user was that I was always getting confused, thinking I was going to the page history when I was going to the discussion history etc. - it still happens from time to time; and I still get annoyed that I can't go straight to the page history from the discussion page. And obviously we should be prioritizing ordinary users - how many buttons admins or oversighters have is surely irrelevant. --Kotniski (talk) 13:08, 27 May 2009 (UTC)

This is what gadgets are for, I think: once an editor gets comfortable at Wikipedia and starts thinking about making editing easier, then he/she can look at gadgets (again). So while I oppose this suggestion (adding two more tabs just makes the world even more complicated for a new editor), I would support adding a gadget that would add two more tabs - something like Wikipedia talk:WikiProject User scripts/Scripts/Six tabs. -- John Broughton (♫♫) 13:32, 27 May 2009 (UTC)

FWIW, here's the "Usability Wiki". I see hiding everything except "Article" and "Edit", with a hover over "Edit" (or "Tools" or "Info" or other possibilities for the tab title) revealing the other sections with better details, like this:

I know, hover does not work in this case – this is just a very rough sketch of what might work to help explain the meanings of the tab titles, while removing visual clutter. The power user would want to avoid all of the descriptions; I think the appearance of the menu would be entirely configurable in user preferences, i.e. "classic" (as it is now), "custom", etc. What about anon, IP users? Well, they can register and/or use an actual account to adjust the appearance of the menu, or it can change by default based on user group. I think a lot of experienced users have ideas along these lines, and think there should be a formal collaborative effort to get such changes in place, I just am not sure where that debate is or who they think should participate. Certainly our opinions should matter even if the changes are to benefit new users. Sswonk (talk) 13:42, 27 May 2009 (UTC)

Yes, it's always hard to get a useful discussion about what works for new users. But surely the newer the user, the less we should be hiding from them - they don't know what to look for, after all. I agree that all this should be personalizable with gadgets, etc., but that's quite irrelevant to ordinary inexperienced users, who ought to be given the most clear, intuitive interface. For me the current tab setup never made sense - you see two groups of two/three tabs, then when you click the second tab the meanings of the 3rd/4th/5th all change, although you don't see any change... Then there's not even any indication that there are other tabs "under" the 1st/2nd one... Maybe it's just the way my mind work-ed/s, but to me the extra confusion from two more tabs is far outweighed by the added clarity (and functionality, of course).--Kotniski (talk) 13:58, 27 May 2009 (UTC)

No, I don't want to hide anything either, but to your points about "clear, intuitive interface" and "extra confusion", wouldn't only two tabs be better, with the second tab immediately revealing detailed descriptions of all the possible other tabs for new users only? Again, like you maybe it's the way my mind works. You are right about the way the tabs currently change meaning, it's bad. Sswonk (talk) 14:36, 27 May 2009 (UTC)

Not sure I've properly understood you, since you say you don't want to hide anything, yet your proposals seem to be about making things invisible until you click/hover over other things, which is what I understand by hiding. This sort of thing is fine in its place (I like the way it works in popups, for example), but I don't see any need for it in a situation where space is not restricted - and at the top of the page there seems to be plenty of room, at least for the tabs a normal user (non-admin) would see under my proposal.--Kotniski (talk) 15:28, 27 May 2009 (UTC)

Absolutely. But there is not plenty of room for clear formal descriptive sentences about each tab. If something at the very top says "Edit", or "Contribute HERE!" (not seriously, but it can be more precise than "Edit"), and displays full details when hovering or clicked, that is going to be easier to understand and decipher than the multiple, somewhat ambiguous offerings now. I still would like to know if there is a single, authoritative UX forum/RFC if anyone can point it out. Sswonk (talk) 17:09, 27 May 2009 (UTC)

PDF of usability design. For those who had not found it yet. —TheDJ (talk • contribs) 14:15, 27 May 2009 (UTC)

I actually suggest a set of tabbed pages is not the best metaphor in the first place. Tabs soggest switching between concurrent activities, whereas here we are selecting—indeed invoking—one activity at a time. For example, clicking "article" is not a valid way to look at the current version while editing, as this will lose the editing done so far. So I would prefer to see something which is, in fact, just like the contents of that "edit" navbox provided above by Sswonk, i.e. a vertical list of completely comprehensible choices, and—lest anyone immediately counter that the long list will take up too much vertical space, which actually perhaps would not be very much—note that further, I suggest the choices visible at any time should only ever be those pertaining to the current action, so for example there would not be an "article" choice visible during editing. PL290 (talk) 14:46, 27 May 2009 (UTC)

AFAICT your point, though valid, really relates only to the edit window. I don't know what the best solution would be - again, not hide the tabs, I think, because you very often do want to quickly access one of the other tabs while editing (e.g. using the browser's "Open in new window" option). But perhaps new users could see a warning message when accessing another tab from the edit window, saying that they will have to use the "Back" button in their browser to get back to editing - and that message could be dismissable once you've learnt. --Kotniski (talk) 15:28, 27 May 2009 (UTC)

That's true up to a point about it mainly being the edit window as far as my example goes; however, consider: once you click "discussion", the "discussion" tab is seen to become the active tab, and three other tabs ("edit this page", "history" and "move") are seen to have remained unchanged as inactive tabs. However, far from having remained unchanged, those three have taken on new meanings and will invoke new actions. This further demonstrates that the tab metaphor is not helping, and that the list of available choices ought to change according to the current action. As to the need to access the article while editing, yes, but that could perhaps be better accomplished by starting the edit itself in the new tab/window. No warning would then be needed. PL290 (talk) 18:32, 27 May 2009 (UTC)

Give Lead section its own edit link

As defined by wiki markup at least, the Lead is not a "section", but some text that appears at the top of the article. This excludes the Lead from having an edit link auto-generated. It would though be beneficial to at least have the option to edit the Lead section in isolation, just like any other section. Benefits include fewer edit conflicts, particularly for large, frequently edited articles or during periods of heavy editing by collaborating editors. PL290 (talk) 10:51, 28 May 2009 (UTC)

Special:Preferences → Gadgets → MediaWiki:Gadget-edittop. Amalthea 10:56, 28 May 2009 (UTC)

If you go to Special:Preferences, and look at the "Gadgets" tab, you'll see an option under "User interface gadgets" that provides just such a link. It is (currently) the third line down, "Add an [edit] link for the lead section of a page". Hope this helps. --Ckatz^chat_spy 10:59, 28 May 2009 (UTC)

Marvellous—thank you both—then I guess the proposal changes to "make that the default preference setting". PL290 (talk) 11:02, 28 May 2009 (UTC)

I enabled that after two weeks of editing, and I still click on it when I mean to edit the whole page and not just the lead. - Jarry1250 ^{(t, c)} 11:11, 28 May 2009 (UTC)

Yes, I do see that's a potential issue; one, in my opinion, compounded by "edit this page" being far away, and appearing to be a tab, per the #Tabs at top of page discussion. Compounded also by what might be termed the Lead's "sectional ambiguity": hierarchically, the Lead is the start of the article and does include all the other sections, yet it's convenient to think of it as a section for some purposes. I'd have thought the gadget, being specific to the Lead, could be tweaked quite easily to add both links in close proximity (edit Lead and edit page) so you see them both at the same time and are more likely to click the right one.PL290 (talk) 11:48, 28 May 2009 (UTC)

• FWIW, this is the reason it's not default - it's still not working very efficiently, and gets snarled up in the page rendering sometimes. It's on the development to-do list, though. Shimgray | talk | 00:26, 29 May 2009 (UTC)

Watchlist improvements

Hello,

Was directed here a few days ago to suggest my improvement.

Currently i have about 200 to 300 pages on my watchlist and each day i can be seeing about 50-100 changes. My suggestion is to make grouping so says for this wikipedia pages you get a collapse menu that shows all wikipedia related items, then you have project pages etc etc, and maybe customised caterogies as well.

This would mean oyu could say have 20 caterogies and then you can see how many changes are in each and you can look through smaller samutn without missing stuff.

A better example is i was offlien for 3 days and it took me 6 hours to work out what had changed and what i had to restore back etc.

Anyway if oyu need mroe information i will let you know.--Andrewcrawford (talk) 19:54, 28 May 2009 (UTC)

To summarise the numerous debates we've had on this topic: it's technically unfeasible for now. The watchlist code is still far too hackish, and yet to be improved to a standard whence it can be improved upon. Sorry. - Jarry1250 ^{(t, c)} 20:02, 28 May 2009 (UTC)

Fair enough, thanks for the reply i hope in the future something like the feature i have said can be implamented as it make editors life much easier esicpally if oyu watch a lot of pages. Thanks again :)--Andrewcrawford (talk) 20:09, 28 May 2009 (UTC)

Its not really "hackish", just inflexible. It works great for what it does now, but almost every feature request for watchlists would require either additions to or a total redesign of the database table for watchlists. Mr.Z-man 20:21, 28 May 2009 (UTC)

Andrew, you might want to test out the script "WikiWatch", which organizes watchlist entries into categories. The project page says it is not under active development at present, but it may be worth a test. --Ckatz^chat_spy 20:31, 28 May 2009 (UTC)

Thanks ckatz that seems to be what i am looking for, unfortnally i will need to muck about to find out hwo to use it since the pages does not say--Andy t c 20:51, 28 May 2009 (UTC)

No problem... I was going to offer to install it for you, but then saw that you've already done so. (FYI, the "Lightmouse" script for date delinking is the subject of an injunction against its use at the present time.) Best of luck, and feel free to ask if you have more questions. --Ckatz^chat_spy 20:56, 28 May 2009 (UTC)

To be honest teh date delinking script does not work for me at all, but thanks for the heads up--Andy Chat c 20:59, 28 May 2009 (UTC)

undent. If anyone like me finds the Cacycle/wikiWatch script runs too long, an alternative is to create a set of bookmarks (or wikilinks on your user page) to specific namespace watchlists like these:

• 3 days Article
• 3 days Talk
• 3 days User talk
• 3 days Wikipedia
• 3 days Wikipedia talk
• 28 days File
• 28 days Template
• 28 days Help talk
• 28 days Category
• 28 days Category talk
• 99 days Portal talk

My watchlist has 1,322 pages and I found I was missing many changes buried among all the article changes. 84user (talk) 02:07, 29 May 2009 (UTC)

Consistency between all section templates

Couldn't we make all section templates the same size? There has been a discussion on making the size of {{expand-section}} smaller and the size was reduced. So what about {{Unreferenced section}}? I'd like to propose shrinking this template too.--Diaa abdelmoneim (talk) 22:24, 28 May 2009 (UTC)

You could try asking on Template talk:Unreferenced section or Template talk:Unreferenced (as Unreferenced section calls Unreferenced). This example adds "small=left" to the ambox call but it makes the template appear taller:

84user (talk) 02:38, 29 May 2009 (UTC)

• Hear, hear! And also, PLEASE, make them appear flush aganst the right margin, like an [[Image:...|right|...]], so that they do not waste screen space with blank lines, and do not interfere with reading the article. All the best, --Jorge Stolfi (talk) 08:14, 29 May 2009 (UTC)

Ew, that wastes acres of screen space. It will need to be cut down hugely if it's to be made small, like sect-expand is just a few words.

Jorge, the right-floating small option was the default for mboxes, and we (the template coders who wrote it) were specifically asked to make a left-aligned version for the small amboxes, so it wouldn't interfere with permanent images, infoboxes, etc, that are located on the right. Happy‑melon 11:02, 29 May 2009 (UTC)

An opinion - How can Wikipedia reliability be improved.

Hi all. I've written a blog post about the Wikipedia reliability issue, and what I think can be done to improve it.

My idea has a major technological aspect, but is based on human review, or "Human Computation" if you'd like.

Anyway, the blog post is here: How can Wikipedia improve its content reliability

-- Itai Bar-Haim

The right way to judge the reliability of an article is to read it and look at the sources it uses. Is your idea of creating an arbitrary numerical grading system for every article likely to encourage or discourage editors doing that? Cuddlyable3 (talk) 08:59, 29 May 2009 (UTC)

The numerical grading system is supposed to let readers know how reliable the article is. Currently Wikipedia articles are not reliable enough for use in academic or even elementary school works, simply because teachers cannot trust that information. I suggest a system that will allow users to know just how reliable that article is, by letting people grade its facts. Who the people are? This I will let Wikipedia editors decide. These can be any reader, trusted editors, or both (trusted editors for specific articles, etc.). Currently, even if editors do check reliability of all sources, and make sure that all facts are correct, a user might still read the specific version of the document that is incorrect without knowing that someone just messed it up. I hope this answers your question. --84.228.205.79 (talk) 09:23, 29 May 2009 (UTC)

The problem is that even with a system like what you are suggesting, people will be able to get around it. For example, they might edit an article so as to keep a particular number the same but changing the text surrounding that number (e.g. changing 'The population of Guernsey is 60 000' to 'The population of Jersey is 60 000'). The statement would become false but the software would detect that the number was unchanged and would treat the statement as correct. It would also be possible for malicious people to obtain the necessary rights to become trusted. There is currently no mechanism in Wikipedia to check someone's qualifications so there would still be the opportunity for someone to game the system.

You said 'When ever someone that is not trusted in a certain value or category, changes a fact field, the reliability factor for that fact field decreases.' What that implies to me is that a fact field edited by multiple untrusted editors is more unreliable than a fact field edited by one untrusted editor. Surely you would just need one person to put in a fake number and the fact field would instantly become incorrect. Tra (Talk) 10:19, 29 May 2009 (UTC)

Not to mention, a fact that WAS true can easily change. ♫ Melodia Chaconne ♫ (talk) 11:24, 29 May 2009 (UTC)

This is all true, of course, and I won't argue with that. However, all of those issues are solvable to some extent:

• Regarding the "changing the text around the numbers", I specifically mentioned there are other types of fact fields, so the entire text surrounding the number can also be marked as fact, and/or make special fields, that include all the relevant terms ("Population", "Guernsey", "60,000" in the above case).
• Regarding the one untrusted editor that messes up things, versus several untrusted editors that messes up things - it's really all the same and up to the chief editor decision. It can be decided that for a certain value, any change made by an untrusted editor in a fact field would simply mark the entire paragraph/section/article unverified.
• Regarding a fact that WAS true and was changed - as I wrote in the blog post, the article will be granted lower reliability factor, thus a link to the highest ever reliability factor will appear next to it, and will show you the version of the article with the correct fact. —Preceding unsigned comment added by 84.228.205.79 (talk • contribs)

This sort of system might work better in an environment where the data is stored in a table e.g. a table of populations of countries. That way, it's clear to the user and the software which fact field is which and it would be easier to handle changes to individual numbers. On Wikipedia, even if you end up turning every other word into a fact field, you'll still very often have people rewording entire sentences and paragraphs and messing up the system. Tra (Talk) 13:47, 29 May 2009 (UTC)

I agree, however, to my (very little) experience, most people who make such changes tend to be registered users, that spend quite a lot of time editing values on Wikipedia. After a while, I believe such people can be granted higher reliability, so a lot of work is off-loaded from the chief editor/editors. Again, I don't say this is perfect, but I do think that if done right (and improves with time) this can increase the reliability factor for most articles. I do believe it will bring Wikipedia to a better position than it is today in the area of reliability (currently it basically has nothing...)

Fact fields? What good do they make, say, in Israeli-Arab conflicts? Or a biography? Dates are the same, numbers are the same. NVO (talk) 18:08, 29 May 2009 (UTC)

Biography consists from a set of facts. It can be teared down to many specifics. It has dates, names, numbers, etc. Each such datum can be marked as a fact field. This means that every change in that field would yield a change of fact, which is usually bad, so the reliability factor would decline. And regarding the Israeli-Arab conflicts? Well, nothing gonna help there... (I say that as an Israeli).

Italicise watchlist redirects

Every so often I go through my watchlist (in the "View and edit watchlist" screen) and pick out the things that I don't need to watch anymore. I would find it useful if redirects would show up there in italics, as they do in categories and allpages. It might, in fact, also be useful for redirects to show up in italics on the regular watchlist. Any thoughts? bd2412 T 11:18, 29 May 2009 (UTC)

Try User:Anomie/linkclassifier.js; highlights redirects (among other things) everywhere. Happy‑melon 16:32, 29 May 2009 (UTC)

display time since last edit on article

I propose that the approximate amount of time since the last time an article was edited (i.e. "last edited (5 minutes or 3 hours or 20 days etc) ago") be displayed somewhere on the article where it may easily be viewed. This would be useful (1) for seeing how current an article about a recent event is, and (2) as a metric for gauging the reliability of the current version of an article, using the assumption that articles that have not been edited for a while can be considered "stable" and are less likely to have vandalism or other issues. Thus, a savvy reader could look and say: "Oh, this article was last edited 5 minutes ago, I should check the page history to ensure the edit was not vandalism before relying on the information here", or at the least "This was edited just 5 minutes ago; I should be more wary about the accuracy of the article as it could be vandalized". As for placement, I would suggest on the same line as the title, but right-aligned and in smaller font, but this is obviously quite open to suggestion.

As to why this would be better when we already give the last modified date at the bottom of the page (1) it's at the bottom of the freakin' page and not very visible at all (2) for readers who don't login, it gives the datetime in UTC, which can be a pain to convert (3) the date is just plain less convenient compared to a time elapsed figure. --Cybercobra (talk) 12:17, 29 May 2009 (UTC)

It says UTC though oddly enough it's actually still based on your prefs. This of course doesn't mater if you'r not logged in. Still, I think using "how long ago" to determine reliability isn't a very good thing to do. Vandalism can stick around for a long time, even years, if it's subtle enough. ♫ Melodia Chaconne ♫ (talk) 13:24, 29 May 2009 (UTC)

I see that, there are counter-examples to using time since last edit as a definite gauge of reliability, but nobody is suggesting that. They are suggesting that there is a positive correlation, which there is. And they are saying that this is an advantage. Which it is. Now even if there wasn't a correlation, that lack of correlation would not be a bad thing. The time of last edited is already shown, and that is clearly not correlated w/reliability, yet you don't argue that it's lack of correlation w/reliability is reason for its removal. Kevin Baas^talk 15:10, 29 May 2009 (UTC)

I like the idea of showing how long it's been since the last edit. I can see many advantages, and no disadvantages, save using up a tiny bit of space on the screen. Kevin Baas^talk 15:10, 29 May 2009 (UTC)

Caching could be a problem with this... for example, {{underconstruction}} has a "last edited" counter built-in, but it is usually out of date. 5 hours after the last edit it may still say "3 seconds" or something because the page's cache hasn't been purged. I don't know enough about the MediaWiki software to know if this could be fixed, but its just something to think about. –Drilnoth (T • C • L) 15:37, 29 May 2009 (UTC)

We could parse the "last edited at" timestamp with JavaScript and convert it into a relative time. Won't help those without JS, of course... Happy‑melon 16:27, 29 May 2009 (UTC)

Regarding performance concerns, there is Wikipedia:Don't worry about performance to consider, though even I would still be wary as to the impact if this change were to be made, but that's more a question for the devs to look at if the proposal manages to get that far, so we shouldn't concern ourselves with performance worries yet. --Cybercobra (talk) 17:00, 29 May 2009 (UTC)

The incorrect "UTC" label was added to the message last month. I just removed it. —David Levy 17:16, 29 May 2009 (UTC)

But now it doesn't show "UTC" for non-logged-in readers... --Cybercobra (talk) 17:54, 29 May 2009 (UTC)

That's a matter for the MediaWiki developers to address. In the meantime, slight ambiguity is vastly preferable to absolute incorrectness. —David Levy 18:03, 29 May 2009 (UTC)

True, but are the devs even aware? --Cybercobra (talk) 18:06, 29 May 2009 (UTC)

I didn't see a Bugzilla entry, so I filed one. —David Levy 18:41, 29 May 2009 (UTC)

DISPLAY all edits

Every article should be displayed in its original form, then any changes should be highlighted in color beneath the original article, similar to a blog. If that takes too much bandwidth, or for whatever reason is not possible, changes should be stored, then users should be able to click on a SHOW EDITS link that will then reveal all changes made to an original article, and either the editor and/or their source, and the reason they made the change (such as: "I was an eye witness, thats not the way it happened," or, "I am the subject of this biography, I would know..," or, "Just correcting a typo...")