Jump to content

Wikipedia:Village pump (proposals)/Archive 28

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

The Problem with the Undo Button

You may have noticed that vandals do their work in segments: instead defacing the article to their liking in one edit, they do it in several consecutive edits. This may be because they are sloppy, or because they come up with another idea for defiling the article, or because they edit by sections. Or it may be because they don't understand how Wikipedia works. Or it may be the opposite: they do it because they do know how Wikipedia works.

If a vandal edits in segments, they pretty much make the "undo" button useless. If you undo their most recent edit, all you're doing is going back to another vandalized page. And you can't undo edits before the most recent one. The only option is the clumsier way: clicking history, then choose a version, then click edit, then click save.

What if we made it so that you can undo ALL the edits that a vandal has made in a row? For example, let's say that vandal A vandalizes page B. The a responsible user C reverts his edits. So the vandal does it again, but this time does it in two steps. Where before you would be forced to take the hard way, now you simply click "undo" on the first edit A made after C reverted his first edits.

Easier, yes?-Link (talk) 19:26, 6 June 2008 (UTC)

there already exists ways of doing that, a revert, or, if you have the right to do so, a rollback, both of which do what you're suggesting.--Jac16888 (talk) 19:32, 6 June 2008 (UTC)
As does Twinkle|. --—— Gadget850 (Ed) talk - 23:04, 6 June 2008 (UTC)
If there have been no constructive edits since the start of a sequence of vandalism edits, you can click on the latest good version of the article, edit the whole article (but not make any changes), and save it. I believe this is the recommended solution. --A Knight Who Says Ni (talk) 17:38, 7 June 2008 (UTC)

Navigational popups also let you do this, by hovering over a past revision's link and clicking revert. ╟─TreasuryTag (talk ╬ contribs)─╢ 17:39, 7 June 2008 (UTC)

Problem with Special:Prefixindex

Currently, it seems that Special:Prefixindex displays pages beginning with the text you enter, regardless of whether it is a subpage of the page you specified. For example, when you go to Special:Prefixindex/User:Anon, which is the equivalent of specifying User:Anon (no longer exists), you see userpages beginning with "User:Anon," like User:Anon! and mine, User:Anon126. I think this should be changed to show only subpages of the page specified. Anon126  (talk - contribs - commons - commons talk - commons contribs) —Preceding comment was added at 05:41, 7 June 2008 (UTC)

It has always done this. It simply displays pages beginning with the text you enter; restricting it to subpages would prevent uses such as Special:Prefixindex/List of to see all pages beginning with "List of" -- Gurch (talk) 05:50, 7 June 2008 (UTC)
If you want subpages only, just add a / to your query. Algebraist 10:01, 7 June 2008 (UTC)

Addition to 'this page in other languages'

When looking up a subject, the site shows a box in the bottom left with other languages in which the article is available. If you're looking for every single bit of information you can get, and you can read multiple languages (I, for instance, took English, German and French in highschool, and thus have little trouble reading most European languages) it would be useful if aforementioned box would show the size of an article. Simple example: I'm looking for information on the German Sicherheitsdienst. I first read the Dutch article and wonder if the article in other languages has more information in it. The box lists the articles as follows: Dutch - 200 words, German - 300 words, English - 100 words,

--Max, 81.69.110.161 (talk) 23:56, 7 June 2008 (UTC)

Word count would be difficult because of the intricacies of wikitext and templates, but something like WP:POPUPS for interwiki links (if popups doesn't already work for interwikis) might be an interesting idea for a user script. Mr.Z-man 03:51, 8 June 2008 (UTC)

New Article Creation "Holding Area".

How about instead of just letting everyone add article willy nilly, there exist a process by which new articles are automatically created in a users space. An editor can then, at their leisure but for a limited time, begin the creation process. After the new article has been created to the original editors liking, he can then choose to have that article sent out to the "baby article" log, where it can be viewed by his peers. At this point the new article is still not "published" but in a limbo area were consensus can be reached as to the readiness of the new article to be released into the wild. Reviewers can also suggest changes (or make it themselves) according to the current process.

This new method of article creation would eliminate much of the current hostility and needs for "damage control" by administrators while at the same time giving new articles a chance to grow and be useful to the using public. If at the end of a pre determined and documented time (provided at the top of every new article) an article does not receive a positive consensus to "keep", it is removed from the database with a copy automatically emailed to the original creator. Everybody wins! I think its a great idea, how about you? Snottythetroll (talk) 07:28, 2 June 2008 (UTC)

Good in theory, but doesn't work in practice, I think. This scheme sounds awfully like Wikipedia:Articles for creation. As I have heard, it has a huge backlog, which is still growing. The problem with this kind of reviewing mechanism is that the number of creators significantly outweighs that of reviews. A post-filterling system as opposed to a pre-filterling system seems like the only option we have. -- Taku (talk) 09:41, 2 June 2008 (UTC)
I suspect most seasoned editors develop articles in userspace and move them to articlespace when ready. Perhaps the Article wizard should be developed and promoted for new editors. Not perfect, but probably better than many of the new articles. --—— Gadget850 (Ed) talk - 15:21, 4 June 2008 (UTC)
Moreover, it would create a whole new breed of lawyering about whether an article is "notable" or not, with the respective sides of that never-ending argument looking out like hawks to kill or defend. I think WIkipedia already has a big enough problem with talk page buzzards picking at and complaining about articles. SiberioS (talk) 08:19, 9 June 2008 (UTC)

I have no idea if anyone has proposed this before (and if its a good proposal it should go to meta to be put on all Wikimedia projects, actually, why not integrate it into MediaWiki?) but I think this would be an excellent idea for all Wikimedia projects.

When looking around Wikipedia related discussions, you always see this[1] kind of external link linking to part of Wikipedia itself; a previous version of a page. Now I personally think that that is a bit clunky, I mean, using an external link to link into Wikipedia itself? It should be much more smoother.

So I propose that instead of external linking we create a new namespace (or more accurately, an interwiki redirect called maybe diff:, prev: or edit:, I'm not fussed) and then when linking to a diff we use that namespace and the page id instead. Now many people right now may be going huh? and scratching their (hopefully) computer literate heads so I will endeavor to explain how this would work.

NOTE: Throughout this I will be using the diff: namespace/redirect as an example, this can be substituted for whatever you think is the best; its not permanent.

Ok, say X wants to show someone a previous version of a page he made, he could

  1. type out (or copy/paste) http://en.wikipedia.org/w/index.php?oldid=3432489 and shove some [ and ] outside it and give it to his friend, or
  2. simply type (or copy/paste) [[diff:3432489]] or [[diff:3432489|name of link]]. That would give a direct link to the old page in question without having to type all of the Wikipedia address. It would even work cross project e.g. to meta [[m:diff:3432489]].

Now that is all well and good for just a single id, but what if you want to compare (diff) fuction? Well, I have thought of an idea for that too. All you'd do is something like [[diff:left column id-right column id]], I'm not fussed about what symbol separates the left column id and the right column id. And to help users who would just copy/paste the url of the diff/oldid in question, in the heading of older pages (in this case "Math rock") it would say "Math rock (diff:3432489)" or if your comparing "Math rock (diff:left column id-right column id)".

Now I have a feeling people will say Why do we need this kind of thing?, well I thought of several reasons,

  1. when search engines come to Wikipedia and try to index the pages, if they come across an external link they get hit with the robot.txt NOFOLLOW tag (meaning that the robot will not go into that link and check out that file) and;
  2. I just think it makes more sense, I mean, when linking to anything else internally we use [[page]], [2] tags have be adopted as the defacto diff linking system, they should follow the conventions that all other internal links follow.
  3. It reduces the clutter when listing many links on the same page.

ADITION TO PROPOSAL: Possibly move the diff access link from an index.php paramenter (e.g. /w/index.php?oldid=344&diff=45354) to the wiki space (e.g. /wiki/diff:344-45354).  Atyndall93 | talk  01:12, 8 June 2008 (UTC)

Feel free to change as you wish; I am open to improvements. Thankyou for listening. Happy editing!  Atyndall93 | talk  05:38, 7 June 2008 (UTC)

  1. Diffs and oldids are already deliberately excluded from search engine results regardless of whether a link has nofollow attributes by robots.txt which blocks everything in /w/ and by meta tags in the page.
  2. Regardless of the form of the link you're still going to have to copy and paste something containing a horrible oldid. I wouldn't object to a template which expands the oldid parameters to a working URL, the code to which could be displayed for copying on the diff page, but the extra bloat on those pages might not be worth the savings in editbox bloat.
That's my opinion. BigBlueFish (talk) 15:47, 7 June 2008 (UTC)
The idea's neat, though in implementation this might be tricky, as it is not only diff id that matters but also oldid, and there are always the special cases. For example, diff=9&oldid=5 shows the difference between revision 5 and revision 9, whereas diff=prev&oldid=5 shows the difference between revision 5 and the previous revision for that page (as revision ids are not contiguous for the same page) with a similar difference for diff=next and I'm not sure how we'd integrate the syntax considering those variables as well. Nihiltres{t.l} 16:38, 7 June 2008 (UTC)
With my idea diff=9&oldid=5 would be something like [[diff:5-9]] and diff=prev&oldid=5 would be [[diff:prev-5]].  Atyndall93 | talk  01:12, 8 June 2008 (UTC)
Turns out a shorthand is available as {{diff}}. Since search engine indexing is not wanted for oldids, I see no reason to change the URLs; a preconstructed code for the diff template on the diff page itself might be useful if there's demand. BigBlueFish (talk) 17:41, 7 June 2008 (UTC)
That template still uses external linking (with the plainlinks class) though I I think its a bit clunky.  Atyndall93 | talk  01:12, 8 June 2008 (UTC)
I don't have any advice on the technical details of how to do this, but I do agree that something should be done. The current system of entering a whole URL is awkward, and I would prefer to point to a diff using an in-line citation instead of a superscript. --A Knight Who Says Ni (talk) 17:50, 7 June 2008 (UTC)
  • It's a nice idea in theory, I suppose, but it'd create a huge trashyard of diff: namespace pages that would never ever be referenced. I think we're up to something like 50 or 60 million total edits so far. How many of these are likely to be referenced? -- Anonymous DissidentTalk 18:06, 7 June 2008 (UTC)
    The word "namespace" is confusing - the proposer is suggesting something more along the lines of a specialized interwiki that would link to wikipedia diffs, much the way that we have a special interwiki for Google searching. {{Nihiltres|talk|log}} 18:58, 7 June 2008 (UTC)
    Yes, it wouldn't actually create the pages, but it would appear that way.

It sounds good on the surface, but BigBlueFish makes a good point. Which is easier? Copy and pasting a URL or using an interwiki, which would mean copying the oldid and the diff oldid separately? The diff URL also has the context of the page title in it usually. Mr.Z-man 03:49, 8 June 2008 (UTC)

In the proposal I suggested having the title show "Title (wikilink for diff/oldpage)" type thing where the text in the brackets is the relevant wikilink for that diff or old version of a page. E.g. (diff:3493-3433) means that its comparing oldids 3493 and 3433. So you wouldn't have to copy/paste the oldids separately as when viewing a comparison page both are listed in the correct format, so you just copy/paste the stuff listed in the brackets (it could be placed anywhere on the page really). e.g. if you typed [[diff:3493-3433]] you would get that exact comparison. And in reply to the context of the links, the actual page name is irrelevant (if you remove it from the link, the link still works) and if you wanted to show name that link you could say [[diff:3493-3433|oldid of random page]] which has the same level of context as a normal diff because normally a [ ] type link just shows up as [3], if you want to name it you have to type in the name next to the link. You could also have a tooltip appear with the page name when hovering over the diff link.  Atyndall93 | talk  07:32, 8 June 2008 (UTC)
What I mean is, when making a normal diff, I type a bracket, paste the URL, then type whatever text I want to appear, then another bracket. To do it as an interwiki-type link, I have to type 2 brackets, then "diff:", paste in the URL, delete all the parts I don't need, add the hyphen, then the pipe and the text I want to appear. It just seems like a lot of extra work for minimal benefit. What I meant by the page title in context, is that when hovering over a link, I see the full URL of the target in the status bar in my browser. Unless this looks up the title associated with the oldid and adds it to the link when parsing, all I would see is http://en.wikipedia.org/w/index.php?oldid=12345&diff=23456. Mr.Z-man 16:26, 8 June 2008 (UTC)
With my proposal you don't copy the url at all, in the title it says something like "Title of Page (diff:whatever)" so instead of copying the url you copy the text in the brackets and whack and around it, we could even make it so the title says "Title of Page ([[diff:whatever]])" so really all you have to do is pipe the link (and with my first proposal add [[ ]] around it. I would recommend the parser is set to show something like "Page Name (diff:whatever)" in a tooltip, thus keeping it in context. So with my proposal you just have to add two more characters (an extra [ and ]) and remove about a hundred from pasting the url.  Atyndall93 | talk  03:16, 9 June 2008 (UTC)
The title isn't really the main issue I have with it. You still need to get the 2 oldids from somewhere. You have to type them from memory, copy and paste them from the URL, or copy and paste the whole URL and remove everything except the oldids, all of which are more work then just copying and pasting the URL. If the only benefit is that the edit page will be slightly cleaner, I really don't see how this is worth the extra work that would be required. Mr.Z-man 05:41, 9 June 2008 (UTC)
Hmmm, I don't think you understand what I'm trying to say, but thats fine, I sometimes word things incorrectly. The oldids in the exact format they are needed to be in to be linked to (e.g. diff:342094-3234234) are listed in the title of the page so you can just copy paste that stuff instead of the url (and just put double [ around them). I'll see if I can make an example animation or something if I have time.  Atyndall93 | talk  10:49, 9 June 2008 (UTC)
So is the purpose of this to save space in the editbox by changing the length of the string that you copy/paste? In which case, why not put code in the form {{diff|Main Page|204901573|202506579}} on the page? BigBlueFish (talk) 12:04, 9 June 2008 (UTC)

(outdent) The purpose of this is to same space in the edit box, to use [[ ]] style linking; keeping it consistent with the rest of internal links and to stop using external links for posting diffs (as {{diff}} does) as I (and other people) thing that it is clunky etc. If people are for the change, it would be easy enough to implement I think.  Atyndall93 | talk  12:23, 9 June 2008 (UTC) My proposal also includes putting a kind of premade diff link in the title in brackets, for more information check the previous posts.  Atyndall93 | talk  12:25, 9 June 2008 (UTC)

SIZE guidelines

Please see the proposal at Wikipedia talk:Article size to update the article size guidelines, in particular to use industry standard word count instead of character count. Oakwillow (talk) 18:27, 8 June 2008 (UTC)

Innovation

My name is Jay Shah and I would like to share a new innovative game (or rather say a challenge) that can be easily played on WIKIPEDIA.I call this as "wikiLINKIA challenge" or simply "wikiLINKIA".It goes like this that a player is given a particular article and he will be given a target article and the player has to reach the target article using minimum links provided right from the given in the article.It may seem very difficult to understand just from one sentence and hence let's consider this example: suppose a user is given the article of RMS TITANIC and his target is WORLD TRADE CENTER.So the user may link his target via NEW YORK CITY as RMS TITANIC was bound for NEW YORK CITY and finally to his target since WORLD TRADE CENTER is located in NEW YORK CITY.I hope I have roughly put on the concept of my game to an image.This example was just a basic one to justify my game.This game can be more exciting since we can restrict either the minimum links clicked to reach the target and the shortest link pathway to the target.I have been playing this game by my own self and even trained my younger sister to play it and now she says she loves this game as it is exciting, interesting.Me and my sister would play side by side on a particular wikiLINKIA challenge and our game would last from five minutes to once even a week and the winner with minimum number of link pathways would be the wikiLINKIA champion.And we would feel very proud to be associated WIKIPEDIA or BEING called as a champion.My DAD who had once tried this game also said that this game can certainly help one to envisage one's vision and tests one's wit and association power to link one thing with the other.Alas I would say that this can be fun and a high level challenge which can be played on well established platform of WIKIPEDIA articles.There is much more to discuss about this game.I will even try my level best to submit the video demonstration as soon as possible.So members please look forward onto this. —Preceding unsigned comment added by EnSYS (talk • contribs) 17:02, 9 June 2008 (UTC)

Welcome to Wikipedia! You might be interested in Wikipedia:Six degrees of Wikipedia, in particular the website that it links to, Omnipelagos. BigBlueFish (talk) 21:14, 9 June 2008 (UTC)
??? - Caribbean~H.Q. 21:17, 9 June 2008 (UTC)
I... dislike... capitals... Waltham, The Duke of 21:43, 9 June 2008 (UTC)

New proposal for Discography sections at WikiProject Musicians

Please take a look at this proposal and express your support or objections. Keep in mind we currently have no guidelines for Discography sections whatsoever, so this would at least be a start. Kaldari (talk) 18:15, 9 June 2008 (UTC)

Liberapedia

May I propose for creation of an external link template which will link to that article in Liberapedia? Otolemur crassicaudatus (talk) 18:12, 8 June 2008 (UTC)

From a quick glance at that site I don't see much benefit of creating a link template. Garion96 (talk) 18:16, 8 June 2008 (UTC)
Though it is helpful, liberapedia is not exactly joke site like Uncyclopedia. It documents real information, and in many cases with references. Otolemur crassicaudatus (talk) 18:20, 8 June 2008 (UTC)
It is not by any standards a reliable source. If it can be used by editors as a research tool to locate adequate sources then great, but Wikipedia does not have a large-scale need to link to this site. Not even massively referenced sites like the BBC News have a link template. BigBlueFish (talk) 12:27, 9 June 2008 (UTC)
Do we have templates for other non-Wikipedia-related sites? Corvus cornixtalk 17:01, 9 June 2008 (UTC)
A good, good many, in fact; see Category:External link templates, which happens also to note (or at least to purport to note; I don't know that criterion two, in particular, is one that we generally follow, and I don't know that it, to the extent it fails to distinguish between those sites that are linked to as sources for substanive material, to which RS would generally apply, and those sites that are linked to merely for their being prominent sites that comment, notably, on a given topic, should be one that we follow) the criteria that the community have generally used to determine whether an external link merits a template, as might be relevant here. Joe 06:45, 10 June 2008 (UTC)

Restrict the "move subpages" feature to admins

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

This idea has been bounced around the noticeboards ever since the "move subpages" checkbox, sometimes referred to as the "recursive move" feature, was added to MediaWiki in rev:33565. The ability to move a page, its talk page and up to 100 subpages all in one action, has been quickly seized upon by a number of pagemove vandals (see 1, 2, 3, 4). With careful choice of targets, the feature enables a vandal to move up to 800 pages before hitting the pagemove throttle, which is supposed to limit non-admin users to 8 moves/min. There has been discussion in various places (1, 2) about restricting this feature to administrators only, and in rev:36038 Simetrical added the technical means to do this. What do we think? Happy‑melon 19:54, 8 June 2008 (UTC)

Restrict it to admins. The feature is virtually useless here (it was added at the request of Wikibooks, not Wikipedia) - the only people who are going to have a need to move subpages on a regular basis are bureaucrats when changing usernames (and they will be unaffected by a change as they are all admins). Hut 8.5 20:04, 8 June 2008 (UTC)

Restrict it to admins, clearly. There are way too few cases where it would be useful for individual users to need this here. —Simetrical (talk • contribs) 21:16, 8 June 2008 (UTC)

Restrict it to admins, the uses here are so few (the only thing I can think of would be moving an article where the talk page has archives, which doesn't happen often), there's no need for almost all users to have this. Mr.Z-man 23:03, 8 June 2008 (UTC)
Support the restriction--I found it hard to believe this was available generally. If Wikibooks wants to use it more generally, they can do so. DGG (talk) 04:46, 9 June 2008 (UTC)
Too easily abused, much harder to revert than to do. Restrict it to admins, and possibly bots. 1 != 2 23:05, 8 June 2008 (UTC)
Support I've moved plenty of pages, but never needed to simultaneously move a subpage at the same time (sometimes I'm had to move an article talk page archive, but that's no big deal). I suggest restrict to admins. AndrewRT(Talk) 00:03, 9 June 2008 (UTC)
  • Support it looks like it is being used more often for vandalism than for anything useful. Occasionally there are good reasons for subpages to be moved, but not very often, and it would still be possible, only it would take more time, if this was restricted. --Snigbrook (talk) 11:52, 9 June 2008 (UTC)
  • Support and urge the devs to deploy this restriction as quickly as practical. There is no compelling reason for non-admins to have this tool and the use for vandalism is a "clear and present danger" as they say. Gwernol 12:16, 9 June 2008 (UTC)
  • Support, though I want to clarify that this would only apply to the recursive "move subpages" function; non-admin users could move individual subpages in the normal way, just as they always have been able to. If there is a need for some non-admin use (renaming a page with lots of talk page archives, or what-have-you), then WP:RPM would be the appropriate forum - and even then, I imagine the response would be to do it manually or send a bot to do it. UltraExactZZ Claims ~ Evidence 12:20, 9 June 2008 (UTC)
  • Support. This feature has a clear pattern of past abuse. The rare times on this project when there is a legitimate need to move a hierarchy of subpages can be handled by Wikipedia:Requested moves. --Allen3 talk 12:28, 9 June 2008 (UTC)
  • Submitted as T16482; but comments are still welcome, as the developers will read this thread before making any changes. Happy‑melon 12:39, 9 June 2008 (UTC)
  • Support - please make this change ASAP. Neıl 龱 12:47, 9 June 2008 (UTC)
  • Support, too much vandalism. MaxSem(Han shot first!) 13:55, 9 June 2008 (UTC)
  • Support, definitely - I've just blocked another vandal who has found this feature useful. :-) Stwalkerster [ talk ] 13:58, 9 June 2008 (UTC)
  • Support just to help to demonstrate to the devs that there's a consensus for this. --ais523 14:05, 9 June 2008 (UTC)
  • Strong support and move to snowball close as endorsed. It takes way too much work to cleanup after this type of vandalism. Users requiring recursive moves can apply to WP:RM. (oops, just noticed this was already bugzilla'd - support nonetheless) xenocidic (talk) 14:08, 9 June 2008 (UTC)
  • Support will certainly be of benefit when clearing up vandalism. -- Anonymous DissidentTalk 14:59, 9 June 2008 (UTC)
  • Support, too powerful. It's possible to revert when the main source page has not been modified after the move, the subpages whose source haven't been modified are moved over redirect. But it's not possible to reverse a move like this when the main source page has been modified. So each subpage has to moved back individually. And even if the source page is not modified, the amount of work and the time needed to cleanup this kind of vandalism is too high compared to the benefit. Cenarium (talk) 15:05, 9 June 2008 (UTC)
  • Support I didn't even know this feature existed. The uses of this are rare (the only instances that springs to mind is a WikiProject that renames itself or moving entire talk page archives but these are still rare situations) and can easily be requested elsewhere. This feature is too powerful to let just anyone use. --.:Alex:. 15:21, 9 June 2008 (UTC)
  • Support - After cleaning up in the wake of a large number of vandalistic page moves, I was thinking that move subpages should be locked down because it has the potential to cause a lot of damage that cannot be reverted as easily as it was caused. Chrislk02 Chris Kreider 15:25, 9 June 2008 (UTC)
  • Support - I'd personally support pagemoves in their entirety being admin-only, but this is a good start. No need for people to do mass moves like this. Tony Fox (arf!) 16:16, 9 June 2008 (UTC)
  • Support. I can't imagine that this feature would be used very much, and if it was needed, it is very easy to ask an admin to do it for you. Or, if there were just a few subpages (less than 8), a non-admin could just move them manually. J.delanoygabsadds 16:36, 9 June 2008 (UTC)
    As to how you contact the devs, when the non-admin rollback throttle removal thingy was discussed, I spammedmessaged the devs on IRC, but I can't remember which channel I used. J.delanoygabsadds 16:48, 9 June 2008 (UTC)
  • Support - the possibility that this has for abuse and vandalism outweighs the its benefits. It's easy enough to ask an admin to move subpages at once if required. RichardΩ612 Ɣ ɸ 16:46, June 9, 2008 (UTC)
  • Strong support - I have personally had to clean up messes made by this feature and it is not fun. Tiptoety talk 18:25, 9 June 2008 (UTC)
  • Support, evidently.  Sandstein  20:36, 9 June 2008 (UTC)
  • UPDATE: This proposal has (apparently) been passed for now. —Wknight94 (talk) 21:16, 9 June 2008 (UTC)
  • I support this: at the moment, I've seen nothing but abuse from this feature, and limiting it to admins should eliminate that abuse. Acalamari 23:43, 9 June 2008 (UTC)
  • Support Looks like it's been restricted for the moment, but I'd like to voice my support for enabling it permanently. It's a reduction of editor abilities that has a positive cost/benefit breakdown between allowing people to edit and protecting the project from vandalism. EVula // talk // ☯ // 23:47, 9 June 2008 (UTC)
  • Oppose, I'm not an admin and I find this could be useful. If we can restrict editing of pages to established users, surely we can restrict moving subpages to established users. Failing that, we should allow for mass deletions of pointless subpages. --M1ss1ontomars2k4 (talk) 03:00, 10 June 2008 (UTC)
    • We don't restrict editing to established users, we can restrict it to autoconfirmed users, which is users whose accounts are 4 days old and have 10 edits, which was also the same restriction that was originally used by this feature. Mr.Z-man 03:43, 10 June 2008 (UTC)
  • So...so disappointed that good features that help editors whenever a page move is performed, has to be taken away from those who do not abuse it. — Moe ε 03:30, 10 June 2008 (UTC)
    • How often do you need to move a page with subpages? Mr.Z-man 03:43, 10 June 2008 (UTC)
      • Well, if there was a situation where a article and its talk page (with archives) needed to be moved, the feature would help move the archives to the new basename. Other than that, moving subpages of your own userspace, which is what I did about 5 days ago, the tool was very helpful to me. Other than that..there aren't many more situations where subpages are used on Wikipedia. The only other thing I can think of is if something like WP:AN (for example) was moved with consensus, and archives were moved with it. That feature might do some good, but the with the limited number of pages like that, the chances of a normal user doing it are pretty slim. — Moe ε 03:53, 10 June 2008 (UTC)
        • I don't think it's technically possible to move WP:AN. There are several hundred subpages.—Ryūlóng (竜龙) 04:50, 10 June 2008 (UTC)
          • True, I meant that as an example, but you know what I mean. All that aside, something I would actually support is, instead of restricting the 'move subpages' feature to admins, restricting the number of pages moves that could be performed with a single click. Like if the page has 4 or more sub-pages, an administrator or higher only has access to mass move that many sub-pages, but when its 3 or less, a normal user can use the feature. This would certianly reduce in the number of incidents with abuse of the tool, if abuse was to occur, the damage would be minimal, and the feature would still be available to those like myself who use it on a small-scale. — Moe ε 06:17, 10 June 2008 (UTC)
  • Support - maybe make it a 'trusted', userrights option similar to the AccountCreator option. Pagemove vandalism can be just overwhelming at times - Alison ❤ 09:53, 10 June 2008 (UTC)
  • Oppose useful feature, disappointing discussion. Guest9999 (talk) 10:45, 10 June 2008 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

non-copyrighted restricted images

I have opened the discussion on non-copyrighted restricted materials again at the Non-free content talk page. In the past this issue has annoyed me severely, and I was told that we would take care of it after the issues with copyrighted materials had been dealt with. Well that is all done now and as such I think the time has come to fix this unclarity. According to current Foundation policy, materials like images need to be "free for usage", but many non-copyrighted materials are not (trademarked logos, military insignia, flags etc etc.). There seems to be a general "exception" for these materials, but there is no real basis for this in the Foundation resolution or our Exemption Doctrine Policy. The General Disclaimer speaks about trademarks in general (including textual trademarks in our articles), but I do no see how this exempts the images from the Free Content Licenses as defined by the "Definition of Free Cultural Works", as adopted by the Foundation. It is my hope, the discussion will be our start to getting this sorted out once and for all. --TheDJ (talk • contribs) 11:20, 10 June 2008 (UTC)

Easier access to Special:Listusers

It could be that I'm just missing this, but I'm looking for a way to very easily and quickly check the rights of any user. I'm finding this more and more necessary as more user groups are created (Accountcreator, IPexempt...) - so what I'm imagining is either a link in the toolbox from a user or user talk page, or just the user's listuser entry at the top of their log page. Unless, of course, there's already some easy way to access this. Alex Muller 11:33, 10 June 2008 (UTC)

This can be easily done with JavaScript, unless you think this should be in everyone's toolbox. Algebraist 11:37, 10 June 2008 (UTC)
Oh, really? In that case, would you or someone else mind sharing how... my Javascript-foo isn't what it should be ;) Alex Muller 11:44, 10 June 2008 (UTC)

This will add it to the toolbox when you view somebody's user or user talk page. Of course adding it elsewhere would require more code. 

addOnloadHook(function(){
  if(wgCanonicalNamespace[0] != 'U') return; t = 'Userrights';
  url = wgScript + '?title=Special:Listusers&limit=1&username=' + wgTitle.replace(/\/.*$/,'');
  r = document.createElement('li'); a = document.createElement("a");
  a.setAttribute("title", t); a.setAttribute("href", url); a.innerHTML = t;
  r.setAttribute('id', 't-' + t); r.appendChild(a);
  u = document.getElementById('t-upload');
  u.parentNode.insertBefore(r, u); 
  });

— CharlotteWebb 15:43, 10 June 2008 (UTC)

Many thanks Charlotte, that's perfect - really, exactly what I wanted... it's going to be incredibly useful for me at least, and hopefully others as well. Again, thank you :) Alex Muller 17:08, 10 June 2008 (UTC)
Well I just realized it will fail for users whose name contains "&" but I think it will work for all other allowable names. Also I chose to put it before the "upload" link because this link will always be present. Trying to put it above the "block" link (or the "contributions" link, etc.) will cause an error if you are on the page of a non-existing user. I think this will only be a noticeable problem if you rely on other scripts to load properly after this one, but adding if(u) to the beginning of the last line would fix it. — CharlotteWebb 17:52, 10 June 2008 (UTC)
Ah, but it will still fail (albeit without an error) for anybody who doesn't have a "block" button and tries to copy your version. — CharlotteWebb 17:58, 10 June 2008 (UTC)
I have a sysop detector that Splarka wrote a bit ago. It changes the user page tab to read (sysop) when the user is a sysop. (Even when the sysop doesn't have a user page.) You can import it from User:Splarka/sysopdectector.js. --MZMcBride (talk) 18:22, 10 June 2008 (UTC)
Maybe I should adapt that to appear in page history, recentchanges, watchlist, etc. as a big red conspicuous "do not revert" warning. Seriously though I did once try to do something with "XMLHttpRequest" on one of my own sites but it kept getting refused by Firefox as a security problem (I don't remember the actual error message). — CharlotteWebb 18:50, 10 June 2008 (UTC)
Simpler (and works for all usernames):
addOnloadHook(function () {
    if (wgNamespaceNumber != 2 && wgNamespaceNumber != 3) return;  // User or User talk only
    var user = wgTitle.split("/")[0];
    var url = wgScript + "?title=Special:Listusers&limit=1&username=" + encodeURIComponent(user);
    addPortletLink("p-tb", url, "User rights", "t-userrights", "List of user groups for " + user);
});
This code adds the link to the bottom of the toolbox. If you want it placed earlier, you need to pass additional parameters to addPortletLink() — see the comments for that function in wikibits.js. —Ilmari Karonen (talk) 18:29, 10 June 2008 (UTC)
Or even simpler:
importScript("User:Ilmari Karonen/userrights.js");
:-) —Ilmari Karonen (talk) 18:33, 10 June 2008 (UTC)
Ah I wasn't sure if split would work in the more common case where there is nowhere to split, hence the unsightly regex. — CharlotteWebb 18:50, 10 June 2008 (UTC)


Another really good script that I use is User:Ais523 non-admin/adminrights.js which lightly highlights the names of any sysop on wherever their name appears. This is good because it saves you the step of having to click buttons to see if they're a sysop. I'd recommend at least a try. -- penubag  (talk) 03:40, 11 June 2008 (UTC)

Use the Geotag Icon in association with coordinates

Wikipedia currently use a little globe icon to indicate GPS coordinates e.g. here:

http://en.wikipedia.org/wiki/Empire_State_Building

The globe currently in use is indistinct and not location-specific, since globes are used in a variety of other contexts. The community-designed and free Geotag Icon has been created expressly for better illumination of geodata:

http://www.geotagicons.com

It is appropriate for geotagging using any format (meta data, microformats, EXIF-GPS, etc) and has been added to the microformats.org icons page:

http://microformats.org/wiki/icons

The information on the Project website is comprehensive and self-explanatory, but if I can answer any questions or be of other assistance please don't hesitate to get in touch.

Project Coordinator: Bruce McKenzie The Home of the Geotag Icon Project www.geotagicons.com —Preceding unsigned comment added by 85.152.18.129 (talk) 14:00, 11 June 2008 (UTC)

What should be done with Wikipedia:Articles requested for more than a year?

Should it be moved to Wikipedia:Articles requested for more than two years? Should it be converted to a category along with Wikipedia:Requested articles? Something else entirely? All comments are welcome at Wikipedia_talk:Articles_requested_for_more_than_a_year#Requested_move. shoy 15:08, 11 June 2008 (UTC)

en.wikipedia.mobi

When accessing Wikipedia from a cell phone, it takes several minutes to scroll down to the log in button and uploading images is nearly impossible (if it's not impossible). Wouldn't it be great if there was a mobile version of Wikipedia so that people could more easily upload images, edit pages, and read articles? Now I realize that the cell phone user would not have much reason to edit pages from a cell phone (unless they were just fixing a spelling error, or, at worst, vandalizing), but I think it would be great if there was a mobile version of Wikipedia for uploading images, possibly including them in articles, and of course, reading articles. As far as uploading images, another possible venue would be to create a short code so that images could be sent as a picture message so that cell phone pictures could be used in articles. I know a work around for this problem: I send cell phone pictures to my email address and then upload them from my computer, but a lot of people, probably including many experienced, good faith Wikipedia contributers, don't know how to do this, and it's not always convenient. GO-PCHS-NJROTC (Messages) 17:37, 11 June 2008 (UTC)

See Wikipedia:WAP access for a bunch of options, and this current thread at Talk:Main Page#WAP version. Might help? -- Quiddity (talk) 19:28, 11 June 2008 (UTC)

Automatic generation of reference information from URL

Providing references is one of the most important tasks of any editor, but it is also one of the most challenging (I think) for new users. It requires technical knowledge of Template:Cite and the manual entering of bibliographic information. However, at least for online references (which [probably make up the majority of references) it seems like it should be possible to automatically generate this information once you have the URL of a site because most major news sites are consistent in the tags and formatting they use for different sections of articles (author, title, etc.). Therefore, it should be possible to create some sort of database of these sites and write a script that would put all the correct reference information into the footnote just given the URL. Would this in fact be feasible, and would anyone be interested in helping to achieve it? Theshibboleth (talk) 01:48, 11 June 2008 (UTC)

Not a solution but, ottobib creates nice templates using ISBNs. And I use the copyurlplus firefox extension to copy url+titles to clipboard - this might be partially adaptable on a personal level.
Your suggestion sounds great, but I would guess requires a more fully developed semantic web (or a large manually created database to draw from) for anything automagical to work.
A text entry form that spits out the cite template might be more within reach? -- Quiddity (talk) 02:02, 11 June 2008 (UTC)
I'm not sure that it is as out-of-reach as it might seem though... even though a lot of sites don't use semantically meaningful formatting, they still style titles, bylines, etc. a certain way, and a script could use those as cues of some sort... I know almost nothing about scripting though, but perhaps I could try to figure out how to do this for one or two sites... I could at least probably figure out what the cues might be.... Theshibboleth (talk) 02:10, 11 June 2008 (UTC)
So for Yahoo! News, the title is at HTML:BODY:DIV ynwrap:DIV yncont:DIV ynbody:DIV ynstory:H1. The author is at ...DIV ynstory:DIV ynmain:DIV storybody:DIV storyhdr:p:SPAN, and the date at ...p:EM recenttimedate. This is the article I'm basing this on - http://news.yahoo.com/s/ap/sudan_plane_crash;_ylt=Ag5praSYT_HOHGzqB4ORgpus0NUE. Theshibboleth (talk) 02:23, 11 June 2008 (UTC)

You're probably aware of these, for journal articles this can often be done. Check the Tools on WP:CITE. I like Verisimilus' Google Scholar search, and use it a fair bit. Also check out the Bibtex to Wikitext converter -- most journals will allow you to export the citation in Bibtext. ImpIn | (t - c) 09:40, 11 June 2008 (UTC)

I use Zotero. I also maintain bibliographies in my userspace to share with other editors; I can do fact checks from my library as requested. See also: Wikipedia:WikiProject Fact and Reference Check and Wikipedia:WikiProject Resource Exchange. --—— Gadget850 (Ed) talk - 19:13, 12 June 2008 (UTC)

Requests for reverts

This is an idea I raise due to WP:3RR. On the Batman Begins, an IP added false information based on speculation in a cited article and also added a redundant url. I removed this and explained very nicely in my edit summary, but he/she just reverted it and now the false information is sitting in the article waiting for another regular editor to undo it. So my proposal is for page requesting another editor or administrator to undo something when someone is clearly not going to respond in a discussion, speeding up the process. Alientraveller (talk) 19:27, 12 June 2008 (UTC)

Encouraging people to bypass 3RR by proxy is not a good idea. If someone refuses to discuss their edits then they can be blocked for disruptive editing. Revert warring doesn't solve anything. Mr.Z-man 19:54, 12 June 2008 (UTC)
I think the particular dispute you mention was resolvable anyway; I made an edit in that regard. I otherwise agree with User:Mr.Z-man, the only cases I can think of where lots of reverts might be really needed that discussion wouldn't solve would be covered by the anti-vandalism procedures. It's OK if the article stays at the wrong version for a bit while the disagreeing editors discuss the issue. --tiny plastic Grey Knight ⊖ 20:11, 12 June 2008 (UTC)

A database on user's past records: a page to watch for these things

I think that we could improve transparency by making it easier to locate people's records of disruptive (at least in some people's mind) behavior. Requests for Comments on users and other relevant information should be easier to find. Unless they are particularly easy to find besides through searching and I just don't know about it? Now, searching is OK, but it requires some effort and thought, and it is not comprehensive -- a search for Requests for User <user> does not give me other relevant results like Arb decisions Wikiquette alerts ect. I know that many people will be uncomfortable with this idea, but it is for the best. ImpIn | (t - c) 10:56, 7 June 2008 (UTC)

A glance at a user's talk page and their recent contributions is all you need to know about a user. If they are acting disruptively, then their history of disruption will be clear from the talk page. However, most users are good, and bad users can change (especially considering the large contingent of teenage users). On the whole, there is no merit in judging the character of a user unless they are deliberately trying to undermine the project, in which case they should already be banned if there's been any past attention to them. BigBlueFish (talk) 15:35, 7 June 2008 (UTC)
The users talk page should be used within reason. It also should never be read as a rap sheet. True a malicious or 'bad' user will have a talk page propagated with warnings and notices, but also a 'good' or innocent user who gets tapped by a bot (moving or redirecting pages named like Bob Sagot used to trip the fagot warning on a antivandal bot) or runs into an over active twinkle user will have a talk page filled with the same warnings. Users who work with controversial topics, will often have warnings or notices from users who may have agendas. People should always look at specific edits (within the context of the subject space and not just a raw diff) to establish a regular pattern of behavior. --Samuel Pepys (talk) 22:06, 7 June 2008 (UTC)
Also, because of the Assume Good Faith guideline, we tend to have a "forgive and forget" system when it comes to things like this. If we keep "rap sheets" for every user, people may never be able to live down incidents in their past. Mr.Z-man 21:00, 7 June 2008 (UTC)

I expected to hear these kinds of responses, and I don't think they hold water. First, looking at a User's Talk page should not be endorsed as a proxy for a user's record. Disruption notices can be taken off of talk pages, and these notices are often made in error, as noted. For example, I recently got a "warning on 9/11 simply because the editors who think they own the article didn't bother to carefully read my edit or its references (they cited conspiracy theory; there was no such thing). People who are attempting to judge a user's character on the Talk page need to be strongly reminded of the problems with that approach. Looking at a user's past contributions is terribly time-consuming and inexact; many users use bots to pad themselves with thousands of trivial edits, which are difficult to sift through. Lastly, I don't have time to keep close watch on Requests for Admin and Requests for Comment User; if I could watchlist a page where these are posted, it would make life much easier for me. I worry that Wikipedia is segregated into groups who perform certain functions: some patrol AfD, some patrol RfA, ect., but when you have a system like that you don't necessarily get input from the most relevant people. There are lots of users for whom I would want to be immediately notified if a Requests for Admin or a Requests for Comment came up, but as it stands, I currently only have a small chance of finding that out, since I can't watchlist these people's talk pages, and don't have want to watchlist RfA since most of the people I do not have time to investigate and comment on. And I don't think that "assume good faith" means that we should forget past indiscretions. Assume it, sure, but if it has been tested, people should be allowed to easily find that out. There needs to be accountability. Right now we seem to rely upon the memory of individual users to keep people in line, and I don't think that's sustainable. ImpIn | (t - c) 23:57, 7 June 2008 (UTC)

Why should you expect there to be no mention of a user's RFA or RFCU on their talk page? If a user is sufficiently undisruptive that it's not even worth your while watching their talk page then frankly that user has the right to edit without being stalked. If the said user runs into trouble, the users who handle the situation are perfectly capable of finding information about past RFAs and RFCUs and any prior warnings, with due attention to the severity and/or faith in which they were solicited. Wikipedia already has a channel for monitoring those whose good faith may no longer always be assumed. BigBlueFish (talk) 12:22, 9 June 2008 (UTC)
What's to stop someone from deleting the RfCU on their talk page? ImpIn | (t - c) 09:27, 11 June 2008 (UTC)
"a User's Talk page should not be endorsed as a proxy for a user's record" - I say that's a good thing. Even the worst users are quite capable of reforming (User:Poetlister). Most users screw up a few times when they are brand new. Why should we create a permanent record of that? If someone was in an edit war in March of 2007 and wasn't blocked for it, should that affect anything now? "Right now we seem to rely upon the memory of individual users to keep people in line" - You really need to read WP:AGF if you think every user needs to be "kept in line." You want a page where you can monitor RFC/U's and RFA's, but you don't want to watchlist WP:RFC/U or WP:RFA? That's just silly. Mr.Z-man 15:53, 13 June 2008 (UTC)
Most long term problem users simply blank warnings, policy seems to accept that. However I do see the benefit in having a record that some user has been warned about personal attacks 17 times in the past, and talk pages simply do not provide that function like it should. 1 != 2 15:56, 13 June 2008 (UTC)

Make 'new section' bold and 'edit this page' regular

The sensible way to edit a large, oft frequented discussion page is by clicking on 'new section' or the 'edit' link next to the section of interest. Otherwise, one must search for the relevant section within the edit window and deal with the horror of edit-conflicts. Currently on pages like the Science Reference desk et al., the 'edit this page' link is bold and the 'new section' link is regular, leading to me accidentally being drawn to the bold link when I want the regular one. Indeed, I imagine few people ever need the 'edit this page' button on the reference desks. I suggest that the 'new section' link is made bold and the 'edit this page' link is made regular, so that people are drawn to what is probably the correct link out of the two. ----Seans Potato Business 17:29, 7 June 2008 (UTC)

It sounds sensible, but... Can this be done for a single page? Waltham, The Duke of 20:13, 7 June 2008 (UTC)
How about doing it for all talk pages and pages with __NEWSECTIONLINK__ on them? – FISDOF9 23:54, 7 June 2008 (UTC)
That might be a good idea. Pity that we seem to have failed to receive enough attention here. I had forgotten about this myself for almost a week... Stupid Pump. Waltham, The Duke of 00:30, 14 June 2008 (UTC)

Mascot

I propose that Wikipedia should have a mascot:Wikipe-tan. StewieGriffin! • Talk Sign 17:51, 12 June 2008 (UTC)

Wikipedia:Mascot. We don't have an official one, but Wikipe-tan is already our unofficial mascot. EVula // talk // ☯ // 18:14, 12 June 2008 (UTC)
This should be the official Wikipedia mascot. -- Coasttocoast (talk) 21:46, 13 June 2008 (UTC)

Proposal to amend the naming convention for numbers

I propose to amend Wikipedia:naming conventions for numbers and years, and also to redirect 911 to 911 (disambiguation) and rename the main article as 911 (year). (Note that the consensus against on Talk:911, while overwhelming, is 2 years old.) Please discuss here and here. 69.140.152.55 (talk) 13:22, 9 June 2008 (UTC)

Ignoring that this would play the dickens with WP:DATE format, do you also propose some objective way to decide which stand-alone numbers should or should not point to a year, or is this an isolated gut feeling about "911"? — CharlotteWebb 15:49, 10 June 2008 (UTC)
It appears, from discussion both at Talk:911 and Wikipedia talk:naming conventions, that the intention of this proposal was specifically to allow the moving of the year article from 911, in order to then allow the emergency telephone number article to be moved to this name. Andrewa (talk) 17:34, 14 June 2008 (UTC)
There have now been two proposals to move 911, both rejected.
The first was rejected, at least in part, because of policy opposing the move. In the light of this, the second foreshadowed this proposed change in policy.
I suggest that we can therefore now regard this policy proposal as also rejected. Andrewa (talk) 17:34, 14 June 2008 (UTC)

Wiki-Genealogy Project Proposal

Hello. My name is Ziang Song, one of my fiends and I have a idea to make wiki more encyclopedic. We have held the idea to build a wonderful module into wiki for a long time. Now we would like to share our new idea with you.

We would like to add a Genealogy or Family Tree module into wiki, in which, anything having relationships can be found here. No matter whether it is the genealogy created by authors in the novel or the actually family tree in our daily life, wiki-genealogy will be a powerful tool to showing every thing in a relationship. We can make it fancy by showing entites in graphs or trees or the similar.

Wiki-genealogy will contribute to the scholars who are studying people relationship in different history as well as novel fans finding it easy to understand personal relationship when they are reading a famous novel...

Definitely wiki-genealogy is a free encyclopedia and can be maintained by people in the world. We can also handle privacy or the similar by some technique which we can discuss later.

If you think it is possible for us to join wiki to do this, please let we know. If not, please also let we know, anyway, comparing notes is happy time for us to learning new things, and we will definitely try our idea in the future.

Thank you.

--Ziang Song (talk) 02:22, 14 June 2008 (UTC)

"comparing notes is happy time for us to learning new things" --- Yes I do believe that sums things up nicely. --Samuel Pepys (talk) 02:25, 14 June 2008 (UTC)
While a genealogy-based wiki sounds like a great idea, Wikipedia is not a good place to run it. You can always download the software Wikipedia runs on, and start your own wiki. — The Hand That Feeds You:Bite 13:33, 14 June 2008 (UTC)
We can currently put family trees into articles using certain templates for that purpose. If you want to maintain more formal structure, then you might want to set up your own wiki as User:HandThatFeeds mentions, or you could get some wiki-farm to host it for you, saving some effort. A MediaWiki-based one would probably be the easiest to incorporate into the "family" (pun not intended) of wikis that includes Wikipedia (that is, the Wikimedia family), if it becomes popular and useful enough that the WMF decide to adopt it.
You might want to read this old page which used to list ideas for new projects, although please note it is no longer in use (but there are some hints you might like). Probably you will want to post a discussion somewhere on Meta to get some ideas on exactly what is the best way to set the project up before you start.
Finally, this sounds like an interesting project, I hope you have fun with it!
--tiny plastic Grey Knight ⊖ 13:53, 14 June 2008 (UTC)

Does anybody have ideas about it? We hope to hear any suggestions about it :)--Ziang Song (talk) 03:39, 23 June 2008 (UTC)

FRUSTRATED: Wikipedia REPUTATION is dirt, sneer, disrespect, skoff, ignored, contempt, unreliable

When I mention Wikipedia to most people older than 30, I get the same reaction:

"Waste of time. Terrible, unreliable info"

  • (Personally, I find the Wikipedia concept is fantastic!)

When I probe a bit, I find the source of their disrespect, scorn, sneers, and contempt:

FIRST IMPRESSION - they see the EDIT button, they see that anyone can edit, and immediately write off the project as unreliable information. (They don't understand peer review on wikipedia.)

I know I know... it's a foundation issue and has been discussed thousands of times. All I'm saying is that this is the reaction from most people I meet in person. Wikipedia has a lousy reputation and it's because of the Edit button.

Even a simple change like "Submit" (instead of Edit) could make a huge difference. —Preceding unsigned comment added by VgerNeedsTheInfo (talk • contribs) 17:36, 31 May 2008 (UTC)

If you think the button names or user interface could be changed for better presentation, that's a reasonable suggestion. There have been proposals to simplify or rearrange the buttons for users who have not logged in, on theory that the majority are not interested in all of the features. However, I don't share your perception about Wikipedia's reputation. That's simply a byproduct of biased and shallow coverage in the press, which is more interested in scare stories and amusing anecdotes than substance when it covers things on the Internet. Anyone who has that opinion has not given it much thought, and is not really the kind of user Wikipeida needs to reach. The Foundation lacks the multimillion dollar PR and marketing budget that commercial operations and even schools and charities use to counter bad press, so we might just have to live with it. 17:43, 31 May 2008 (UTC)
And yet we are one of the most popular web sites on the internet. We are a work in progress. 1 != 2 17:49, 31 May 2008 (UTC)
Of course, you could just rename the "Edit" button to "Contribute", but only to users who have not registered. It's something to consider nonetheless. --.:Alex:. 17:51, 31 May 2008 (UTC)
And my reply to anyone who thinks the edit button makes the information unreliable is to point out just how wonderfully satisfying it is to be able to actually correct errors rather than have to put up with them or consult lengthy errata sheets like you have to do with textbooks and other publications. The proverb, "Don't believe everything you read" long predates Wikipedia... —Ashanda (talk) 18:04, 31 May 2008 (UTC)
Wikipedia is not so universally denounced by non-young people. There are plenty of active contributors who are older. I've met multiple college professors who like the idea of Wikipedia - I've even seen a textbook that referred students to Wikipedia for information on topics that were too specific to be covered in the book. While Wikipedia isn't universally liked either, I don't think changing the wording of the edit tab is really going to change any minds. Mr.Z-man 18:08, 31 May 2008 (UTC)
And a lot of people under thirty dismiss us. Therequiembellishere (talk) 04:24, 1 June 2008 (UTC)

The fundamental problem with changing "edit" to "submit" is that it's inaccurate. This isn't really a peer reviewed system. Edits go live as soon as you hit "save page" without any other human eyes seeing them. If your older friends think this makes Wikipedia unreliable, that's their opinion. If the button said "submit", new editors might make changes assuming someone will look at their "submissions" before they become part of Wikipedia only to be surprised to see the changes immediately. --D. Monack | talk 05:55, 6 June 2008 (UTC)


It's actually important that people who use Wikipedia should expect the worst of the page they are reading. It's simply the truth that you can't be sure what has just been changed, by whom, in the last five minutes. The content of articles has to prove its reliability through quality and verifiability. In terms of an irrational fear of this, the advent of flagged revisions may serve as the safety blanket your friends need, to know that somebody with some experience has at least already checked the page. BigBlueFish (talk) 15:28, 7 June 2008 (UTC)
Instead of changing it to a "submit" button, What about a "correct/add" button? Bobzooka (talk) 12:55, 9 June 2008 (UTC)
That is simply an incomplete definition of editing. BigBlueFish (talk) 16:11, 9 June 2008 (UTC)

How about a more honest solution. ;) ... On a more serious note, I still run into more people who are surprised that you can just edit. Most who have a low opinion simply think that WP has a low threshold of whom it allows to edit, not that there is no threshold. --Gmaxwell (talk) 19:53, 15 June 2008 (UTC)

Order of precedence

As far as I can tell their is no explicitly laid out order of precedence for wiki policy. I feel its time we lay out which policy outweighs other policies. For example if on a WP:RM 10 people vote oppose but one votes support with a reference should WP:CON be overruled by WP:V? WP:C would over rule WP:V right? Gnevin (talk) 12:38, 3 June 2008 (UTC)

I think WP:IAR would come before anything, if that's any help to you. --.:Alex:. 12:59, 3 June 2008 (UTC)
I think something like this would only encourage more wikilawyering and detract from the community trying to reach consensus and compromise on matters of disagreement. - Masonpatriot (talk) 15:51, 3 June 2008 (UTC)
The current WP:BASHing isn't really helping reach con either as Wiki has many rules that will apply . Gnevin (talk) 07:29, 4 June 2008 (UTC)
But they apply in different ways in different situations; for example, if 10 people voteestablish consensus to delete an article due to its being supposed to be unverifiable, and one person comes and adds reliable references to the article just before closure, then the closing admin can ignore the earlier opinions as they no longer apply. Effectively the 11th editor used WP:V to overrule WP:CON, the opposite of what you say above. :-) I think that the easiest and simplest way to deal with precedence issues is to just WP:IGNORE the parts of any policies that you think have a lower precedence in a given situation (which gives the same effect without needing to create a list of situations vs. policy-precedence lists, which would probably end up being non-exhaustive anyway). I think that's what User:.:Alex:. was trying to say. --tiny plastic Grey Knight ⊖ 07:20, 5 June 2008 (UTC)
Is there one single case of a Con of 10 to 1 being over turned based on WP:V? Gnevin (talk) 07:32, 5 June 2008 (UTC)
Well, if the only rationale provided by the other commenters was "has no reliable sources" and somebody fixes that mid-AfD, then I would imagine that would be the only reasonable outcome. I don't know of any actual examples, but I think that deleting a reliably-sourced article on the basis of having no reliable sources is pretty silly, so hopefully there are some! :-P --tiny plastic Grey Knight ⊖ 08:10, 5 June 2008 (UTC) I made a slight edit to your comment to fix a formatting error
I propose that any rules necessary for compliance with U.S. law (such as WP:C) should come first, followed by WP:NPOV and the general principle of "first, do no harm" (that "the importance of following process may, at times, be superseded by the need to minimise the harm caused by inaccurate, unbalanced or inappropriate content,"[1] which to me is implied by the mandate to "ignore all rules,") followed by all other policies, followed by consensus, followed by guidelines. That is not to say that guidelines ought to be ignored, but rather, that if anything higher on the list contradicts them, then whatever is highest on the hierarchy would ordinarily prevail. 69.140.152.55 (talk) 14:44, 9 June 2008 (UTC)
________________________________
  1. ^ See the Wikipedia essay on avoiding harm, but keep in mind that the essay is only a suggested application to biographical articles, and the general principle should be applied everywhere.
69.140.152.55 (talk) 14:44, 9 June 2008 (UTC)
So sorry, Charlie, but this is champion grade bunk. The policies are equal in standing. The community has precedence and in the event of an overlap will decide how to apply policy. Geoff Plourde (talk) 06:20, 16 June 2008 (UTC)

Proposal - warning system for fair use violation/copyvio uploads

In the wake of Wikipedia:Administrators' noticeboard/Incidents/User:Kelly block review, I'd like to propose a gradated warning system (such as we use for vandals) for users who do not comply with copyright policy regarding images. For instance, users who upload non-free images that obviously violate the WP:NFCC (no rationales, excessively high resolution, copyright holder not identified, etc.) and users who upload "free" content without the data necessary for a free license claim, such as claimed public domain images that do not identify the creator and date and place of publication, or images claimed to be used with permission of the copyright holder with no corresponding OTRS ticket.

The warnings should specify that the user is required to review their upload log for previous uploads that violate intellectual property law and/or Wikipedia's non-free content policy. If images cannot be brought into compliance, the user themselves should flag them for deletion. Of course, conditions beyond the user's control (like fair-use images that become orphaned due to article editing) should not count against the user.

Users who do not comply with this would receive a message that any further noncompliance of the same sort will result in either a block, or a block from uploading images (this is a technical issue that the devs would have to deal with.)

I think something like this is urgently needed to prevent further deterioration of this one of the five pillars. Kelly hi! 19:48, 14 June 2008 (UTC)

Endorse. Its high time we do something about incorrigible uploaders, and find some way of dealing with them. I doubt restricting upload privileges will work though. Those that simply never "get it" will then also not "get" why their privileges were revoked. -- Fullstop (talk) 22:24, 14 June 2008 (UTC)
I support a warning system, but how would it differ from {{Uw-upload4}}'s system? MBisanz talk 22:41, 14 June 2008 (UTC)
We can't give those warnings to people that have been around for a while - WP:DTTR. I understand it's just an essay, but you try dealing with copyvio by established users sometime - it belongs in Dante's book. Besides, we need some way to force these people to fix their old uploads. Kelly hi! 23:37, 14 June 2008 (UTC)
Hmm, yes, I can see the DTTR issue, too bad the WP:TTR doesn't have nearly the following of WP:DTTR. MBisanz talk 02:16, 15 June 2008 (UTC)
So template the regulars. If they're doing something once and they're a regular user, they probably screwed up and/or are new at images. Leave something along the polite lines of "Hey, you're doing it wrong. Go here to figure out how to not do it wrong." If they're not a regular user, then they probably don't know how to do it. Leave something along the lines of "Hey, you're doing it wrong. Go here to figure out how to not do it wrong." If they keep doing it, give them a "Hey, you're still doing it wrong...", etc. I don't really see the problem; one of my first edits was an upload without a fair use rationale; I didn't know what I was doing, and the template helped quite a bit. I don't imagine I'd work any different if I did it wrong now, just because I have a few more thousand edits than I did then. Celarnor Talk to me 03:57, 15 June 2008 (UTC)
Celarnor, please, please spend a few days tagging images. You will quickly understand the problem. Go ahead and template the regulars, then come back and comment here once your block has expired. :) Kelly hi! 04:07, 15 June 2008 (UTC)
Well, the problem seems to be with defensive editors rather than the process itself. The process itself seems pretty straight-forward: You screw up, someone points out you screw up, you don't do it again. If you do it again enough, you get blocked. Really, it doesn't seem that complicated; I could be missing something important, I just don't see what it is. Regular editors, who seem to be only type of editors at issue here, should understand that process is important, that notifications that process isn't being followed are an important part of following process, and that it isn't humanly possible to craft a nice "Hey, you're doing it wrong" message for each and every instance of someone doing it wrong. The message that "You're doing it wrong" gets through whether it's template with links to relevant articles and policy or a lovingly crafted paragraph by the image tagger containing the same information and a lot of fluff that took ten minutes to write while a backlog of 800 images piled up; if someone takes it wrong and gets defensive, well ... they are doing it wrong. Celarnor Talk to me 04:34, 15 June 2008 (UTC)
I agree, unfortunately it does not work that way. Copyright violations are considered to be a minor offense, even though they are one of the few things that a user can do here on Wikipedia which is actully illegal in the real world and not just a wiki-offense. Kelly hi! 05:28, 15 June 2008 (UTC)
The warning system we have for vandals uses templates, so I expect a gradated warning system (such as we use for vandals) would also use templates. Either you template the regulars with the existing templates or with a new set. Of course, the better choice is to give a regular a custom message telling him or her what was the problem is, which is what DTTR means. DTTR is just an essay and a lot of people don't even know it's there. It is not the issue in that ANI thread at all. The point (of DTTR) is that it's downright rude to use canned messages with experienced editors who presumably know the policies and have made a mistake, people we run into everyday at XfDs, the Pump, a Project, or our favorite article, rather than those who are substantially newer and either don't know the policies or have intentionally violated them.--Doug.(talk • contribs) 04:10, 16 June 2008 (UTC)

Forums on Wikipedia

I think there should be some sort of Forums on wikipedia for members to talk together.Y5nthon5a (talk) 05:38, 15 June 2008 (UTC)

Aren't you on one now? 5:15 06:42, 15 June 2008 (UTC)
No, I mean more of a forums, like where we can talk about sports, television, and other things. Y5nthon5a (talk) 06:52, 15 June 2008 (UTC)
That's not going to happen; Wikipedia is not a discussion forum. We have some IRC channels, though, which might be what you're after. Algebraist 08:52, 15 June 2008 (UTC)

Sometimes I find it difficult to understand the topic that I am reading, which may also be the case for many others, here is one suggestion that might help: It would be more convenient for me, and perhaps for many others, if they are provided with the information on the topics which might be helpful to them before they read this topic and on the topics they should be able to understand after they have read that topic, for example: which maths theorem I should read first before trying to understand this theorem, and which maths theorem I might be able to understand, base on my kowledge of this theorem.. It would be nice if the 'see also' links are added with such information, providing guidance to readers as to which link might be helpful to them if they do not understand this topic and which topic might they like to read next. —Preceding unsigned comment added by 202.40.137.197 (talk) 09:35, 15 June 2008 (UTC)

"It would be more convenient for me, and perhaps for many others, if they are provided with the information on the topics which might be helpful to them before they read this topic and on the topics they should be able to understand after they have read that topic" Yes that would be convenient, as would the ability to 'read' by osmosis. Place your hand upon the screen child. --Samuel Pepys (talk) 09:37, 15 June 2008 (UTC)

It would be great if I can 'read' by osmosis. The problem with that is that cannot be done, whereas to remind editors that to add a simple piece of information together with the 'see also' links would be great for the readers can be done. Sorry for my poor English.. —Preceding unsigned comment added by 202.40.137.197 (talk) 10:11, 15 June 2008 (UTC)

See also is not a parking place for "more information." See alsos are links that have yet to be added to the body of an article.
The first sentence of an article should already be linking to article(s) that provide prerequisite information. Those links are the "see also"s that you need.
For instance, "Liouville's theorem states every bounded entire function must be constant" has two "see also"s.
-- Fullstop (talk) 10:39, 15 June 2008 (UTC)

There is a serious problem here, that does not seem to be getting addressed. Many articles have become so technically dense that even readers who are knowledgeable in the field find it difficult to understand the articles. A current example is Memristor at which even physicists are complaining. I started an article about a subject I knew quite well, returned to it a year later to find I understood very little of it. Articles should start out without jargon and equations. Further down (perhaps way further down) the article can become more technical. The beginning of articles should be an introduction for someone who knows nothing about the subject -- like an average 14 year old. The psychologist Jerome Bruner wrote that a learner (even of a very young age) is capable of learning any material so long as the instruction is organized appropriately. -- ☑ SamuelWantman 06:18, 16 June 2008 (UTC)

Major rename proposal of certain "lists" to "outlines"

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

Each one of the Lists of basic topics is more like an outline than a mere list.

I would like to rename them as outlines.

For example, List of basic geography topics would become Outline of geography.

It just seems more professional, and I've always felt that the lists of basic topics were awkwardly named. Referring to each as an "outline" is clearer, crisper, and more familiar to our general audience than a "list of basic topics". The latter just sounds weird, tacky, and contrived. I apologize for naming them that in the first place (yes, it's my fault). I just couldn't think of anything else at the time. Sorry.  :)

The change would include updating any self-references on these pages as well. (Where each refers to itself as a "list" would be changed to "outline", for consistency).

One of the problems with the current titles is recurring contention over the word "basic", and what constitutes a "basic" topic. Renaming the pages would eliminate this problem. The simplification would also remove the word "topics" from the title, which is another awkward element (it's superfluous).

Since there are a lot of them (see Lists of basic topics), I thought it would be best to ask you first.

May I rename them, please?

Sincerely,

The Transhumanist 21:41, 8 June 2008 (UTC)

I find "Outline of foo" much less clear than "List of basic foo topics". Removing the "basic" from "basic foo", however, would certainly be acceptable as a means to stop those debates you mention. {{Nihiltres|talk|log}} 23:22, 8 June 2008 (UTC)
Except that "Lists of topics" (without the "basic") are comprehensive in scope, and have a tendency grow to include thousands of topics. The "Lists of basic topics" weren't designed for that - increasing their scope would ruin them. The Transhumanist 08:24, 9 June 2008 (UTC)
However, if it's not a list of basic topics, isn't it a portal? BigBlueFish (talk) 23:53, 8 June 2008 (UTC)
That's an interesting point, not because I agree with it or disagree with it, but because it suggests a viable alternative. Why not move these lists to the Portal namespace? {{Nihiltres|talk|log}} 01:40, 9 June 2008 (UTC)
Why didn't I think of that? The Portal space is underused, even though this is exactly what it was made for. Paragon12321 (talk) 04:19, 9 June 2008 (UTC)
These outlines were designed as a set, as a form of table of contents to Wikipedia, with each outline following a standard design. Navigating them is easy because they are all organized in the same way. Whatever namespace they are assigned to, they should be kept together as a set.
Portal space is underused in part because it isn't included in Wikipedia's default search parameters. That's probably because the deluge of portal subpages clutters search results when portals are included in searches, making the results of those searches almost unintelligible. Moving these lists to portal space would essentially bury them. And we wouldn't want to do that. Besides, portals follow an entirely different design philosophy, and serve different purposes than this set of outlines.
Portals belong in portal space. Regardless of what we rename these pages to, they're still lists, not portals, developed according to the list guideline, which defines them as "structured lists". There are many structured lists besides those in this set, and they're sprinkled all around Wikipedia. As stand-alone lists, they are a form of article. Articles, including lists, belong in article space.
So how about it... may I change their titles to "Outline of ______"?
The Transhumanist 07:44, 9 June 2008 (UTC)
We tried moving them to portalspace at Wikipedia:Move navigational lists to portal namespace, but it failed to attain consensus (due to a number of reasons: primarily because the portal namespace isn't included in default searches making the lists hard to access, but also because some bad examples were used at the beginning of the discussion (eg Lists of mathematics topics a former featured list)). -- Quiddity (talk) 20:13, 9 June 2008 (UTC)
I agree with your essential point, that "List of Basic Geography Topics" is patently not how a general audience would describe it! Sounds like jargon which should be ditched AndrewRT(Talk) 00:05, 9 June 2008 (UTC)
List of basic history topics is another of my favorites. The Transhumanist 08:42, 9 June 2008 (UTC)
The format was modified a bit for countries. Check these out: Albania • Argentina • Australia • Canada • Ecuador • Egypt • France • Germany • Iceland • India • Indonesia • Iraq • Ireland • Italy • Isle of Man • Israel • Japan • Macau • Mexico • Russia • Taiwan • United Kingdom • United States The Transhumanist 09:14, 9 June 2008 (UTC)
I'd agree with the change, especially for these large topics. For smaller lists it might be a bit of a bold term, but I think its worth standardizing the titles. Thanks for all your work on these lists, by the way. Lists are in my mind the best way to navigate Wikipedia -- or at least navigate a complex topic. And when you look through them, they can help you structure your thoughts and remember better. ImpIn | (t - c) 09:50, 9 June 2008 (UTC)
You're welcome. I'm glad you like them. The Transhumanist 03:10, 10 June 2008 (UTC)
Could not "Topic (overview)" or "Overview of Topic" be possible renamings, as an alternative to "outline"? --MASEM 13:56, 9 June 2008 (UTC)
That would conflict with the current title of the Portal:Contents/Overviews page. -- Quiddity (talk) 20:35, 9 June 2008 (UTC)
And "overview" doesn't pertain to format, just to scope. For example, core articles are overviews of their subjects. The article "Geography" is an overview of geography. The title alone would not imply that someone couldn't add prose to the body of an overview. The word "outline" is a format designation. The Transhumanist 13:20, 10 June 2008 (UTC)
The word "outline" is complicated because of its other "silhouette" meaning: Outline of Italy is quite confusing as a title.
How about changing to "List of core ____ articles"? Retaining the "list" designation is clear, accurate, and useful, because it defines what standards the lists need to meet, and describes the contents accurately. E.g. List of core history articles and List of core geography articles.
Alternatively, "main" or "essential" or "key", instead of "basic" or "core". E.g. List of main Ireland articles or List of key education articles or List of essential history articles.
Or swap the word order for something like List of core articles in geography.
Just some thoughts... -- Quiddity (talk) 20:35, 9 June 2008 (UTC)
Outline of Italy topics is not confusing, which is what it would likely be named. ImpIn | (t - c) 04:42, 10 June 2008 (UTC)

I don't care so much about the labels of the Portal:Contents classification system as I do the structure. This discussion seems to be about what's contained under Portal:Contents/Lists of basic topics and Portal:Contents/Lists of topics. I would be perfectly fine with Template:Contents pages (header bar) calling these links Outlines and Indexes, respectively. If that classification clarification means resorting what's included on each page, then all the better. If some leftover links seem to suggest a new type of page or so, then we're getting closer to arranging the encyclopedic topics by the various forms of page structures represented under Portal:Contents. That sounds like a good thing to me. As far as stylistic names go, "Outline of _____ topics" and "Index of _____ topics" works for me. RichardF (talk) 19:50, 12 June 2008 (UTC)

Topical outline

Good points. You got my mental juices flowing...
"Key", "core", "essential", and "main" would invite the same problem as "basic" from the sourcing diehards who from time to time question the verifiability of the "basicness" of the items in one of these lists. I've tried looking for sources, and it is a real pain in the... head. Going around looking for sources for the topics' "coreness", or "keyness", etc. would be just as daunting.
Using "articles" in the titles makes them a little inconsistent with their contents, because the list may (and many do) contain redlinks. A topic can be red and still be a topic, but articles can't be red and still be articles.
You've given me the idea of combining the initial proposal with your idea of swapping the word order. This would fix the ambiguity problem for countries. For example: "Topical outline of Italy". "Topical outline of" would also be less likely to duplicate a title from the real world, and therefore would be good to use for all the subjects, not just the countries. The Transhumanist 01:58, 10 June 2008 (UTC)
Upon trying it out on a bunch of subjects, this phrase looks, sounds, and feels encyclopedic:
And its meaning is consistent with how its used on the Internet. (See Google).
The Transhumanist 01:58, 10 June 2008 (UTC)
I don't like prepending "topical". "Outline of geography topics" sounds so much better to me than "Topical outline of geography". ImpIn | (t - c) 04:42, 10 June 2008 (UTC)
But the plural tense doesn't fit well. "Outline of geography topics" means "outline of more than one geography topic", while "Outline of geography" clearly means "outline of the subject of geography". But "Outline" by itself looks funny in front of country names, though I believe Wikipedia's readers are smart enough to know what context is intended. I prefer "Outline" too. But some have expressed concern over the ambiguity of the word. Therefore, we need to find a compromise that works equally well for all subjects. "Topical outline" fits. It's contextually accurate. I can't find any other term that describes these pages as precisely as "Topical outline" does." The Transhumanist 20:54, 11 June 2008 (UTC)
Strongly support. "Topical outline of ___" works very well. It would also result in Category:Topical outlines which would match perfectly with the existent Category:Topical indexes. (unless there are any even better suggestions...?) -- Quiddity (talk) 05:30, 10 June 2008 (UTC)
Uh, no, I think "topical outline" is too vague, and the word "outline" itself is ambiguous. The "outline of Italy", for example, is a shape like a leg with a boot on it. I don't see much wrong with what we've got now. Gatoclass (talk) 06:46, 10 June 2008 (UTC)
How is "topical outline" vague? I thought it was pretty clear: "Outline of a subject comprised of its topics." The Transhumanist 13:28, 10 June 2008 (UTC)
Come to think of it, our competitors have outlines. Worldbook places outlines at the ends of articles. Britannica published an outline of the whole of human knowledge. But as far as I know, neither of them publishes outlines as articles. We do! But you can't tell they are outlines by reading their titles. For these structured lists, the word "List" in their titles doesn't convey the essence of what they contain. There's no indication of structure. A list may be unsorted, sorted, or topically arranged, but you can't tell which from its title. All three types are clumped together under the same name: "List". The Transhumanist 13:38, 10 June 2008 (UTC)

Outline of Italy articles does not convey the sense that we're talking about the country's geographical shape. I don't see it as confusing. Like I said, I oppose prepending topical just because it seems wordy to me. If It is simply "outline of <something> articles", then I'm OK with it. Although strictly speaking the word "outline" is best for structured lists, an "outline" which is simply a categorized list is, technically speaking, also an outline. ImpIn | (t - c) 00:44, 11 June 2008 (UTC)

How about one of Geography (contents), Geography (table of contents), Contents (geography) or Table of Contents (geography)? Bluap (talk) 02:11, 11 June 2008 (UTC)
Don't like those very much either. What's wrong with "Outline of geography articles"? ImpIn | (t - c) 09:29, 11 June 2008 (UTC)
"Table of contents" just doesn't capture the essence of these pages. These pages can serve as tables of contents, true, because of their links. But they don't stop there. These outlines go way beyond the scope and format of a table of contents and include a lead section/introduction, annotations and data, maps and pictures. Each one also has a see also section, and an external links section. These are articles (as defined in the list guideline) and their focus is the world outside Wikipedia - they present the structure of subjects, not the structure of Wikipedia. The Transhumanist 09:38, 11 June 2008 (UTC)
ImpIn, "outline of articles" conveys the meaning of an outline of multiple articles. "Outline of Italy articles" appears to mean that it is an outline of multiple articles about Italy. These aren't outlines of articles, they're outlines of subjects.
With respect to wordiness, "Topical outline of Italy" has four words and nine syllables, while "Outline of Italy articles" has exactly the same: four words and nine syllables. They're equally wordy.
"List of basic Italy topics", the current name of that page, has nine syllables too, but it has five words instead of four. It's definitely wordier. The Transhumanist 09:38, 11 June 2008 (UTC)
I don't particularly care that much. I see from Google that it is fairly common to create "topical outlines"; the verbiage doesn't quite please me, but I'll let it pass with a neutral. The content is what actually matters. ImpIn | (t - c) 09:53, 11 June 2008 (UTC)

Keep in mind that we'll always have the option of removing the word "topical" later, if the community felt strongly enough that the word was unnecessary. (Though I believe the pun "Outline of Italy" will always bother someone). Therefore, I suggest we move forward with "Topical outline of". The Transhumanist 20:54, 11 June 2008 (UTC)

 Done The Transhumanist 07:07, 16 June 2008 (UTC)

Adjective such as 'basic' or 'core' vs. no adjective

  • Argument against using such an adj.: There are sometimes battles over which topics are or aren't 'basic'.
  • Arguments for: Without such an adjective, many readers AND editors will assume that this article is supposed to be a list or outline of all of articles on this subject. Editors will be much more likely to constantly add minor topics, based on this incorrect assumption. If the list is intended to be limited, the title should reflect this in some manner. ike9898 (talk) 20:35, 12 June 2008 (UTC)
The line "The following outline is provided as an overview of and introduction to foo:" deals with the problem by defining the scope of the page. If editors go rampant and start warping the scope of these pages by adding everything under the sun, we could add "basic" back in to the titles, but that probably won't be necessary... Outlines choked with topics lose their usefulness as outlines and cross a line to become topical indexes. Also, you've currently got someone (me) who watches over these pages. So if anything goes wrong, the community will be alerted. By me.  :) The Transhumanist 22:51, 12 June 2008 (UTC)

We have a List of basic chemistry topics, which given the meaning of basic within chemistry, might be seen as the counterpart of the List of acidic chemistry topics! --Itub (talk) 10:07, 13 June 2008 (UTC)

Some other puns that result are basic programming, basic English, basic research, basic law, basic training, basic role-playing, basic education, basic service, and basic instinct :). The Transhumanist 20:32, 13 June 2008 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Indexes

Index to foo topics perhaps? Just another thought. OscarTheCat3 (talk) 21:06, 11 June 2008 (UTC)

Interesting that you should bring this up. Wikipedia does have some alphabetical indexes:
To name a few. While "Index of" would not fit most lists, such as structured lists or small lists, it would be appropriate to rename extensive alphabetical lists to "Index of ____ articles". The Transhumanist 21:29, 11 June 2008 (UTC)
Need indexes necessarily be alphabetical? Skomorokh 00:59, 12 June 2008 (UTC)
Not necessarily (but usually, see Index and wikt:index); however, there is a large set of articles that currently follow this scheme. See Category:Topical indexes for all 436 of them. -- Quiddity (talk) 01:31, 12 June 2008 (UTC)

(edit conflict) At one point I even considered whether an Index: namespace might be appropriate for many of the List of foo articles articles. The drawback to that approach, obviously, is that the most useful wikilinks in those articles would then become cross-namespace wikilinks.

I think Skomorokh raises an excellent point: indices need not be alphabetical. Truly, most are, because it tends to be easier for a human to locate a specific entry in an ordered list than an unordered list, and the Latin alphabet provides a familiar ordering mechanism. Nonetheless, "classified" or "topical" indices do exist. (Indeed, the whole of Wikispecies is an index of living things.)

I may be opening another can of worms entirely here, but don't many of these "lists of foo topics" (in articlespace) redundantly repeat Category:foo (in categoryspace)? AfD could have a field day. --OscarTheCat3 (talk) 20:44, 12 June 2008 (UTC)

Thanks for correcting my grammar, Transhumanist, but "redundantly repeat redundantly" was intentional. "Repeat" alone would suffice, of course. --OscarTheCat3 (talk) 19:36, 13 June 2008 (UTC)
Please don't edit other people's comments for minor typing/grammar errors. See the second sentence of Wikipedia:Talk page guidelines#Editing comments: "It tends to irritate the users whose comments you are correcting." There's a list of standard exceptions below. -- Quiddity (talk) 21:18, 13 June 2008 (UTC)
Yup, a whole different can of worms. They're mostly for the benefits of wikiprojects, but also aid the occasional reader (see intro wording in many, such as List of Andorra-related topics (which is also an example of a "classified" index)). See WP:TRIFECTA for details, as to why they aren't taken to afd ;-) (they would just get moved to projectspace, and thereby get used less (less easily found, less motivation to update, ...)) -- Quiddity (talk) 21:42, 12 June 2008 (UTC)
WP:TRI -- you mean the DBAD principle, specifically? :-) --OscarTheCat3 (talk) 19:36, 13 June 2008 (UTC)
Not especially. IAR, if anything specific. I meant the page as a whole (irreverent, contextual, eventualist, adults-only, ambiguous). This place contains a lot of mess, and it should be a bit of a mess for at least another x number of years. M:Immediatism is the greatest cause of harm to our community, in most cases (imho, and a completely different topic). -- Quiddity (talk) 21:18, 13 June 2008 (UTC)
See the guideline Wikipedia:Categories, lists, and navigational templates which addresses the issue of redundancy. Lists are beginning to take the role of an upgrade over categories, with superior presentation formats, annotation and image support, non-link data, the convenience of scrolling, searchability, redlink support, etc. (Lists of basic topics are a good example because they utilize all of these features). Should one system replace the other? The category system shouldn't be eliminated from Wikipedia because it is useful for gathering links and building the superior lists. Lists in turn are useful sources for updating categories. Lists are a lot easier to work with (they're easy to combine, divide, or to copy and paste sections to or from them - you can't directly edit categories) and lists make categories easier to work with: lists can be plugged into AWB to update categories, which is much faster than updating those categories by hand. The two systems (lists and categories) are synergistic, and complement each other. The Transhumanist 22:42, 12 June 2008 (UTC)
Excellent point, and one I had not considered: this need not be a case of either/or, but rather and/also. Frankly, I wasn't aware WP:CLN existed. I never read the whole of the MoS either, as I didn't realize there might be a quiz later.  :-) For what it is worth:
* Support moving List of X topics/articles to Index to/of X topics/articles where appropriate (and of course, creating redirs in their place). --OscarTheCat3 (talk) 19:36, 13 June 2008 (UTC)
I also support "Index of (basic) foo topics" (topics not articles, to limit scope and allow for redlinks). This is based on the assumptions that the non-alphabetical use does not jar with other uses of the word "index" across Wikipedia, and that readers won't be surprised at finding a non-alphabetical link. Transhumanist, Quiddity, what say ye? Skomorokh 09:18, 15 June 2008 (UTC)
The (basic) part shouldn't be required anywhere, those are completely seperate projects (the indexes aim to be exhaustive, the basic lists aim to be core/basic only).
But yes, I would support a move of all the "List of foo topics" articles in Category:Topical indexes to either "Topical index of foo" or "Index of foo topics". (I prefer the first, as it matches the category name, and means the keyword is always at the end of the line (as with "Topical outline of foo"). -- Quiddity (talk) 21:22, 15 June 2008 (UTC)
I agree with Quiddity that the index project or proposal doesn't apply to the basic lists. The outline structure, lead section prose, annotations, images, charts, maps, external link support, and limited scope of the basic lists makes them very distinct from indexes. As the outlines become more developed, their structure will become even more refined - and they will further diverge from indexes, and this can easily be seen in the country outlines. For example, the presentation of the structure of a branch of government wouldn't be retained in an index, and describing a page with this type of content as an index would be very misleading. Here's the executive branch section from the List of basic Japan topics:
Executive branch of the government of Japan
Present Kantei, office and residence of the Prime Minister.

I think the lists of topics that are obviously indexes and not outlines should be renamed to "Index of foo articles". An index is a directory of subjects covered in a specific work. Imagine a book that had an "index" that listed topics that weren't covered in the book. Its index would no longer fall under the definition of index. An "Index of topics" in a book would be assumed to present topics included in the work the index supported, and would default to "Index of articles" in connotation - and this same principle applies to Wikipedia. Which brings us to the issue of redlinks. Upon thinking it over, redlinks are a core feature of Wikipedia, and aren't out of place, even in an index. Like all pages on Wikipedia, indexes are works in progress, and redlinks simply designate planned articles. Therefor, "Index of foo articles" fits better than "Index of foo topics". The Transhumanist 22:14, 15 June 2008 (UTC)

Perhaps a broader discussion is needed

I find most of this discussion to be very pertinent and wonder if a broader discussion of lists, portals, categories and other methods of navigation should be undertaken. I've been concerned that categories will soon need to be overhauled when category intersection is fully implemented. It is already possible to find the intersection of categories using search, but because we do not have broadly populated categories (most get diffused into small categories), the feature is not very usable. I'm hoping that we can create "index categories" that will be very broadly defined. It might help to try and rethink how we might want to reshape categories, lists, etc... as part of an general overhaul of navigating around Wikipedia. The problem is that there seems to be resistance to any form of overhaul because of the overwhelming inertia of the status quo. However, if there is interest, I'd be happy to discuss this with others, to see if we could come up with a new scheme for organizing things. Perhaps a subject or two could be reorganized according to the scheme as a test project. -- ☑ SamuelWantman 07:20, 15 June 2008 (UTC)

2 things.
That should distract you for a while ;) -- Quiddity (talk) 21:33, 15 June 2008 (UTC)
Broader discussion? OK. See below... The Transhumanist 07:13, 16 June 2008 (UTC)

Index-builder bots

The creation of index category pages is interesting in theory, but maintaining them would be extremely difficult because categories have no tracking feature. And not being able to edit them directly is also a major impediment. Redlink support is also missing. Index pages are much easier to develop and maintain, in part because the category system can be mined by AWB in gathering links for index pages. Perhaps bots can be created for mining categories, inserting the links found in them into index pages, and then automatically sorting the index pages. This would allow index pages that included all the links from the relevant categories, as well as any links that editors added by hand. Redlinks would also be supported, as the bots would only add to indexes, not delete items from them. The Transhumanist 22:49, 15 June 2008 (UTC)

I find this comment to be very telling. Pehaps, after 4 years of working on categories, we may end up concluding that lists were better to begin with. I find the lack of tracking and the inability to easily revert category changes to be be flaws that prevent the categorization system from improving past its current so-so condition. Editable lists (or indexes or whatever we call them) have many advantages. The only disadvantages when compared to categories is that it takes more work to add an entry to a list from an article you are working on, and lists cannot be used to do database searches, which is now minimally possible with categories, and will be more likely in the future. Perhaps the entire scheme needs rethinking. Categories seem to be most useful as a database. If we were to only put articles in top level single attribute categories, they would be much more useful for creating intersections. If all the categories were transcribed by bots into lists and thus archived as you describe, it would be much improved. While we're at it, the process should work both ways. There should be bots that can restore a category to a previous state by comparing the current population with the archived state. This would mean that lists (or indexes as you call them) would once again become the primary way of navigating through articles. Categories would be used for database functions ad data mining.
We might want to think about adding an "Index" namespace for all these lists. You could add an "Index" entry to an article and it would add the article to an index just as it now adds it to a category. Index pages could be edited just like an article, and would contain links to all the articles that are so indexed. If you do not organize the links, they would be automatically be added to the bottom of the page in an "Unsorted entries" section. The software would keep track of all the pages linked from the index. If someone adds a link to the index, it automatically gets added to the article. If you add the link to the article, it automatically gets added to the index. I'd guess you'd want them removed the same way. This way the change could be reverted at either end. There could be an area for listing indexes that appears just above the category listings at the bottom of articles. I would guess that the default for this would be that they would not be seen unless you clicked on "Show indexes", like many navigation boxes. Many indexes could be created by mining category intersections. I think this has possibilities. -- ☑ SamuelWantman 01:54, 16 June 2008 (UTC)
Except for including redlinks, a lot of this sounds like it could be solved with a CategoryTree. Example below. The whole topic deserves a new/separate thread though. -- Quiddity (talk) 18:42, 16 June 2008 (UTC)

T290062: Parameter onlyroot is deprecated. Use depth="0" instead.

Philosophy

Comments added later : Sounds to me like one of the rare proper uses of subpages. See Wikipedia talk:WikiProject Outline of knowledge#Name of this set of pages +sj + 15:12, 10 March 2009 (UTC)


Useroval

Hi, I am an IP user on wikiHow (but a registered user here), I saw they have a Template:Useroval, like the userbox, except it displays as an oval in Firefox. It will make no difference in IE, an will display like the normal Userbox template. I was just wondering, thanks,

♦ { Crimson } ♦ Talk • Contributions 14:47, 14 June 2008 (UTC)

What was it that you were wondering? I don't understand. If you want to make a userbox that uses this then I guess you can (although I think creating them in the User: namespace is the recommended best practice nowadays). What are you asking? --tiny plastic Grey Knight ⊖ 15:07, 14 June 2008 (UTC)
I think he's asking to have the template imported to Wikipedia for use here. — The Hand That Feeds You:Bite 18:35, 14 June 2008 (UTC)
ok Okay, it's in my userspace if anyone gives a flying squirrel.
--tiny plastic Grey Knight ⊖ 08:45, 16 June 2008 (UTC)

Inactive users

Sometimes when I search through a list or category of users (for example: members of a wikiproject, some-language-speaking users category...), for contact, most of the time, I end up posting for inactive users. I started the habit to check before posting, the contribution page of each user to see whether he's still contributing or not. But It's a tedious task. I know this is not the right place to post this (I think it's Bugzilla, but I don't know how to post there) but I think it would be useful to add some indication about whether a user is active or not. Maybe it could be a sign which appears at the top, bottom, or on the side bar, when visiting a User page. The sign could be either a active/inactive button, or just mention when his last edit was. But what I also prefer, is that links to inactive (or active) users are highlighted in some colors (just as broken links or stubs are colored in red) to indicate their status (what should be considered active depends on a setting in the preference page). What do you think? Eklipse (talk) 16:38, 15 June 2008 (UTC)

I think it'd be too much server load to have everyone's contributions being checked constantly to see how long ago it's been since they last edited. Perhaps a script you could run as needed would be more appropriate. — The Hand That Feeds You:Bite 18:24, 15 June 2008 (UTC)
Thank you. I added a request at Wikipedia:WikiProject User scripts/Requests#Checking for active users. Eklipse (talk) 03:42, 17 June 2008 (UTC)

Named references in infoboxes

It appears that having a named reference that is first used in an infobox and later used in the article space will cause a cite error. [4] My encounters with Category:Pages with incorrect ref formatting shows this has been a widespread problem. I have copied most of the problem refs into the article but this issue will only reappear later. A technical fix needs to be made to allow the named reference to pass from an infobox to the article space. --Samuel Pepys (talk) 17:51, 15 June 2008 (UTC)

Are you sure that the ref in your example was used in the infobox? I did this (having the full ref in the infobox, and the ref name later) in the South Dakota article, for the area, and it turned out alright. Often when the 'cite error' thing appears, it is a problem with the ref name, as in it wasn't copied properly or something; I don't know that the problem is having it in the infobox. AlexiusHoratius (talk) 18:02, 15 June 2008 (UTC)
Use {{#tag:ref|content|name=foo}} instead of <ref name="foo">content</ref>, and you can bypass the bug. Also, make sure that the template or the reference itself at least, for transcluded, default references, is wrapped in <includeonly> and </includeonly> at the template page. {{Nihiltres|talk|log}} 22:19, 15 June 2008 (UTC)
Oooh! Nifty. Does that mean refs can now be generated during the template-processing phase? Also, wouldn't a {{#tag:references}} then be necessary? -- Fullstop (talk) 19:02, 16 June 2008 (UTC)
You have two problems:
  • In the infobox, you had <ref name=NBA.com> and in the body, you had <ref name=NBA.com />. Your ref name must be in quotes: <ref name="NBA.com">.
  • You are using {{Infobox NBA Player}} and entering the reference in the field for "nickname". The problem is that this infobox does not have a nickname field, thus the first reference is not being transcluded.
--—— Gadget850 (Ed) talk - 19:25, 16 June 2008 (UTC)
Fullstop, no. {{#tag:foo}} based tags work exactly the same way as other tags, just their content gets parsed differently (i.e. is parsed rather than just passed through as literal). A {{#tag:ref}} reference will work with <references/> exactly as though it were a <ref>. It's wonderful; give the devs a hug. :D {{Nihiltres|talk|log}} 21:05, 16 June 2008 (UTC)

DOI

Should every Wikipedia article have a digital object identifier (DOI)? Or even every oldid? JFW | T@lk 10:13, 16 June 2008 (UTC)

Actually oldid is a doi. Like so: http://en.wikipedia.org/w/index.php?oldid=219728437 , the previous version of which is http://en.wikipedia.org/w/index.php?oldid=199899596 and so on. -- Fullstop (talk) 18:52, 16 June 2008 (UTC)

New poll to establish consensus about autoconfirmed status

Since the results of the first poll have been rejected by the the developers, a new poll has been created to establish "unequivocal consensus" about when accounts should be granted auto-confirmed status. Please express your opinion there. Thanks! Kaldari (talk) 16:41, 16 June 2008 (UTC)

Move the search box directly beneath the puzzle globe

This is a follow-up to Wikipedia:Village pump (technical)#change the SEARCH field input box, please (permanent link).

Currently the search box, the first thing that our users want to use, is about 3/4 of the way down the screen, after the lists of "navigation" and "interaction" links. This can make it hard to find for new and elderly users.

I propose that we move the search box directly beneath the puzzle globe, like so:


You can try this out in your own browser by adding 

addOnloadHook(function() {
    document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions"))
})

to your monobook.js. You can also type 

javascript:void(document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions")))

into your browser's URL bar and press "Go" to see how just one page would look with the new layout.

If there is consensus to make this change, then I'm sure the developers can just tweak the search box's location by default, eliminating the need for JavaScript.

So, what do you think? —Remember the dot (talk) 03:28, 21 May 2008 (UTC)

  • I like the idea of having the search box higher up the page, but this version seems to almost blend into the logo to me. Perhaps if a thicker line separates the globe from the search box? Johntex\talk 04:01, 21 May 2008 (UTC)
  • It could easily be added as a Gadget if people want it, I mean it's hardly a lot of code to implement. Oh, and yes, I like the idea. RichardΩ612 Ɣ ɸ 06:02, May 21, 2008 (UTC)
  • Support new visitors to the Wikipedia are likely to be here to find things out. Having the search box as proposed makes this easier for them so to do. DuncanHill (talk) 09:28, 21 May 2008 (UTC)
  • Oppose - I think it looks nicer the way it is; it's still not hard, and Google will direct most people to the right page anyway! —TreasuryTag—t—c 09:38, 21 May 2008 (UTC)
  • support. It should be made more obvious than in the sample; ease of use is more important than aesthetics (ask Jakob Nielsen, he knows). While most people enter Wikipedia via search engines (including me!) and most find related articles via wikilinks, we should be encouraging visitors to search for other info that's of interest to them - either unconnected or connected in ways that were not foreseen by editors. Philcha (talk) 10:08, 21 May 2008 (UTC)
    • The point is to combine aesthetics and usability, not to go too far towards one thing on the expense of the other. And for people who do not enter through search engines, we should have a truly prominent search box on the Main Page. From that point on, it won't be hard for them to find their way around. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • Comment what about putting it between the "navigation" links and the "interaction" links? I do think it needs to be higher (people shouldn't have to scroll for it) but it does look a bit wierd right underneath the globe. What's the javascript for that? And there's no need to bug the devs for a change like this - if we gain consensus, just add the relevant code to Mediawiki:Common.js. Happy‑melon 11:04, 21 May 2008 (UTC)
    • Comment - I've corrected the proposal to make clear that developers don't need to be involved in making this change. —Preceding unsigned comment added by John Broughton (talk • contribs) 11:56, 21 May 2008 (UTC)
      • JavaScript is not the right tool for every task. It will work, and it's a good first step, but page loading would be more smooth and less prone to bugs if the change were made directly. —Remember the dot (talk) 14:29, 21 May 2008 (UTC)
    • Comment. I like Happy-melon's suggestion of moving it between "navigation" and "interaction" - that would fix my issue whereby I have very small screen (I've already pointed this out posting from a different IP) because it would then be visible without scrolling. But thinking further about this, why are links like "Featured content", "Current events" and "Random article" so high up? I don't believe these are central to most consumers of this encyclopaedia who generally are looking for information on something specific.--82.148.54.183 (talk) 18:05, 26 May 2008 (UTC)
  • Support. The location of the search box should be optimized for readers; there are more than a thousand page views (by readers) for every edit that is done. The location may not be that important if a reader comes to a specific article via (say) Google, but it's hugely important when reader starts at the main page - and millions do so every day. Take a look at how Encyclopedia Britanica does it - search box right at the top. I don't think editors will have any problems adjusting - there was a major reorganization a couple of years ago without many complaints, I think. But for experiencd editors who like the old location, just create a gadget so that they can put the search box back where they prefer it. -- John Broughton (♫♫) 11:56, 21 May 2008 (UTC)
    • The analogy is an unfortunate one, I am afraid. Even if we do move the search box to the top, it will hardly be any more visible than it is now, given that we do not drastically change its formatting. Britannica's search box is incorporated in the masthead, or whatever it is called, which is always at the top—we have a sidebar, which occupies the left edge of the screen. Completely different vehicles for the display of important links. Furthermore, it is white on a blue background; our colours are much more subdued. In other words, it is clearly more conspicuous than our search box will ever be. And it probably needs to be, because there are visibly fewer ways to browse Britannica than Wikipedia. In any event, these are two very different examples. Adopting anything similar to Britannica's format would entail a radical change of Wikipedia's layout. And the current one works much better for the requirements it needs to meet. Waltham, The Duke of 23:02, 22 May 2008 (UTC)
  • Oppose I think the search provided by Wikipedia is kinda useless. I don't use the search box. -- Taku (talk) 12:09, 21 May 2008 (UTC)
    • Comment: Are you saying that you think the Wikipedia search box should be less obvious so readers are less likely to find it and use it? -- John Broughton (♫♫) 16:36, 21 May 2008 (UTC)
    • Comment: Just because you don't use the search isn't a very good reason to oppose. If you don't use the search that moving it won't affect you. Many others do use it. You have to consider them. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
  • Support The search box is THE most important thing of the sidebar and it makes every sense in the world (to me) to have it on the very top. John Broughton's arguments are spot on. Pax:Vobiscum (talk) 12:56, 21 May 2008 (UTC)
  • Support I definitely like it better up there, and John's suggestion is a good one. J.delanoygabsadds 13:27, 21 May 2008 (UTC)
  • Support I like it better up there because it makes it easier to navigate by lists and headings with screen readers. To get to the categories of a page, I can just hit up arrow twice from the search heading and to get to the Article/Discussion/Edit tabs, I can just hit "l" to navigate to the next list from the search heading. With the old positioning, I sometimes had trouble finding my way around. I know about the hidden "Views" heading, but that doesn't work in my version of JAWS. Graham87 14:11, 21 May 2008 (UTC)
    • One-size-fits-all solutions always have problems, especially with the modern variety in monitor sizes. Some people say the search box is too low now; taking it to the top will have other problems, however, especially for people with bigger screens. Surely there isn't the ability to adapt the main page to various gadgets? The demands of different users often seem irreconcilable. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • Hmmm... I think I'm with User:Happy-melon. What about between the "navigation" and "interaction" boxes? Or altering the color of the box from white to a slight padtel or something to make it stand out more where it is? Mahalo. --Ali'i 14:29, 21 May 2008 (UTC)
  • Oppose Too much white space clumped together. It looks better the way it is now. 1 != 2 14:34, 21 May 2008 (UTC)
  • Oppose as a site-wide JavaScript hack. If you want it changed, please change it in MediaWiki. GracenotesT § 14:57, 21 May 2008 (UTC)
I thought that's what the proposal is for. To tweek MediaWiki so that the javascript workaround can be avoided. Missing something am I? --Ali'i 15:01, 21 May 2008 (UTC)
Ah, must have missed that paragraph (doesn't look like you missed anything, no); struck. No opinion on the GUI change, but implemented as a change in the monobook skin, there shouldn't a problem. GracenotesT § 15:18, 21 May 2008 (UTC)
Well, I wasn't 100% sure myself, so I figured I could have been totally wrong. :-) Mahalo. --Ali'i 15:26, 21 May 2008 (UTC)

 
    • Comment - This is a proposal to move the search box up to the top of the left margin on every page - the example above is simply an example. Moving the search box to where it is more visible doesn't change the nature of the Main Page; it's not a search page. The search box has to go somewhere - this question is simply about WHERE that somewhere is. -- John Broughton (♫♫) 16:36, 21 May 2008 (UTC)
      • I believe that Wikipedians could find a way to integrate a search box in the Main Page's top, where it would be most useful, without compromising aesthetics; it is certainly better than changing the appearance of a few million pages. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • Comment and background. See Wikipedia:Village pump (proposals)/Sidebar redesign for the previously proposed idea, of having the search box between the "navigation" and "interaction" boxes (which we all liked, but it appeared to be technically difficult to accomplish). I'd support that as the ideal, if it's possible.
    Otherwise, I'd support Oppose this proposal to move it to the top of the stack, per Waltham and Evula, plus our search results are still quite abysmal. -- Quiddity (talk) 18:13, 21 May 2008 (UTC)
  • Support. I like it better this way, myself. It makes more sense, considering that Wikipedia is a searchable encyclopedia above everything else. Celarnor Talk to me 22:21, 21 May 2008 (UTC)
  • Support. And in addition, perhaps make the word "Search" bigger and bolder. --207.176.159.90 (talk) 23:54, 21 May 2008 (UTC)
    • Comment There's no point to the word "search". Just get rid of it. There's already a button that says "Search". Less cluster is actually makes things easier for newbies. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
  • Totally support this, to make it easier for new users to find their way around Alex Muller 06:00, 22 May 2008 (UTC)
  • Oppose on the following grounds:
    • It would be rather distracting, being placed exactly next to the beginning of text in articles (I don't think the screenshot above is so representative, if this change is to take place in all pages). Its current position, on the other hand, is well into the body of articles, and therefore more distinct than the non-sidebar part of the page.
    • I consider the proposed place of the search box too high, forcing my eyes go almost to the top of the page for every single search. Furthermore, it does not give me the ability to change that, in contrast to the current position, which is easily adjustable in most pages by scrolling. I'd also like to note that, although the current position rarely ever requires scrolling to reach the box from the page's top, it requires less scrolling from the bottom than the proposed position.
    • The search bar is rather distinguishing as it is; while the rest of the sidebar is a long bulleted list, the search box has a long box and two large buttons below it. I believe it strikes a perfect balance between being visible and not distracting a viewer's attention. The sidebar should be discreet; if one needs it, one can look at it then.
    • The search box's being above the sidebar's first two boxes would make it look as if it is more important than the links in these boxes, which is not necessarily true. The first box contains standard ways of browsing, important to, and useful for, a great part of our readership. The second one includes pages of extreme importance, including the "About", contact, and donation pages and the Community Portal; the first two are of particular significance to non-editors.
    • The current location of the search box divides the sidebar into two parts, of arguably different importance and usage. The first two boxes are important to all Wikipedia users; the toolbox is only used by editors, and the languages box is a varying factor.
    • Finally, per 1 != 2. I don't like the aesthetic side of the proposal. (And don't you dare focus on this argument... :-D) Waltham, The Duke of 06:24, 22 May 2008 (UTC)
  • Support. A very sensible idea, in line with navigation principles used on other web sites. And, replying to Nihiltres, if the main page isn't a "search" page as well as a "content" page, I wonder what is a search page? That's a rather overwrought statement—it's obviously both. –Outriggr § 10:33, 22 May 2008 (UTC)
    I would suggest Special:Search and Google as good examples. Nihiltres{t.l} 14:29, 22 May 2008 (UTC)
  • Support. As I suspect that it will make life easier for readers who are not used to the site. CambridgeBayWeather Have a gorilla 14:25, 22 May 2008 (UTC)
  • Oppose Its current location is just fine; if a user is so easily confused that they can't figure it out, moving the box up won't help (and it's already above the threshold, so even on a small screen, it's visible). Moving it clumps all the other sections (Navigation, Interaction, Toolbox, Languages) together; having the search box in the middle helps to make the sidebar more visually distinctive. I think it would be perfect for a gadget, though. EVula // talk // ☯ // 14:42, 22 May 2008 (UTC)
  • Oppose. I'm going to have go with the opposers on this; they've convinced me. Navigation and Interaction are just as important as the search bar, and its current location is, I think, more noticeable and distinctive than it would be up by the logo. To me, it's part of what makes the default Wikipedia skin look like Wikipedia. Powers T 18:27, 22 May 2008 (UTC)
  • Support I've been trying out the new format and it's better all around. It looks better and it's more logically placed. And as was mentioned in other comment, it's important for mobile devices to have it higher. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
  • Expand the discussion
Personally I prefer the current position because it's near the photo of the Feature Article, but try the other if you like. The real problem is that the Main Page is too long and needs to be edited down. This is a very tricky operation because everyone will have their favorite links! But the way it is I don't even remember to look at the Featured Picture most of the time, for example. There are three sections for other languages - the "Local embassy" link, the list of numbers of articles in other languages at bottom, and the sidebar with other languages. (By the way, I think that we should find a way to trim crazy languages like Volapuk from the main list; I know it has 100,000+ articles listed, but there should be some way to trim the list based on the number of articles and the number of actual readers; also Chinese should be at the top of the list rather than the bottom)
The problem is, we need a way to begin meaningful editing. There has to be some way for alternate Main Page versions to compete against one another in a very widespread test of approval. For example, if people could set a "Wikipedia home page" in their preferences, then different people, once logged in, could see different Main Pages, sometimes using portals or Wikiprojects, sometimes using an alternate development version of the main page. The statistics would start to prefer specific development versions that could be subjected to a Wiki-wide vote of approval or a test for a day. Wnt (talk) 15:51, 22 May 2008 (UTC)
This thread is about the Sidebar, not the Main Page. However, See Wikipedia:Main Page alternatives for Main Page variants, and the js code to make them your default. -- Quiddity (talk) 18:26, 22 May 2008 (UTC)
Thanks for pointing these out. Still, I think most users will bail out the moment they see ".js", without further consideration. Also, is there any way to gather statistics about how many use each version? Wnt (talk) 16:44, 23 May 2008 (UTC)
See http://stats.grok.se/ eg [5]. -- Quiddity (talk) 17:52, 23 May 2008 (UTC)
Hey, that's a handy tool - thanks! I guess no special method of collecting stats is needed then, though differences in the number of reloads between users could skew the results somewhat. Wnt (talk) 14:09, 26 May 2008 (UTC)
  • Oppose—Silliest idea in a long time. Its current position allow you to access it both initially and having scrolled down further.Tony (talk) 02:18, 23 May 2008 (UTC)
    • I dunno...most of the time when I'm reading along in an article, I have to scroll up to get back to the search box anyway.
    • We could also make the search box more prominent by adding it to the main page like the Commons does (although they hide the "Go" button and just leave the "Search" button). Would that be better? —Remember the dot (talk) 03:20, 23 May 2008 (UTC)
    • Comment That argument only works for a very specific article size. In fact, it fails for long articles (which are numerous) because you can always quickly drag the scroll bar all the way up and know that you'll see the search box; whereas with it in the middle on low-resolution display you may actually have to go down a page. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
  • Support, as we have actually gotten complaints about it's current position (see the link at the top of the thread). You really have to look at the sidebar as a casual visitor does and realize that they're blind to it and many of its links because it looks similar to and is positioned similarly to contextual ads on other sites. I do recall seeing studies where people were asked to find something on a government website and almost everyone completely ignored a link to exactly what they were told to look for because it looked like an ad- logic doesn't even enter into it, there aren't ads on government sites. Putting it directly under the puzzle globe will make it much easier to find for new visitors- people look at logos because they're usually navigational aids. I'd also advise bolding the word "search" above the box to make it a tad more prominent. I don't like the way the searchbox on Common's main page is set up- it looks just horrible to me. That's my two pennies anyway. —Ashanda (talk) 01:04, 24 May 2008 (UTC)
    • Bolding search would not help because the Wikipedia logo has large, bold lettering anyway. Basically, all it takes for a user to know where the search box is is to find it once; and if there is a prominent box on the Main Page then they will know that there is searching capability, so that they will look for it on other pages even if they cannot find it straight away. And where will they look but in the sidebar? As long as they think to look at the sidebar, they will see it right away—within the sidebar the search box is rather distinctive. I agree that the Commons solution is rather ugly, but we don't have to do it this way. I am thinking of a page-wide narrow bar below the top box, which would be useful without disrupting the page's layout or ruining its appearance. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
    • Comment No just get rid of the world search... it's redundant as the button already says it. Jason Quinn (talk) 23:30, 31 May 2008 (UTC)
  • Support - The first thing most people want to do when they visit is search, so it makes sense to have the search box closer to the top. – FISDOF9 04:40, 24 May 2008 (UTC)
  • Comment (I actually support this, but don't want make it appear I'm voting as I don't my opinion to get rejected as I'm an anon.) An important point is that an increasing number of users like me use small-sized screens (800x480 on my Asus Eee PC) and cannot currently see the search box without scrolling.--82.148.54.195 (talk) 12:43, 24 May 2008 (UTC)
  • Support anything that helps searching. I would die to see the search box in the header next to "Welcome to Wikipedia" in place of the portals (like Portal:Art, Biography, etc...) Renata (talk) 21:44, 24 May 2008 (UTC)
    • That I would support (seeing Renata dead would not be bad, either). However, I do not want to see the portals replaced, but the inclusion of the search bar would certainly help; a long, narrow bar with bold wording below the top box would not affect the Main Page's layout and formatting much. See comment a few bullets below. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
  • Support - The two main activities on Wikipedia are "searching and browsing". It makes sense that those should go at the top where they are most noticable. Searching followed by navigating (browsing) is fine. The Transhumanist 22:37, 24 May 2008 (UTC)
    • As I say below and have said again, the top of the sidebar is not that much different than any other place in the sidebar, and moving the search box has more consequences than a simple re-arrangement; it changes its entire appearance and the way people look at it. The top of the Main Page, however, is much more prominent, and really is the first place one will look at on that page—which is dubious for the sidebar. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
    • I disagree that the search box is more noticeable below the logo. I would (and did) in fact argue that it's more noticeable where it is now, than up by the logo. As it is now, the user's casual glance sees "round thing, block of text, interruption to the block of text, block of text" along the left sidebar. I fear that with the edit box moved up, it would blend in to the logo on a casual glance or in peripheral vision. Having it interrupt the "block of text" makes it stand out more. Powers T 13:49, 25 May 2008 (UTC)
      • In practice, however, new users don't even actually "perceive" the side bar's table of links because to them it looks like a series of contextual ads (white boxes with text in them) and is ignored because of banner blindness. I've had n00bs email me to ask how to do something linked to from the sidebar, and I've had to give them specific directions, including landmarks and how many links to count down to find what they're looking for. Putting the search box between the "white boxes" and the logo will definitely make it more visible to newcomers. —Ashanda (talk) 14:20, 25 May 2008 (UTC)
        • I don't know about "definitely" -- I understand the banner blindness, but I think it's precisely the current position of the search bar that serves to break that up. Moving it could exacerbate the problem rather than alleviate it. Powers T 14:50, 25 May 2008 (UTC)
        • Indeed; it is not at all assured that it will draw more attention to the sidebar. Nor is it assured that people read web pages like book pages in a very rational sequence from the top to the bottom. They focus on images, large headings, and otherwise distinctive features, like those breaking patterns (and that includes the search box). The logo is right in the corner; even if people look at it, they might as well ignore the search box even if it is right below, as it will be lost next to the big, bold Wikipedia. And then the sidebar will not be in the least noticeable, because it will just be a long and largely featureless column of links. Waltham, The Duke of 02:11, 26 May 2008 (UTC)
  • Support This will more closely match user expectations. Essentially every site on earth does it at the top, though the top right corner is perhaps the most usual. In fact I think doing it up there, right above the page tabs might be the very best. DGG (talk) 00:22, 25 May 2008 (UTC)
  • Comment – If it is so important so help people find how to search in Wikipedia, then why not just have a search box on the Main Page—the main portal of entrance to Wikipedia—much more prominent than it would be anywhere in the sidebar, including the top? Renata's idea is splendid, and is in line with the otherwise completely irrelevant references to the layout of the Commons main page. For all other pages it does not matter so much, as people either know how to search in order to have found these pages, or have gone there from Google or other search engines. Personally, I prefer the status quo, but if there really is a problem, then this is the way to go, without ruining the grouping of the sidebar boxes or the balance of the search box's neither too high nor too low. Waltham, The Duke of 01:37, 25 May 2008 (UTC)
    • So, where on the main page would you put the search box? —Remember the dot (talk) 01:57, 25 May 2008 (UTC)
      • I am thinking of a one-line page-wide box just below the top box ("Welcome to Wikipedia", portal links, etc.). Too narrow to affect the page much, but it would still be noticed due to its prominent position, and perhaps slightly different colouring. (I have yet to decide if the box would be better above or below the "Overview", "Contents" and other links, but I think below would be better.) It would say "Search Wikipedia" on the left, with bold letters of medium size, and a long search box would be on that phrase's right; on the far right there would be the "Go" and "Search" buttons, or some differences might exist there. The details are open to discussion, but this is the general idea. A prominent box on the most important page, without adversely affecting either that page or the sidebar. Waltham, The Duke of 03:33, 25 May 2008 (UTC)
        • Well, one of the reasons why I'm hesitant to add a search box to the main page is because that would mean there would be two search boxes on the main page, a prominent one on the top and the regular one in the sidebar. It seems rather unprofessional...wouldn't it be more consistent and easier to find if the search box was in an easy-to-find place on every page? —Remember the dot (talk) 03:38, 25 May 2008 (UTC)
          • There would be two search boxes; although I do not generally like redundancy, I do not find this much of a problem—especially if we incorporate some sort of extra feature into the top search box which would make it more "special". The main points are two: one, I seriously doubt that a top position in the sidebar would make the search box much more visible (if one looks at the sidebar, one can easily locate the search box—this really is a matter of drawing more attention to the sidebar), and two, in the current position the search box acts like an anchor for the sidebar, splitting it into two well-defined parts, of which the first is always identical while the second is subject to changes. If we were to move the box to the top, we'd have all the other components of the sidebar lumped together, a grey mass with no distinguishing features; the whole thing would look like a long, fading line, instead of the current solid format. And, of course, there are the other arguments I have put forth in my main oppose (scrolling, semantics, etc.). Waltham, The Duke of 05:15, 25 May 2008 (UTC)
          • Update – There is redundancy elsewhere in the Main Page: out of the eight links below the top box, mostly linking to general information and browsing methods, four are already in the sidebar. I don't think redundancy should be considered so seriously for the main page.
            • What I don't like about this idea is that it may very well end up hindering navigation by new readers because they'll never notice the search box on every single page and will think they have to return to the main page every time they want to search. Besides, even the smallest changes to the main page seem to involve a lot of drama even after it seemed consensus had been reached. —Ashanda (talk) 14:20, 25 May 2008 (UTC)
              • That is exactly the reason we didn't implement this suggestion during the Main Page redesign. See specifically Wikipedia talk:WikiProject Usability/Main Page/Draft/Search box poll, plus many discussion threads.
                However, If you'd like to experiment with a new example, try fixing up Wikipedia:Main Page alternative (Search Box) (perhaps using elements from Wikipedia:WikiProject Usability/Main Page/Draft extra search box2). Hope that helps. -- Quiddity (talk) 20:42, 25 May 2008 (UTC)
                • Ashanda, we could give a link to the help page about searching in that bar, explaining the whole process. Many readers seem to be at a loss regarding how searching works in Wikipedia, even if they have located the box. Which, by the way, you make it sound quite difficult. The sidebar is one of the very few things that don't change from page to page; people are bound to notice that at some point. About the drama... If the arguments are compelling enough, they should prevail. Why should the Main Page be so much harder to change than an element appearing in every single page? Anyway, I now look at the poll, and see that the main arguments are:
                  1. "It distracts from the sidebar box" (which would indicate that people notice it).
                  2. "it makes searching look too important" (these could be used against any attempt to make the search box more conspicuous).
                  3. "It disturbs the layout of the main page" (that only relates to the specific proposal).
                  4. "Redundant", "it will make people think there is something special about one box over the other"
                  5. "It confuses readers because it disappears on the next page"
                • The two last bullets contain the most compelling arguments, I believe. However, it must be noted that from the 116 supports for the extra box, only one mentioned moving the sidebar one up, and from the 131 opposes, again there was only one such suggestion. Apart from that, the comments seem directed towards making the box more prominent. That I am willing to support (depending, of course, on the means), but moving the box up would simply ruin the sidebar. Waltham, The Duke of 02:11, 26 May 2008 (UTC)
  • Support, the most important navigation element (or should I say browsing element...) should be where new users actually find it (currently, it is easy to miss it in that jungle of small links). I further suggest to remove the 'search' heading above the search form, it is redundant to the 'search' button and it looks much, much better without. Cacycle (talk) 01:06, 26 May 2008 (UTC)
The search box is completely different from the "small links" (for one thing, it is sidebar-wide and has no blue at all), and a distinctive break in the sidebar's pattern; how can it be missed? And what makes the proposed spot "where new users actually find it"? In all honesty, I'd like to know where that comes from. In any case, the "search" heading, apart from ensuring consistency, actually helps setting the search box better apart, giving it more space. I am not so sure about its not being useful at the top, either; a box with no heading at all and just two buttons below would look downright strange, even below the logo. Waltham, The Duke of 02:11, 26 May 2008 (UTC)
Exactly because the "search box is completely different from the "small links"" the box should not be intermingled with those (for a new user more or less irrelevant) links. And for me it seems quite obvious from what I have read about usability that the place under the logo is the most prominent place to get the user's attention while any element hidden in small text and link lists at a visually non-prominent place will almost certainly be missed by a new visitor. Cacycle (talk) 03:14, 27 May 2008 (UTC)
How could you call it "intermingled" when the links are organised in boxes and separated from each other? And even if you don't believe that a box breaking a repeating pattern is more eye-catching than another lost in the shadow of the logo, do you really believe that the search box's move would not have detrimental effects on the appearance of the rest of the sidebar by accentuating this repetition and making the sidebar draw even less attention? I maintain that the move, although perhaps producing a small gain for the search box, would negatively affect the entire sidebar's layout and through it that of every single page in Wikipedia. Is it really worth it? And that small gain could be made much more painlessly by colouring the search box, as suggested by Quiddity below. Not anything loud... Just enough to be noticed, better guaranteed than dubiously beneficial moves. Waltham, The Duke of 19:37, 27 May 2008 (UTC)
Not true :-) Cacycle (talk) 03:14, 27 May 2008 (UTC)
I think the main point is less about how any of us likes it better, it is about how we can make life easier for new visitors. Cacycle (talk) 03:14, 27 May 2008 (UTC)
  • Neutral I'm happy with the search box where it is, but I don't really care. I do care that the location of the search box be consistent on all Wikimedia wikis because I am active elsewhere and I depend on a comfort level with the interface in foreign languages. I don't think it's worthwhile to change the interface on a thousand different wikis, so my suggestion is: don't bother changing anything. Shalom (Hello • Peace) 03:41, 27 May 2008 (UTC)
  • Weak Oppose - I'd normally strongly support this, as it conforms better to general web interaction conventions (familiarity being a large part of usability) and because it's very helpful for a user seeking info on a specific topic. On the other hand, the current search is fairly useless unless you know exactly the right term to search for; and worse, can be very confusing to people who use "go" instead of "search".
  • Support Sounds good to me. Why anyone would oppose such a minor and trivial change is beyond me,... Dr. Cash (talk) 00:17, 28 May 2008 (UTC)
    • The upper left part of the screen, from the logo to the "toolbox" label, is (perhaps along with the "book" background) the only part of the interface that does not change in the slightest degree in any of Wikipedia's several million pages. It is the one constant element that acts as a connecting thread between the most diverse of pages, and which everybody recognises and often uses. Even the slightest change to that part would, and should, be subject to discussion. That said, this is certainly not a trivial change, considering that it would affect (very negatively, in my opinion) the appearance of the entire sidebar, as well as the searching experience of readers and editors alike. A move would entail consequences which would not be trivial. Waltham, The Duke of 20:27, 28 May 2008 (UTC)
  • Support - would make life much easier for visitors and editors alike, and it's easy to implement. I don't think "I'm used to where it is" is a good reason to oppose - we'd soon all get used to the new position. Waggers (talk) 09:55, 29 May 2008 (UTC)
  • Support. It's an excellent idea: the whole layout feels more consistent, and the search box is easier to access. -- The Anome (talk) 23:58, 29 May 2008 (UTC)
  • Comment – Does any one know why when I hit Save without having previewed first I am taken to a search page? (For the record, I use wikEd's previewing tool.) It only happens in this thread. Waltham, The Duke of 15:41, 30 May 2008 (UTC)
  • Support. As an ordinary user and only occasional contributor, I've been annoyed by the current placement for a very long time. As the proposer says, it's the first thing people want to use but is currently hidden away and a real nuisance if you're accessing wikipedia from a mobile device. Saluton (talk) 21:15, 30 May 2008 (UTC)
  • Support. This is a request I heard many times in conferences and from regular users with a laptop. They hate scrolling up and down each time they need to do a search. Anthere (talk) 10:09, 1 June 2008 (UTC)
  • Support All it is a simple move. Not only that it helps out those who have problems with finding the bar..and I have seen people struggle to find the bar. Rgoodermote  00:54, 2 June 2008 (UTC)
    • I don't see how this proposal helps. Do you have evidence that the search bar is easier to find if it's underneath the logo? Subjectively, it appears to me that it's less noticeable there. Powers T 12:13, 2 June 2008 (UTC)
  • Oppose Per Powers and The duke of Waltham. Keep it the way it is. Or change it. But either way it should be an option in preferences. FelisLeoTalk! 11:48, 3 June 2008 (UTC)
  • Comment I think that moving it to the top is better than where it is now, however I think that an better place is at the bottom of the navigation navigation like it was way back in proposal 15. Is this possible to do? If so I'd greatly apprciate if somebody could give me the code to put in my personal monobook.js page Redekopmark (talk) 22:00, 3 June 2008 (UTC)
  • Weak Oppose I think this is a solution looking for a problem. There's nothing wrong with the search bar being 100 pixels too low. If it ain't broke, don't fix it. Paragon12321 (talk) 03:00, 4 June 2008 (UTC)
  • Neutral As long as there's a gadget to move it back, I'm happy either way. shoy 13:17, 4 June 2008 (UTC)
  • Support As a reference desk monitor, it is clear to me that users need to be encouraged to search for the answer to their question on Wikipedia. In many cases, we already have an article that answers their question directly. ike9898 (talk) 14:44, 4 June 2008 (UTC)
  • Support - Seems like a good and logical idea. ScarianCall me Pat! 15:05, 4 June 2008 (UTC)
  • Oppose I don't see why it needs to be moved. I've never actually heard anyone complain that they couldn't find it before and so I'm not sure that there is really a need to make the change. Also, to my eyes it appears to clash with the Wikipedia logo at the top rb000 —Preceding unsigned comment added by Rb000 (talk • contribs) 05:01, 5 June 2008 (UTC)
  • Comment What about inbetween the Navigation and Interaction boxes, if you want to see how it looks you can see what it looks like by adding
addOnloadHook(function() {
    document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-interaction"))
})

to your monobook.js Redekopmark (talk) 05:39, 5 June 2008 (UTC)

  • Comment Between the navigation and interaction boxes would be fine with me. Also, a thick line or some other form of separation between the logo and the search bar would alleviate my concern. I still think the case for moving would be much stronger if anyone could provide a concrete example of how its current location has actually confused anyone Rb000 (talk) —Preceding comment was added at 23:17, 5 June 2008 (UTC)
  • Support The new location looks nicer to me. Also, I have been asked by new users how to search wikipedia because they did not see the search box. The change makes it more visable.--Banana (talk) 00:15, 6 June 2008 (UTC)
  • Support - The search box is easily the most used feature on Wikipedia. Almost everything else on the left side of the page is gobbledygook to non-editors. It's used much more than, for example, "current events" or "community portal" which are currently above the search box. --D. Monack | talk 05:42, 6 June 2008 (UTC)
    • Actually, half the links of the first two boxes ("navigation" and "interaction") are quite important for readers. And frequency of use is not really a factor; it is important that the reader's eye can go straight to the box, not that it should cover the least distance from the monitor's top. Light goes from the fastest road, not the straightest; this is similar. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
  • Support. --Wikinaut (talk) 13:13, 6 June 2008 (UTC)
  • Oppose per EVula and LtPowers above. Like they said, the search box provides a clear distinction between the nav/interact boxes, which may be used by anyone, and the toolbox, which is mainly used by editors. Without the search box in its current position, this distinction would be lost and it would be more difficult to find a particular link. The search box is fine in its current position and does not require scrolling to locate, except for those who use lower-resolution displays. Kal (talk) 22:04, 6 June 2008 (UTC)
  • Support- I can navigate the boxes OK and it's irritating to have to scroll down to reach the often-used Search box. -- SEWilco (talk) 17:01, 7 June 2008 (UTC)
  • I am neutral regarding the location of the box, but would be against any proposal to have two of them on the main page (the current one in the left sidebar plus a new one for the main page only).
  • Support -The way I see it, if I have to look for it sometimes, and I come here every day, then other older and newer will have trouble. —Preceding unsigned comment added by Leonard^Bloom (talk • contribs) 03:12, 12 June 2008 (UTC)
  • Support - This will make things a lot easier for many; I'm not sure if the veterans in opposition are really putting themselevs into the shoes of a brand new user. The first thing they'll see is the logo, and, hopefully, with a new format, the second thing will be the search box right below the globe. -- Anonymous DissidentTalk 13:38, 14 June 2008 (UTC)
    • You are an old user... Do you consider your judgement more accurate than ours as far as the way newcomers view Wikipedia's layout is concerned? :-) In any case, I strongly disagree with the view that people read a screen like a book page, line by line, top-to-bottom. A newspaper or magazine page would be a more accurate analogy: people first look at the most distinctive elements (in printed press that would be headlines, pictures, and captions). In the case of the main page, not only is the search box as conspicuous as it can be with its current formatting because it breaks the sidebar's pattern of link boxes, but it would be overshadowed by the bold lettering of the logo right above it. The move could actually make the search box less conspicuous. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
  • Support - Excellent aesthetic improvement. Jeff Carr (talk) 16:22, 16 June 2008 (UTC)
  • Strongly Support - Good usability should be a prime objective of every website and that means following design conventions where they exist and placing the search where the visitor expects it. The current position violates usablity guidelines which state that the search should be placed at the top of the screen. I see no rhyme or reason for placing the search where it currently is. This should be a no brainer. --Wolbo (talk) 21:11, 16 June 2008 (UTC)
    • Yet it is not. And I agree as far as the top of the page is concerned, and there are indeed many websites placing their search bars right at the top. However, the top of the sidebar is not the top of the page. We are talking about very different layouts, and the comparison here is rather poor. Waltham, The Duke of 01:22, 18 June 2008 (UTC)
  • Support. That's a no brainer. The readers are who we are doing this for. Ther are the majority of users, and we have to acknowledge that we get lots of visitors that are not familiar with the site. We have to make it as easy as possible for the reader to find what is probably the most important function of the site. Plus it'll help users with mobile devices. Furthermore the searchbox should be at the same position on every page (principle of least surprise). --Dschwen 14:43, 11 July 2008 (UTC)

Improvising on Random article

Dear Sir/m'am, This is with respect to a very good facility provided by Wiki Side bar in Main site i.e. The Random article. During my use of the aforementioned I have noted a tendency of the "Randomiser" to land onto page which I myself ,per se ,have no interest in .These include subjects like place names and Counties and Schools. I propose a facility for the registered and frequent user to be able to select a range , not too specific, of subjects that interests that particular PERSON. This may be recorded as a javaBit next to the "Random article" tag. A Maximum of 6 to 7 (with option of choosing 2 not more), with memory facility(ie The Ability to retain the choices in next LOGIN would be optimal IMHO. I do not know how articles are indexed in Wiki <myself not trained in Computers>.However as in such cases the numbers of the Key index pertaining to A SPECIFIC ARTICLE will have a correlation w.r.t. the TAG that it holds (History , Natural Science , Politics , Psychology , Fine Arts , linguistics etc.) and the same may be used here, if POSSIBLE.


I hope due consideration may be given to this thought.

I remain,

Yours Sincerely

ChimesM --Chimesmonster (talk) 06:24, 8 June 2008 (UTC)


We should probably either mark "Improve Special:Random" as a perennial proposal or else figure out a way to do it (the latter would be nice, I wouldn't mind being able to look up a random article within a category). I suppose we might add a category parameter for it and have a separate link beside the normal randomiser to give a list of some of the high-level categories you can select (something like: "Random article (pick type)". An editable (but presumably protected) page could be reserved to maintain a list of eligible categories, I guess (not sure if there is much caching to worry about in this regard).
That's a random idea anyway, probably someone can think of a better way to do it! --tiny plastic Grey Knight ⊖ 07:53, 10 June 2008 (UTC)
Check out Wikipedia:Link intersection -- a proposal to create a tool to find similar articles based on them sharing the same wikilinks. -- ☑ SamuelWantman 07:02, 15 June 2008 (UTC)
###How obvious is this? Lets have to option to not land on stubs and disambiguation pages!69.134.171.127 (talk) 22:57, 17 June 2008 (UTC) —Preceding unsigned comment added by 69.134.171.127 (talk) 22:56, 17 June 2008 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_28&oldid=1252123335"