Jump to content

Wikipedia talk:2008 main page redesign proposal/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Previous discussions

[edit]
  • The current page is bland and unexciting. It is hardly enticing to a new reader.
  • It is outdated in parts. Some links are to pages that are rarely used anymore, or are deprecated (e.g., Wikipedia:Local Embassy)
  • It doesn't cover much in the way of things like featured portals or good articles.
  • The arrangement needs looking at—some think Did You Know should have a more prominent position.
  • Links to better-used pages should be added.
  • There should be some description of the site itself. Currently there is nothing except "the free encyclopedia" and the number of articles.

See Archive 3 for most relevant discussions. ChyranandChloe (talk) 20:26, 27 November 2008 (UTC)[reply]

…But to summarize the opinions there:
  • Icons: Generally negative
  • Content sections and Featured content: More featured media, combine sounds with picture for "media", DYK with GAs, and no community info (Signpost)
  • Self-description: Opposed to additional information
  • Search bar: No consensus; discussion shifted towards highlighting it on the sidebar
  • Two featured articles: No consensus; possibly beyond the scope of this project
  • Interlanguage links: Remove to sidebar, like all other pages
Hopefully this will prove to be a springboard for other comments. I'm not sure exactly what "New Proposals are now closed" is supposed to mean; my impression is that anyone can try out an idea as long as they stick to the MP formatting, because we are worried about content, not style, at the moment.--HereToHelp (talk to me) 21:54, 27 November 2008 (UTC)[reply]
I removed to notice, and I think you are correct. ChyranandChloe (talk) 02:24, 28 November 2008 (UTC)[reply]
Since there seems to be consensus about removing the language section to the sidebar, I'm going to remove it from the proposal. --Dudemanfellabra (talk) 23:34, 28 November 2008 (UTC)[reply]
Sounds good. See also the local embassy among the various links immediately below.--HereToHelp (talk to me) 23:37, 28 November 2008 (UTC)[reply]

Changes that can be made

[edit]

Other areas of Wikipedia

[edit]

Editable List: Show what you mean:

  • Search — A brief help page about searching for articles.
  • Table of contents — A basic outline of Wikipedia's topics.
  • Index — An A to Z listing of Wikipedia's articles.
  • Featured content — The best that Wikipedia has to offer.
  • Questions — A directory to where you can ask questions.
    • Reference desk — Post a question for volunteers to tackle your questions.
    • Help desk — Post a question about using Wikipedia for volunteers to answer.
  • Help — Learn about using Wikipedia.
  • Village pump — For discussions about Wikipedia itself, including areas for technical issues and policies.
  • Community portal — Bulletin board, projects, resources and activities covering a wide range of Wikipedia areas.
  • Site news — Announcements, updates, articles and press releases on Wikipedia and the Wikimedia Foundation.

This list has been cited to be outdated:

  • Help desk — Ask questions about using Wikipedia.
  • Reference desk — Serving as virtual librarians, Wikipedia volunteers tackle your questions on a wide range of subjects.
  • Village pump — For discussions about Wikipedia itself, including areas for technical issues and policies.
  • Community portal — Bulletin board, projects, resources and activities covering a wide range of Wikipedia areas.
  • Site news — Announcements, updates, articles and press releases on Wikipedia and the Wikimedia Foundation.
  • Local embassy — For Wikipedia-related communication in languages other than English.

Per Goals, the Local Embassy has been proposed to be removed, and perhaps we can rework this section entirely. In the order of aestetics, perhaps we should enclose it in a box similar to the featured content, therefore giving a consistent look. ChyranandChloe (talk) 00:29, 28 November 2008 (UTC)[reply]

I oppose putting it in a box similar to TFA because of the distinction between dynamic and static content. Dynamic content is templated in and changed either daily (TFA, OTD) or at least frequently (ITN, DYK). Static content is permanent, like these links. We need to distinguish between the two because otherwise we imply that the links change often, and makes them harder for someone skimming the page. As for the links themselves, I suggest an arrangement like this: Search (because it's the most effective if you know what you want), Table of contents, Index (two common features of books, in the order you'd find them in a book), Portals, Categories (two things you would not find in books, with the more reader-friendly one first), Featured content (we've done enough self-promotion already; if we can link it someplace else, cut it), Reference desk (last to reduce the strain on the real people), Help (no longer about finding articles), Wikipedia in other languages (the last resort; easy to cut if you like). Yup, no news, no no village pump, but remember: the MP is for readers, not editors.--HereToHelp (talk to me) 04:24, 28 November 2008 (UTC)[reply]
Ok, but aestetics is another issues, and perhaps I should of splintered that in another subsection. We are omitting the Local Embassy, from there I feel there is too much left to implication, can you show what you mean (I gave you a list we can mess with). ChyranandChloe (talk) 21:04, 28 November 2008 (UTC)[reply]
I'm going to use the "Find an article" list from my draft that you linked to (somewhere on this page…); I've posted it in the edit-able list. (Alternatively, they can be put at the top of the page without the explanations.) The Help and Reference desks have been moved down, but retained. The embassy is gone, per your reasoning (though we need the links on the left sidebar). The remaining three items are all aimed at editors; someone out of the loop probably won't find them much use, especially if they don't want to edit. My logic for the new list is explained in the previous post.--HereToHelp (talk to me) 23:07, 28 November 2008 (UTC)[reply]
Ok, this opens up some space in the header, and perhaps we should merge these two sections so we can start looking at this hollistically. Additioanlly, there are still quite a few more links, perhaps we should make it into two columns, and shorten the descriptions. ChyranandChloe (talk) 01:12, 29 November 2008 (UTC)[reply]
I don't really like the Portal:Contents page. When I think of "Table of Contents," I think of something like the A-Z or Categorical indexes. Both of these pages (Categories especially) accomplish what I think of when I think "Table of Contents," so I don't think Portal:Contents is necessary. Also, Portals and Categories are pretty much the same thing; in my opinion, only one (Categories) should remain. I think Wikipedia:Questions, which informs people where to ask which questions, should be included somewhere, and Wikipedia:Policies and guidelines may need to be included; teaching people how to go about certain tasks would be helpful in my opinion. --Dudemanfellabra (talk) 03:37, 29 November 2008 (UTC)[reply]

(outdent) In a book the table of contents is the list of content in the order that it appears, but Wikipedia has no definite order. Portal:Contents has good general info, but Portal:Contents/Overviews more closely matches the expectation. It's the article counterpart to the Portals and Categories links. There's probably no point having three similar pages linked in one place (they're linked to each other at the top and new users might not immediately get the difference). Besides, many portals are not well maintained and going through categories has always felt like crawling through the air ducts (like any good spy movie). I've cut them both and changed the link under TOC above. I'm still leaning towards Reference desk over Questions because the heart of the latter is Help:Contents and the ref desks, but I'm open to advice (or using both). WP:LOOK, which I found at Questions, is the new search link. You can try them in a list or in the header.--HereToHelp (talk to me) 04:28, 29 November 2008 (UTC)[reply]

Per ChyranandChloe's suggestion, two columns would be great. Shortening the descriptions and just making the link title more descriptive would also help navigation. I am uncomfortable about having the "Find an article" links at the bottom of the page, however. PretzelsTalk! 19:20, 29 November 2008 (UTC)[reply]
I found a page that I think suits my idea of a "table of contents"; this page can be located at Portal:Contents/Lists of topics. This link provides not just articles (as in Portal:Contents/Overviews), but lists of topics, which I find more helpful. Lists appear more like a "traditional" table of contents than articles do. I still support leaving Categories in the list because I see categories as the most useful organizational tool on the site. Much like my rationale for linking to topics instead of overviews, categories show articles in a semi-listlike environment, which in my opinion is the most organized method of navigating the site.
I still don't support linking to the Reference desk. I see it as a kind of forum if you will of learning actual material. One goes to the reference desk to ask a question about a certain topic, and it's answered. This, in my opinion, is what the site itself is for. I think we should focus more on getting people to search through Wikipedia to find the answers to their questions (which is, in fact, a suggestion on the reference desk page.. they tell you to search Google or Wikipedia first before asking them). If we link to Wikipedia:Questions, the user gets a much more broad perspective of questions. This page tells them where to ask which questions (and even provides a link to the reference desk.. but with more emphasis on searching).
Also, I found another link I like: Wikipedia:Simplified ruleset. This would be a replacement for the Guidelines link I proposed earlier. Instead of having an extensive explanation of what policies are (without naming them) and why we have them, this new page simply lays out briefly tips on how to become a "successful" Wikipedian.
Replacing reference desk with Questions and adding the Simplified ruleset (linked in my working proposal as "Guidelines") would move the focus more from just asking someone a question to getting the user to utilize searching through the site and finding their answers independently. --Dudemanfellabra (talk) 19:25, 29 November 2008 (UTC)[reply]
I would preserve the reference desk. Wikipedia:Simplified ruleset is an essay written in an informal tone. Although useful, I think we need more justification before placing it on the main page let alone swapping it with Wikipedia:Policies and guidelines. For the remainder, if we do two columns, I think we can do both. I've reentered Site news, community protal, and Village pump. They may not be essential to a person intent only on reading, however, for new users it is perhaps one of the few places to start—I'm testifying for evidence, it's how I started (when the welcomming commitee totally left me out of the loop). Lastly I've arranged the list of links acending from focused on the reader to focused on the editor. ChyranandChloe (talk) 20:33, 29 November 2008 (UTC)[reply]
Pretzels: Moving the entire section up would be too unwieldy, but I agree it needs to be prominent, which is why I support adding just the links between the header and dynamic content. The links must be short (crowding, small screens) but self-explanatory. I'm still loath to put community content on the page, but I prefer SR to P&G - it's not as overwhelming. Is there a better name for it, though? Also, perhaps we can link WP:INTRO again. If we put the article stuff up top, and the community stuff on the bottom…maybe. I still like Reference desk because of the real-word analog, which implies a reputable source. I would like more users to weigh in on that. As for Portal:Contents/Lists of topics, it's like the Portal and Category pages, or Portal:Contents/Overviews, which uses articles, except Lists of topics uses lists. The more I think about it, using lists might make sense, because a Table of Contents itself is nothing more than a list. I'm not sure whether I prefer lists or articles anymore, but I do prefer lists to categories. The former are organized by some meaningful criteria (chronologically, geographically) where categories are alphabetized (arbitrarily). If you're looking for something in an alphabetical list, you know what you want - which means you might as well search for it.--HereToHelp (talk to me) 20:56, 29 November 2008 (UTC)[reply]
I think we migrating some of the links that were on the header into this new section. In my opinion, it would be more orgainized this way. There's still space, and we can concentrate on shortenning the list at a later time. Per HereToHelp, let's put in the Intro link. As for portals, I think it should be in a seperate section—it doesn't seem to make much sense to put it in the header. After we've finished organizign the links, we'll look at the header. ChyranandChloe (talk) 21:14, 29 November 2008 (UTC)[reply]
The jump-to links, suggested by 88wolfmaster and discussed under #Header link reduction, would need to go at the top of the page to be functional. I'd put them where we currently have all the portals because we can arrange the links in a pattern that mirrors the content itself. I think the space between the header and dynamic content (can we call this the subheader?) can hold find-an-article links on the left and Help/Questions on the right. (This important content is likely to be looked over so I don't think we should reduce the opacity of the text, as suggested at #Color scheme.) Below the dynamic content we have a little more space (and this text can be a little lighter). You can put Community info, if you like, and of course the sister projects there. I'm not sure how much we need the portal listings, or if we do, would they be portals? --HereToHelp (talk to me) 03:26, 30 November 2008 (UTC)[reply]
(outdent) I think putting the portals in its own section rather than cluttering the Header would be a good idea. Lastly, can we concede on temporarily placing the links above into the main page draft? ChyranandChloe (talk) 08:26, 30 November 2008 (UTC)[reply]

About Wikipedia

[edit]

Now that the new header is in the proposal, I think we should talk about a where to move the links to that were taken out. In my design there is a section titled "About Wikipedia." This section contains all the links previously in the header and a few extra from the old "Other Areas of Wikipedia" section. I believe this is a good starting point for discussion about what links to include in this section (if we even want this section). --Dudemanfellabra (talk) 04:00, 12 December 2008 (UTC)[reply]

I like the idea, can you import the list of links into the discussion? Otherwise my main position is that I'm strongly against the removal the "Reference desk" and "Help desk". ChyranandChloe (talk) 04:53, 15 December 2008 (UTC)[reply]
Here's my list. I have indeed removed Reference and Help desks and replaced them with WP:Questions, which links to both of them. In my description of the link, I say that this is where people need to go to find out where to ask questions. When they click the link, they find the Help and Reference desks; yes it makes users who know that they want to get to the Ref/help desks go through one more click, but it also potentially prevents new users from asking something at the ref/help desks that should have been asked in another location. Some people probably look at the main page and see "humans" and automatically go to these desks to ask because they don't want to find the information themselves; they want someone to just tell them what to do. One of my main goals of this redesign is to promote using the site itself to find information rather than just asking someone. This has been the premise for removing the portals/etc from the header and including more explanatory text on the main page (i.e. the interlanguage links in the language section), and I use the same rationale for removing these two links. I also included a link (courtesy HereToHelp) to WP:Look it up to aid users in how to search effectively. My philosophy is, "Accustom new users to using the site to their advantage.. not the people on it."
  • Help — A general help directory about anything and everything Wikipedia
  • Questions — An outline of where to ask which questions
    • FAQ — Answers to the most frequently asked questions about Wikipedia
  • Search — A brief help page about how to effectively search for articles
  • Navigation — An explanation of wikilinks and other methods of navigating the site
  • Editing — An explanation of how to edit Wikipedia
    • Tutorial — Step-by-step instructions on edting articles
    • Guidelines — A few things to keep in mind while reading and contributing to an article
  • Mobile Access — An explanation of how to access Wikipedia from a mobile device
  • Contact Us — Information about how to contact Wikipedia
Have fun. --Dudemanfellabra (talk) 05:51, 15 December 2008 (UTC)[reply]
[edit]

We can put the portals below the dynamic content (I'm not sure that they have to be there at all, but if they do, that makes them less prominent and easy to remove). In their place can go 88wolfmaster's jump-to links. I'm still unclear what we're putting in the subheader (that space between the header and dynamic content, where we currently have Overview · Editing · Questions · Help). What's going there and what's going in a bulletted section with explanations below the dynamic content?--HereToHelp (talk to me) 13:58, 30 November 2008 (UTC)[reply]

I don't think we need portals at all.. I mean we have links to any way possible that you want to find an article. Simply clicking on Table of Contents will take you to all of the different areas of the site... and there's a search bar of course.. so I mean.. why are they necessary? --Dudemanfellabra (talk) 19:58, 30 November 2008 (UTC)[reply]
The purpose is to find a topic of interest instead of flipping through each article and rely on the links inside to direct you to another article in the same topic. OhanaUnitedTalk page 21:25, 30 November 2008 (UTC)[reply]
But we can only offer a very parochial list of portals on the MP. If we link to a list of portals, readers can find any topic of interest they link. This doesn't have to be mutually exclusive with the lists, which function like a table of contents with several layers of hierarchy. ("Ooh, look at all these types of dance/dead kings of Scotland/logical fallacies/three letter acronyms/WWII battles/units of measurement/genetic disorders/classical symphonies/nuclear explosions!") I still oppose categories for reasons mentioned above (alphabetic listing is useless with a search bar, not very user friendly).--HereToHelp (talk to me) 23:02, 30 November 2008 (UTC)[reply]
(outdent) I second HereToHelp that perhaps a breif list of portals is all we can do with having it be too lengthy. If there is little opposition I can implement it into the draft and see how it looks (I'll wait until thursday)—we can go from there to see what we can do. ChyranandChloe (talk) 04:23, 3 December 2008 (UTC)[reply]
But what about jump-to links and what TOC is piped to? I've outlined most of my concerns in above posts. I would like responses to them, please, because this design is a community thing. If I have to concede a list of portals below the dynamic content to get stuff in the header, that's an acceptable compromise to me, even though I don't think portals belong at all.--HereToHelp (talk to me) 21:56, 3 December 2008 (UTC)[reply]
I'd like to hear some more discussion about these things too. As of now, I think the only people I've really heard discussing actual links and inclusions in the header are HereToHelp and I. Does anyone else have an opinion? My ideal header doesn't include portals; I see them as unnecessary. With links to Contents, Categories, Index, and Featured content as well as a search bar in the left column, there are already ample methods to find an article from the Main Page. My proposal doesn't include "jump-to" links (partly because I don't think they're necessary.. the page isn't that long..), but I'm open to finding a way to incorporate them if needed. I still think TOC should link to Portal:Contents/Lists of topics because lists IMO are the best method of finding information on the site. I've also included a few more links at the top of the page that I think should be included such as Tutorial (linked on the current main page as Editing.. Help:Editing will replace this link), Wikipedia:Simplified ruleset (linked as Guidelines. I feel as if the essay format is more inviting to new users and presents the information in a less overwhelming method than Wikipedia:Policies and Guidelines), and FAQ. Another addition to the header is Wikipedia:Mobile access; while this isn't really imperative, I believe that as the market of mobile internet grows, there will be a more pronounced need for mobile sites. Giving exposure to Wikipedia's mobile version will make it easier for mobile internet users to be able to use Wikipedia anywhere. Also, my proposal has changed the layout of the header, making "Welcome to Wikipedia" much bigger and more pronounced and also redirecting some of the links in the tagline. There are many subtle changes in both of our designs, but either no one is noticing them, or no one is commenting on them. Without comments, this redesign is doomed to failure; we need serious discussion about little things like this as well as major things such as DYK vs. GA and Featured Lists below. Any comments will be appreciated. --Dudemanfellabra (talk) 22:17, 3 December 2008 (UTC)[reply]
Interesting design; have you not linked to it before or have I been blind? I like the white background under dynamic content; it makes it feel more professional and less color-mad. Mobile Access might be worth having. I like placing it where it can be seen on cell phones, but "Welcome to Wikipedia" needs to be the first thing seen by screen readers. Can we have browser detection that automatically routes cell users to the mobile cite, en.mobile.wikipedia.org? Or at least shows that link only on phones; it should lead directly to the mobile page and not the info page still formatted for big computers. The Wiki globe is a nice piece of eye candy but we already have it in the sidebar, it makes reading the text harder, and it doesn't always display in certain browsers. I like the bigger text but the header itself seems bloated. I agree with (Table of ) Contents and Index; I dislike categories for reasons I will reiterate: they feel like the back door, and if you're looking for something by topic, use the lists that are ordered (usually chronologically) rather than the alphabet. If you know what you want, use the search bar. I don't think the date and time are necessary; people have clocks and it's stated under OTD. I also think we an have some more help links, maybe just under the header. --HereToHelp (talk to me) 22:50, 3 December 2008 (UTC)[reply]
When I'm reading Wikipedia, I use both categories and portals. I use categories when I'm researching a topic and want to move up and down a hierarchy from that topic. I use portals especially when I'm first familiarizing myself with a topic, and want to know how others have organized a presentation on that topic. Both approaches have been very useful to me. BrainMarble (talk) 23:07, 3 December 2008 (UTC)[reply]
Whether to have a short list of topics on the Main Page, or to have Main Page links to other pages containing extensive lists of portals and categories, either choice is workable for me, as long as whatever is on the Main Page is clear to us as readers. On the project page right now, I do see a short list of portals and a link to "all portals", then a link to categories. But right next to the categories link is a link to "contents", which to me is an amibiguous term, not as clear as saying "Wikipedia's contents". I wouldn't normally click on an ambiguous term, not having the time in a busy day to go exploring all the Main Page links already there. But when I clicked on "contents" just now, I found on the next page that there are such things as timelines and spoken articles. I hadn't known about these at all before now, and would have continued missing them altogether if I stuck with only clicking on the clearly stated links on the Main Page. BrainMarble (talk) 23:07, 3 December 2008 (UTC)[reply]
We've been using Portal:Contents/Lists of topics for Contents because it most closely resembles a bulleted list. (The main article is usually the first thing linked in those lists). I prefer Table of Contents because it is clearer and slosely resembles a book, implying authority and credibility.--HereToHelp (talk to me) 23:19, 3 December 2008 (UTC)[reply]
(outdent) I've linked to it before haha.. several times. The white background was deliberate; I think the current colored background makes the reader's eyes strain. The white background feels less strained and also gives the section a more professional look. Do you think we may be able to discuss doing that in this proposal? Kind of like a new topic section: White background. About the mobile thing, most mobile phones will re-route [en.wikipedia.org] to [en.mobile.wikipedia.org] automatically, so like I said.. the link is not really imperative. But the page itself has some information about other methods of mobile browsing of Wikipedia such as OperaMini, WAPedia, and MiniWiki.org, all different methods of searching Wikipedia on a mobile device. Most phones automatically re-route to en.mobile.wikipedia.org, so most people don't even know about these other sites. About the background image, the code for that image is a background:url() thing.. if you look at the source code (through your browser.. the actual HTML of the page) of any Wikipedia page, you will see that the globe in the top left corner uses the background:url() method with the link to display that globe. Since this method is used on every page (in every section of the Wikimedia Foundation), I see it as eligible to put in the design. If they can't see the background picture of my header, they can't see the background image of the link in the top left.. 99.99% of people are able to see the background image, so we needn't worry about the small percentage that can't. About the time at the top, yes it is in OTD, but the people at OTD say the only reason it's in OTD is because it's nowhere else on the page. I'm pretty sure that if we put the date/time at the top of the page (where users are more likely to look for it), it will be removed from the OTD template. The only reason the time, in my opinion, is needed is to show that Wikipedia operates on UTC and not local time for anyone. That would explain why for some people Wikipedia may seem to have the wrong date at certain times. About the "Contents" v. "Table of Contents", I'm impartial. I think "Contents" is no less ambiguous than "Table of Contents", but whichever works with me. --Dudemanfellabra (talk) 17:27, 4 December 2008 (UTC)[reply]
Ok, so the image works technically; we'll see if it works aesthetically. I could go for article count and time on the right side of the header if it's deemed we don't need jump-to links. In the subheader (the gutter below the header) we can have "find and article" stuff on the left and help on the right. I think that we have decided to put most such links (except perhaps portals) above dynamic content (have we?), which means no explanation other than the linked text. I dislike the placement of such links in your design because some links get in the way of screen readers and others make the header thicker (vertically) than it needs to be. So much for placement; on to content. Feel free to edit:--HereToHelp (talk to me) 01:44, 5 December 2008 (UTC)[reply]
Search · Table of contents · Index · Reference desk

Navigation · Help · Questions · Guidelines · FAQ

I updated the design. I still like the old one better, but this will do. Thoughts? --Dudemanfellabra (talk) 03:23, 5 December 2008 (UTC)[reply]
In my opinion the background image is distracting, but we'll see how it turns out. I think we should remove the gutter below the header and group them together in the section below the dynamic content (possibly in other areas...); to me having links strewed around like that can become very messy and would likely deter new users from finding everything they need. In my opinion the header serves the purpose similar to an infobox for articles: it provides several breif and explicit fact and then moves on. In the next order, I think we're conceding on removing the portals from the header—whether or not we will move it into a section below the dynamic content we haven't seemed to discuss yet. ChyranandChloe (talk) 04:38, 5 December 2008 (UTC)[reply]
Better. I like the bigger name and the stats off to the side. I think that the book is worse than than the globe; while we can take the matephors of a book (table of contents, index) for familiarity and reputation, a direct image goes to far against WP:NOTPAPER. I still think that categories are unnecessary and not very useful, I'd like a third opinion. I still like Search and maybe Featured Content. FAQ and Guidelines still seem like they're focused on editors. I still like placing them in the gutter, but whatever works. I say ax the portal links and put the main link up with everything else (cats can stay too). If it's too much content, though, cut cats, portals, and the ref desk. I also favor leaving "Welcome to Wikipedia" unlinked, with free encyclopedia leading to About and anyone can edit going to Introduction.--HereToHelp (talk to me) 22:35, 5 December 2008 (UTC)[reply]
Search · Table of contents · Index · Portals · Categories · Featured Content · Reference desk

Help · Navigation · Questions

I don't think it's wise to give such prominent position to the time. Can we not create a completely new header, instead of fudging around with the old one? Links in the gutter look messy and there's too much stuff up there - we need to make a clear focus on WELCOME TO WIKIPEDIA and the few links people actually want to use. The rest can go further down, with the portals. And the Main Page is for wannabe-editors too, so being editor-focused is no basis to remove links. PretzelsTalk! 00:57, 6 December 2008 (UTC)[reply]
(outdent) I'm with Pretzels in that rebuilding the header is in our best interest. However, I think we need to clarify out discussion into a explicit and simple criteria. We have a lot of opinions and individual points we want to get across, and cramming several of them into prose leaves some to be omitted by the next user. Below is a redbox, place what you feel should be added, should be removed, and we can see if we can achieve a consensus on any one of those points. Some are listed in both boxes and that's where I feel we have disagreements. Start a new h4 for the discussion of those points you guys want to tackle first. ChyranandChloe (talk) 04:44, 6 December 2008 (UTC)[reply]

Header: arbitrary edit point

[edit]
Welcome to Wikipedia
Monday November 11, 2024 (UTC)
6,909,127 articles in English
Table of contents · Categories · Index
In response to discussion about header links, I've once again updated my design, this time a major update. I've reverted back to the header with the globe background, but changed a few things. The time and date are still in the header because I think it is needed to show new readers/contributors that Wikipedia operates on UTC and not their local time. This was a main reason for adding the time in the OTD template; new people kept asking why the dates were wrong and such, so the DYK people felt it had to be added. You can ask them, since it's been added, the questions have decreased slightly, but I believe placing Wikipedia's time and date at the top of the page will bring more attention to the fact that the site operates on UTC. I do think, however, that there should be someway to redirect the UTC link to an article that explains why Wikipedia uses UTC instead of local times (of which I'm not aware.. is there one out there?). This, in my opinion, would be a great tool for explaining why the content on the Main Page "has the wrong date." I removed links above the header (because of the screen reader thing) and placed them in a new section entitled "About Wikipedia"; I believe this to be a better name that "Other areas of Wikipedia." It includes all of the links from the previous header strapline plus a few more that have been discussed. The navigation links (Table of contents, Categories, Featured content, and Index) are still in the header. I believe this to be a better location for them than in the About Wikipedia section because they're more about finding a specific article or topic of interest, and have little to do with "About Wikipedia." If someone comes to the main page simply looking to find an article, they will quickly see these links and be able to find what they're looking for. Also, I've removed the box from the Wikimedia Foundation section and created a static vs. dynamic difference. I believe the About Wikipedia box is the way to go. --Dudemanfellabra (talk) 08:00, 6 December 2008 (UTC)[reply]
I like your system for arranging links; now if only we could agree on what to put where. I still think that Who Writes Wikipedia is, though logical, not the first thing users need to see. (You can link it from Introduction if you like.) Leave Wikipedia unlinked, or have "anyone can edit" go to the intro. For UTC, try Wikipedia:FAQ/Main Page#When is the Main Page updated? Why do you have the wrong date in Selected anniversaries?. I like the idea of putting a select few content links up top and it eliminates the need for the gutter, which we can eliminate. As for what links to put there, I've voiced my opinions and would like to hear others. I like the distinction between static and dynamic content and we anevaluate the links under "About Wikipedia" (nice title) later. I would like a normal looking header rather than the small bold one, though. But on the whole: coming along nicely.--HereToHelp (talk to me) 19:13, 6 December 2008 (UTC)[reply]
I've moved the header into the discussion so we can don't have to jump back and forth. I like it as it get rid of gutter and the portals (guess we don't need to get into each topic in detail). However the article count only applies to English. Perhaps we can renamed it from "Currently 6,909,127 articles" to "Currently hosting 6,909,127 articles in English." I'm with HereToHelp that WP:INTRO would be better. In the choice of links, they're nice, but I think we should alphabetize it or apply some kind of organization. Secondly, one question I have on mind is about the Portals. I'm not saying we should bring them back, but similar to the TOC, index, and so forth, perhaps we should swap the Featured content (which seems out of place) with Portal:Contents/Portals.

I'm with HereToHelp, that About Wikipedia can come later. ChyranandChloe (talk) 23:45, 7 December 2008 (UTC)[reply]

I took off "in English" (the link especially) because I'm pretty sure users will know that they are on the English Wikipedia.. I mean the text is in English, so it's kind of a given (and why link to English language? That's useless IMO). There would be no reason to think that "6,909,127" referred to all Wikipedias combined.. The English Wikipedia (though largest) isn't somehow "above" all the others; it is simply one language in a list of many. If the number appeared on the Spanish Wikipedia's Main page, people would assume there were that many articles in Spanish.. or on the French page in French.. they wouldn't assume that their Wikipedia was egotistical enough to assume ownership of all others. The same should be able to be said for the English Wikipedia. Americans are ignorant and don't know there are 200 other countries with multiple languages out there (stereotype.. sorry), but that is not our fault. This would not be a problem in any other language, so why deal with it here?
Also, about the links, I took out WP:INTRO because I think WP:ABOUT does a better job of describing the site. ABOUT is in a Wikipedia article format instead of the tabbed format INTRO is in. Also, ABOUT spends more time talking about the history, etc. of the site and focuses more on research/reading first as opposed to INTRO just jumping into editing.. Yes we're trying to attract editors, but more people than not use Wikipedia solely as a means to gain information - they've never edited anything. If you talk to newcomers about reading and get them comfortable with that then slowly work your way into editing, they will be more likely to edit rather than just being like "here's our crap; edit it." I still like Wikipedia:Who writes Wikipedia because it gives some nice information about how you don't have to be a rocket scientist to edit the site; anyone can... thus "anyone can edit."
As for the Portals link, I don't really like Portals as I've mentioned, but I agree that Featured content seems out of place. I'd like for it to be linked somewhere on the page, but there's not really a good place. In my proposal, I link to TFA and POTD, but each has its own little box.. there's no central "Featured Content" box.. just its individual parts. I'm not exactly sure where to put this link, but that seemed like the best place for now; putting it in the "About Wikipedia" section wouldn't really fit with the rest of the information there either haha.. Can anyone think of a better place? --Dudemanfellabra (talk) 01:05, 8 December 2008 (UTC)[reply]

(outdent) I never thought of it that way, but by saying that everyone can write Wikipedia, it's a more subtle invitation to edit. I'm not sure which to use, so let's move on. I like labeling article count because it raises awareness of the multilingual aspect; the link should be to a page to that extent (or nonexistant). I agree that we need to link Featured Content but there's no place for it. (Maybe at the end of TFA or the featured content column -- which will probably require more content!) I suppose Search has fallen out of favor. We can put Index by TOC, since you'd find them both in books. Then Portals and Categories, in that order, since Portals are more user-friendly. Some of the designs had some sort of serif font for Welcoem to Wikipedia; can we use that to look a little more formal? And what would it look like to put the globe on the right?--HereToHelp (talk to me) 01:49, 8 December 2008 (UTC)[reply]

I still don't think we should add "in English"; let's wait for consensus. I commented out Featured content until we can find a place for it.. I also applied the serif font and made the letter small caps to appear more professional. You can mess with the position of the background image by modifying the background-position parameter, but I think it doesn't look as good on the right.. it makes that side look very cluttered and the left look essentially empty.. that's one of the main reasons I support the globe.. without it over there, that side looks empty; with it, the header is balanced IMO. I still like Search, but not for the header.. it's in my "About Wikipedia" section. About the arrangement of the links, I think TOC should go first and Index should go last with whatever else in the middle.. that's the order in a book. I still don't like portals, but if I'm outnumbered, I'm out numbered haha. I also modified the way the time was displayed to allow us to have more control over the UTC link. I still haven't been able to find a satisfactory page about why Wikipedia uses UTC (maybe we should write one?), but I think that would be an ideal link for this situation. As of now, UTC is unlinked unless someone disagrees. --Dudemanfellabra (talk) 03:34, 8 December 2008 (UTC)[reply]
I don't see why we should have Categories but not Portals. Yes, indexes go in the back of the book but categories don't go in them at all, but it's okay to have the index at the end. The globe can stay, I guess; the typeface is a definite improvement. For UTC, try Wikipedia:FAQ/Main Page#When is the Main Page updated? Why do you have the wrong date in Selected anniversaries?.--HereToHelp (talk to me) 00:27, 9 December 2008 (UTC)[reply]
I don't really link that link.. I mean it's just two lines of information. I'm looking for something in the form of WP:ABOUT except for dealing with UTC. Also, when I click on that link, something in Firefox doesn't make it go directly to that section for some reason.. so if I have the problem others are bound to have it. I would rather link to an entire article than to a section. --Dudemanfellabra (talk) 01:24, 9 December 2008 (UTC)[reply]
I think we have disagreement over "in English" clause. Stating that the article count is simply implied does not hold true to me, especially to the reader who does not understand the massive gap between languages in Wikipedia. Most users don't travel between languages because of the simple language barrier, for example if they're reading an article filled with jargon — it's much easier to understand the jargon while it's at least in your first language rather than your second. As for egoism, I'm not viewing this from such an aggressive standpoint; we aren't rivals and we aren't paranoid. All three top language Wikipedias (Spanish, German, and French) all have "in (their language)" for clarity and I think so should we.

I'm still defending the adding a link to a list of portals, although there should at least more discussion there. As for WP:INTRO and WP:ABOUT, I don't know where to place my opinion, I find that both are acceptable except "about" appears to better fit the context better than intro. "free encyclopedia" yields the definition, not a beginners guide to editing. As for "Who writes Wikipedia", perhaps intro would be more appropriate, but I'm not casting opinion there. This is the best articulation I can think of for our linking problem and let's solve this first. ChyranandChloe (talk) 05:02, 9 December 2008 (UTC)[reply]

I think "in English" should be included but the link should be to some multilingual coordination page; I've added one to the header above (hope you don't mind). UTC should go to a page about how Wikipedia's timekeeping is structured (if such a page exists…). I've rearranged the order of the links in a way that I think makes more sense; I feel that it should be arranged logically, not alphabetically. Furthermore, while WWW is theoretically a good link, it is part of a complex hierarchy of help pages and is not particularly welcoming to newcomers, drawing a line between the volunteers and the readers and tossing out a lot of jargon. We need something more encouraging, along the lines of "Who writes Wikipedia? You can!". I think the Introduction is therefore much better and have linked it. Please consider my arguments (and read WP:WWW), but if you still disagree you can revert my edits to the sample header.--HereToHelp (talk to me) 00:24, 10 December 2008 (UTC)[reply]
(outdent) I don't understand your logic in organizing the links, can you explain? I also approve of changing the "in English" link. I think the issues between WP:INTRO and WP:WWW is between you and Dudemanfellabra; I don't have much of an opinion on this other than the arguments above (it fits the context). If Pretzels would join in, I think that would improve the discussion. Other than that, I think the main point is that we approve of the design, while we finishing our resolve over the links. If you concede as well, can we insert it into the draft to see how it looks? ChyranandChloe (talk) 05:58, 11 December 2008 (UTC)[reply]
I took out the period on the "in English" part... it's not a sentence. I don't really like "hosting," but I don't have a logical reason or anything. My design says "Currently ___ articles in English." I still like WWW and think it's the most logical, best-fitting link for that location. We don't have to treat our readers like our 5 year old children playing community tee-ball by being all cheery and "Yes you can"-ish; tell them the information they need to know and be done with it. Another reason I like WWW and not INTRO is that INTRO and ABOUT are essentially telling the reader the same thing; I'm fine with either link (preferably ABOUT), but both shouldn't be there. If you can find a suitable article besides WWW, I'm willing to concede, but I oppose INTRO, and have reverted the linking. .....But this back and forth is getting nothing accomplished haha.. we need other opinions. Seems like everyone's focused on GA/DYK right now and not worried about anything else. I think we should go ahead and copy/paste the header.. that'll get their attention haha. If that doesn't get people commenting up here, then Idk what will. --Dudemanfellabra (talk) 06:43, 11 December 2008 (UTC)[reply]
In a book, the Table of Contents is first and the Index is last. Alphabetically, it's switched. I'm saying we should follow the conventions of a book because readers will expect that. I'm still not thrilled with WWW and (to a lesser extent) categories. (The article count line looks good.) Nevertheless, I agree: let's go ahead and stick it in the draft.--HereToHelp (talk to me) 01:50, 12 December 2008 (UTC)[reply]
I'm challenging the idea that the reader would expect the layout to be as a book; in addition to Wikipedia is not on paper, how would Categories fit in a book? Or Portals for that matter if we decide to include it. Alphabetically is, in my opinion, the most rationale and arbitrary method; it is furthermore the most obvious. In linking to either WP:WWW or WP:INTRO, is it possible to link "anyone can" to WP:WWW and "edit" to WP:INTRO?

I linked UTC to the article explaining what it is, until of course, a better page is found. I think we concede kind of half way, the link HereToHelp provided seems to be centered on the editor and is only a sentence long. Which either we end up choosing I think it should be linked nevertheless. ChyranandChloe (talk) 04:34, 13 December 2008 (UTC)[reply]

I agree with Dudemanfellabra - 'hosting' is a bit too technical. We should aim for something more accessible to the layperson. Also, I changed the heading "Wikimedia foundation" to "Wikimedia Foundation". Should we like to wmf: or something in the opening sentence of the paragraph below? This, that and the other [talk] 09:55, 13 December 2008 (UTC)[reply]
Thank you for capitalizing "Foundation"; I don't know why it wasn't already. This section is for discussion about links and phrases in the header, though, so let's stick to talking about those things. I'll mention your comment about the link in the proper section (Combining Sister Projects and Langauges). About including "hosting" or not, IMO we shouldn't put anything there; simply saying "Currently ___ articles in English" would work with me. --Dudemanfellabra (talk) 18:36, 13 December 2008 (UTC)[reply]
(outdent)I think we lost some flow when "currently hosting" was omitted, and there should be a linking verb between Currently and the value. This makes it the statement choppy and there is plenty of room for some more text. Also what do you say about the compromise between WP:INTRO and WP:WWW? ChyranandChloe (talk) 03:29, 15 December 2008 (UTC)[reply]
I don't see "currently hosting" as necessary.. I'm more willing to allow "currently" than "hosting" (hosting is a techie word), but simply saying "___ articles in English" suffices. Yes there's room, but "currently" is already implied; I don't think people would go to the main page and expect a past or future amount of articles. About the compromise, I don't like it. It makes the link look like [[anyone can edit]] instead of [[anyone can]] [[edit]], and there's some WP page that advises against that (laziness prevents me from looking it up). --Dudemanfellabra (talk) 05:28, 15 December 2008 (UTC)[reply]
WP:MOS:L --HereToHelp (talk to me) 01:35, 16 December 2008 (UTC)[reply]
[edit]

The current header is "Welcome to Wikipedia, the free encyclopedia that anyone can edit." I think that this is overload of links that are not particularly helpful. The words [[free content|free]] [[encyclopedia]] look like [[free encyclopedia]], which is something MOS says not to do. I also question the value of explaning ourselves viia encyclopedia articles when we have pages tailored to do just that already. I suggest "Welcome to Wikipedia, the [[Wikipedia:About|free encyclopedia]] that '''[[Wikipedia:Introduction|anyone can edit]]'''.", which looks like this: Welcome to Wikipedia,the free encyclopedia that anyone can edit. We direct traffic to the about page if you want to know who we are, and most of the traffic will be drawn by "anyone can edit," which bolds the existing link to the Introduction.--HereToHelp (talk to me) 23:33, 28 November 2008 (UTC)[reply]

A lot of elements in the header can be combined with the sections in the appendicies (e.g. Other areas of Wikipedia, Wikipedia's sister projects). There are two elements I am pursueing to move: Portals, and the links below the header box. So let's look into developing the scheme for the appendices for these two new sections. Also, before we start proposing designs, is there anything you want to add? ChyranandChloe (talk) 00:27, 29 November 2008 (UTC)[reply]
I don't think it's overlinked at all, but I do think the links should be changed. In fact, in my proposal (the updated version), I proposed "[[Wikipedia:Introduction|Welcome]] to [[Wikipedia]], the [[Wikipedia:About|free encyclopedia]] that [[Wikipedia:Who_writes_Wikipedia|anyone can edit]]." which displays as "Welcome to Wikipedia, the free encyclopedia that anyone can edit." --Dudemanfellabra (talk) 02:33, 29 November 2008 (UTC)[reply]
Dudemanfellabra: That makes sense logically, but I think people will click on what's provocative, the idea that anyone can edit. Besides, it's also last, so viewers will remember it more strongly than previous links, and their memory and focus deteriorates with each link you add. ChryanandChloe: I really like 88wolfmaster's idea of having jump-to links at the top of the page (they're in the header). I would like to see "On this page:" to clarify what they are, but they could clue the reader in to what's on the page, which is especially helpful for small screens. Perhaps we could put these links where the portals are now, and the "Other areas of Wikipedia"/"Find an article" between the header and TFA/ITN? That would make that information much more visible without getting in the way of the dynamic content. See my sandbox. --HereToHelp (talk to me) 04:45, 29 November 2008 (UTC)[reply]
Although I disagree with HereToHelp's argument about user's "memory and focus", I do prefer their simpler proposal for the links (minus the bold). Instead of a weird psuedo-sentence, however, it would be better to use "Welcome to Wikipedia" as a header, and the rest as a slogan. PretzelsTalk! 19:25, 29 November 2008 (UTC)[reply]
I could drop the bold and punctuation if that's what people want.--HereToHelp (talk to me) 20:21, 29 November 2008 (UTC)[reply]
(outdent) I think we're moving a lot of the links to the currently titled "Other areas of Wikipedia" and developing "Portals" section. #Other areas of Wikipedia. In a matter speaking, I think we need to revise the header from being a link farm, as it currently is with the portals and so forth. HereToHelp, I like 88Wolfmaster's as well, and I think that's were we're headed towards by unloading the links into other sections. ChyranandChloe (talk) 21:19, 29 November 2008 (UTC)[reply]

Capitalization in Headers

[edit]

I think the the first letter in every word of the headers for all sections should be capitalized. Lowercase headings look really unprofessional. "Today's featured article," "Did you know...," "This day in history," etc. should become "Today's Featured Article," Did You Know...," and "This Day in History." --Dudemanfellabra (talk) 02:03, 29 November 2008 (UTC)[reply]

Yes, but everywhere else they use sentence case ("Capitalization in headers"), per MOS. Again, let's not do something one way here and another way everywhere else. --HereToHelp (talk to me) 05:04, 29 November 2008 (UTC)[reply]
Hmm.. I didn't know that haha.. I've always capitalized. Guess I should go change my edits haha. Is there any reason sentence case is used? --Dudemanfellabra (talk) 05:10, 29 November 2008 (UTC)[reply]
Dunno. Maybe it's easier than trying o figure out what should and shouldn't be capitalized.--HereToHelp (talk to me) 05:27, 29 November 2008 (UTC)[reply]
Yeah, by using the capitalization scheme set by the WP:WPMOS, I think their rationale was to cut down on the number of captial letters which would make it difficult to distinguish the proper nous from the rest of the title. I think we and justify a position against the WP:MOS; however, out of habit, I'm not exactly willing to go against it. ChyranandChloe (talk) 20:45, 29 November 2008 (UTC)[reply]
[edit]

I believe the current TFA displays too much content on the Main Page, making the text feel unnecessarily "heavy". I think this detracts user interest and reduces the number of visitors to the featured articles themselves, especially visitors not attracted by the FA topic at first glance. This is worsened by the fact that it does not separate paragraphs (which the full articles do) making the text even harder to read.

The point of displaying FAs on the Main Page is not to make people stay on the Main Page and read them there, but to catch their interest so they visit the articles themselves, much like the lead paragraphs on news sites that link to the full articles. By reducing its length by 50% I believe we would get a significant increase in FA readers and visitors from the Main Page. - Wintran (talk) 14:24, 28 November 2008 (UTC)[reply]

I strongly agree with all these points, and admire how well you have explained them. I also think the featured article could be made more attractive by using a larger image size and possibly larger text. PretzelsTalk! 22:04, 28 November 2008 (UTC)[reply]
Maybe not bigger font, but a bigger picture I could go for, if it doesn't screw up the formatting on small screens. But as for shortening the text, sure - but that's something to take up with the FA people.--HereToHelp (talk to me) 22:56, 28 November 2008 (UTC)[reply]
I think we need to contact the FA wikiproject to see how they're running it. Unlike the POTD, they do not seperate their content into separate modules, and because of this we cannot create a custom template like we did with the POTD. As much as I enjoy manipulating the content to fit our design goals, we do not directly create or format it: we simply import it into a global scheme. The POTD template I am referring to is User:ChyranandChloe/Workshop 6. ChyranandChloe (talk) 00:33, 29 November 2008 (UTC)[reply]
Without wishing to sound like a chorus. I strongly agree too but would go even further limiting it to maybe a fourth of what it is now. It should act a teaser for readers go and read the rest of the article, rather than a summary. Ending it mid-sentence could even be encouraged so that users would be more likely to go to the article. Today's featured could be limited to something like:
Today's featured article
Murrumbidgee River at Balranald, New South Wales
Murrumbidgee River at Balranald, New South Wales
The Riverina is an agricultural region of south-western New South Wales, Australia. It is distinguished from other Australian regions due to the combination of flat plains, warm to hot climate and an ample supply of water for irrigation. This combination has allowed the Riverina... (Read on..)
45 words and a useful corner box rather than acontent hog. — Blue-Haired Lawyer 13:20, 14 December 2008 (UTC)[reply]
Leave off in the middle of a sentence? No way! That mockup bears an uncanny resemblance to a "please log in to your paid account to view the rest of the article" situation. A good FA's lead is bursting with info and has been carefully designed to convey it as simply yet as quickly as possible. We need a comprehensive look at the article if we are to "sell" it (for free, of course). The shortened version hardly conveys that Wikipedia is comprehensive. That said, let's try to remove a few sentences. We wind up with:
Today's featured article

Murrumbidgee River at Balranald, New South Wales

The Riverina is an agricultural region of south-western New South Wales, Australia. The Riverina is distinguished from other Australian regions due to the combination of flat plains, warm to hot climate and an ample supply of water for irrigation, making it one of the most productive and agriculturally diverse areas of Australia. Home to Aboriginal groups for over 40,000 years, the Riverina was originally settled by Europeans in the mid-19th century as a pastoral region providing beef and wool to markets in Australia and beyond. The 20th century saw the advent of rice and wine grapes. ( Read on…

Recently featured: Albert SpeerMana series2008 Men's Olympics road race

I deleted two types of content: meta-discourse (wordy language, talking about talking, failure to use pronouns) and geographical info that means nothing to a non-Australian. South-west Australia, that's about as much as I need to know. Notice how we get a shorter paragraph but don't seem to lose much.--HereToHelp (talk to me) 13:46, 14 December 2008 (UTC)[reply]
The aim of commercial web design is to make websites more inviting and usable. It aims to encourage users to enter the site and to reduce the number of mouse clicks required to buy something. Wikipedia does not sell anything but encouraging users to enter the site and reducing the number of clicks that they need to make to access content, are presumably what we've meant to be aiming at. — Blue-Haired Lawyer 14:13, 14 December 2008 (UTC)[reply]
The same principles of design that were developed to sell paid for services, newspapers and so on, are useful here. The Main Page is essentially an advert for the rest of the encyclopedia. It should encourage people to click on links as much as possible. I'm not suggesting people should pay for content but the hit count for featured content would increase.
I disagree. The MP is an advert, but I feel that the best way to "hook" readers is to let them know a little more. It's annoying to have to click to finish a sentence. It's more enticing to give them more information and then have them click for details. Under my version, they have more content with 0 mouse clicks and the exact same content after one.--HereToHelp (talk to me) 15:11, 14 December 2008 (UTC)[reply]

Aesthetics

[edit]

The main page is the most obvious and influential advertisement on Wikipedia, and within my opinion this aspect is perhaps more essential than the self-promotion of the various feature content groups. I do not feel that we can send the a proposal to the community unless we can accomplish several goals:

  1. Professionalism, as Wikipedia becomes a more authoritative, it needs to become more austere. We are now beginning to concentrate on appealing to more knowledgeable users, experts, and by that we are not here to waste their time with eye candy. Therefore we have toned down the colours and removed unnecessary shapes, boxes, and so forth—that may become distracting; and thus lending greater emphasis to the feature content: the meat of Wikipedia.
  2. Enticing, the main page is still an advertisement, or rather a promotion. We need to make it engaging and appealing. Therefore when a reader comes onto this page, they need to feel as if they don't want to leave it until they've read all or most of the content and still want more. The first step is to get them to pay attention to the page; the second is to keep them on it.
  3. Organization, the main page need to be organized enough that the user will have little or no difficultly distinguishing the different types of content. So far we have distinguished dynamic and static. The FA, DYK, ITN, POTD, and so forth is dynamic, the remainder is static. One capability in aesthetics is to subtly guide the reader to distinguish the two.

I've omitted Usability, since this belongs in a discussion of its own. We can subsubsection (level 4) from here over specific points. We can go over some of our independently developed proposals to see what's been done. ChyranandChloe (talk) 21:35, 28 November 2008 (UTC)[reply]

5theye
88wolfmaster
Alexfusco5
Alvaro_qc
AMK152
Aquillyne
Artyom
Blackhole77
Calibas
ChyranandChloe
Combined proposal (Scottydude)
CrazyChemGuy
CRGreathouse
Dudemanfellabra
Eitch
Electrical Experiment (2)
EricV89
Five Fifteen 2
Five Fifteen
Futurebird
Gnangarra
h2g2bob
Hazelorb
Hereford
HereToHelp
Highfields
Ikzing
Ishikawa Minoru
Jackl
Jennavecia
Kollision
Kollision2
Kpalion
LaraLove
Lights
Mangler13
MindstormsKid (2)
MindstormsKid
Miserlou
MZMcBride
Nat/Alpha
Nat/Beta
Nat/Gamma
NickPenguin
Onecanadasquarebishopsgate
Polishname
Pretzels
Pro bug catcher
Red Thunder
RichardF
RichardF2
Ryan Postlethwaite
Ryan
RyRy 2
RyRy
RyRy
Scolaire
Scottydude (2)
Scottydude
Soxred93
SusanLesch 2
SusanLesch
Tabbed
TakuyaMurata
Tlogmer
Trevor MacInnis
WBOSITG
Wintran 2
Wintran 3
Wintran 4
Wintran
Workshop 14 (ChyranandChloe)
Xenus
Zrs 12

While we're currently focused on content, these are very good points to bring up. The first two points are a balancing act, although if you take austere too far, you get into dreary and lifeless, which is almost as bad a gaudy and flashy. Also, thank you for taking up the dynamic/static distinction. It also helps as far as not going overboard with formatting. I agree with your points, but they aren't the primary focus at the moment.--HereToHelp (talk to me) 23:18, 28 November 2008 (UTC)[reply]
It may not be the primary focus at the moment in your opinion, however this is perhaps the primary focus in mine. There is no significant change in content, only a minor revamp. Therefore in order to make this proposal worth the consideration of the community, we have to do more than just a few renames and rearrangements. Additionally, this aspect was the first element on the charter that began the proposal, I think it deserves more attention than its getting. ChyranandChloe (talk) 00:17, 29 November 2008 (UTC)[reply]
That's fine, as long as differences of opinion on style don't get in the way of consensus on content. So far, so good.--HereToHelp (talk to me) 04:32, 29 November 2008 (UTC)[reply]
Ok then, let's get started with a color scheme. ChyranandChloe (talk) 21:03, 29 November 2008 (UTC)[reply]

Dynamic-static design focus

[edit]

In order to distinguish the static content from dynamic content:

  • In static content we can:
    • Lighten the text from being solid black to dark gray
    • Or by changing the opacity to approximately 90%, and therefore slightly lightening the static content
    • The reason for this scheme is that it give a feeling of depth: which subtly guide the reader to start with the dyanmic content, the featured content. By this it accomplishes two things: (1) It allows the reader to quickly catch onto what would be most interesting and therefore prevent them from simply clicking away, and (2) It prevents the reader from becomming overwhelmed by the amount of content, it tells them to "start here" and if you're interested "move to here"
  • In Dyanmic content we can colorize slightly to be most disginguish, the current scheme accomplishes this

ChyranandChloe (talk) 21:03, 29 November 2008 (UTC)[reply]

Color scheme

[edit]

The blue and green look rather similar. It might be premature, but if we're moving all featured content to one column, can we make it a gold color? I think that would work well with the blue that we have.--HereToHelp (talk to me) 03:29, 30 November 2008 (UTC)[reply]

Gold would be a good choice for featured content, partnered with the associated star. PretzelsTalk! 04:34, 30 November 2008 (UTC)[reply]
That would be interesting, but that's a pretty invasive reconstruction of the main page. ChyranandChloe (talk) 08:35, 30 November 2008 (UTC)[reply]
The star is better than most as far as icons, because it's fairly clear and commonly used; it would be good to visually link the star and featured content early on. That also might give us an opportunity to link to Portal:Featured content. My biggest concern is how would we balance it on the other side, the ITN/DYK/TDIH (formerly OTD) column. There isn't an easy label for them like Featured Content; they're just what's left over. (My best idea is "Day to day," but that might us trouble with Day to Day.) Neither is there a corresponding icon, and I'm worried about having only one icon on the MP. Changing the hue might be more intrusive but won't leave us with an icon and a label with no conterparts.--HereToHelp (talk to me) 13:52, 30 November 2008 (UTC)[reply]
The In the news / This day in history column should be narrowed and without a background. This would alleviate the above worries, while providing more of a visual path for the reader. We could use an idea from a very early proposal of mine: merge the two into a section simply headed with today's date. PretzelsTalk! 16:46, 30 November 2008 (UTC)[reply]
I think removing the color would take too much emphasis away; Featured Content is only half of the dynamic content. I like today's date, though that would be dynamic and Portal:Featured content is static (and you're not supposed to link headers, anyway). That, and we still don't have an icon. You might be able to find one, but it's not going to match the Featured star and I don't think it's going to be commonly used elsewhere.--HereToHelp (talk to me) 23:05, 30 November 2008 (UTC)[reply]
Thanks. My point is that if we use too much emphasis, it's no longer emphasis - that's how I feel about the current main page. If we emphasise featured content visually over the other sections, it will appear far more professional. The page is already slightly weighted towards the left, let's go with that and be bold.
Regarding a date icon, any Nuvola-type calendar could be used, but an icon is probably unnecessary here. PretzelsTalk! 10:55, 2 December 2008 (UTC)[reply]
I'm still not sure. How about you sandbox it, post a link here, and I'll make up my mind once I've seen it? More featured emphasis might justify an icon for it and not for the other stuff (would a calendar icon have to update daily?), but we'll need more than one article and one image (media) for it to work. Try the yellow, too; see if you can get it to be gold.--HereToHelp (talk to me) 00:29, 3 December 2008 (UTC)[reply]
I couldn't get the color to look gold while retaining the standard saturation and lightness (see HSL and HSV) but playing with it a little more liberally I got this:
Today's featured article
St George and the Dragon atop Mells War Memorial
St George and the Dragon atop Mells War Memorial

Mells War Memorial is a First World War memorial in the village of Mells, Somerset, in south-western England. Designed by Sir Edwin Lutyens, the memorial takes the form of a marble column topped by a sculpture of Saint George slaying a dragon (pictured). At the base of the column, the names of the village's war dead are inscribed on stone panels. The memorial is flanked by rubble walls in local stone, on top of which grows a yew hedge. Low stone benches protrude from the walls to allow wreaths to be laid. The memorial is one of multiple buildings and structures in Mells designed by Lutyens. The memorial was unveiled on 26 June 1921 by Brigadier-General Arthur Asquith, whose brother is commemorated on it and whose father was Prime Minister of the United Kingdom for much of the war. Additional panels were fixed to the wall to commemorate the Second World War. It is a grade II* listed building and since 2015 has been part of a national collection of Lutyens's war memorials. (Full article...)

Recently featured:
Any takers?--HereToHelp (talk to me) 22:14, 3 December 2008 (UTC)[reply]

[unindent] This is great. I'm very impressed with how good that looks colourwise. My botched attempt is a lot more "toned down" but is not half as effective. We should see how this looks combined with the proposals for 50% of the text and a larger image. PretzelsTalk! 00:47, 5 December 2008 (UTC)[reply]

White background
[edit]

It has been discussed above in the Header links section that the background to all the sections should be white instead of tinted blue and green. The current tints make the page look color-crazy and strain the eye in my opinion. With a white background, there is less color and more professionalism. An example of how the sections would look with a white background can be found here. Any comments? --Dudemanfellabra (talk) 17:31, 4 December 2008 (UTC)[reply]

I agree, but perhaps slightly offwhite migh work better?--HereToHelp (talk to me) 00:38, 5 December 2008 (UTC)[reply]
Certainly not every piece of content - regardless of whether it's dynamic or static - should have a background, these things are for emphasis. PretzelsTalk! 00:47, 5 December 2008 (UTC)[reply]
When in doubt, sandbox. White:
Today's featured article
St George and the Dragon atop Mells War Memorial
St George and the Dragon atop Mells War Memorial

Mells War Memorial is a First World War memorial in the village of Mells, Somerset, in south-western England. Designed by Sir Edwin Lutyens, the memorial takes the form of a marble column topped by a sculpture of Saint George slaying a dragon (pictured). At the base of the column, the names of the village's war dead are inscribed on stone panels. The memorial is flanked by rubble walls in local stone, on top of which grows a yew hedge. Low stone benches protrude from the walls to allow wreaths to be laid. The memorial is one of multiple buildings and structures in Mells designed by Lutyens. The memorial was unveiled on 26 June 1921 by Brigadier-General Arthur Asquith, whose brother is commemorated on it and whose father was Prime Minister of the United Kingdom for much of the war. Additional panels were fixed to the wall to commemorate the Second World War. It is a grade II* listed building and since 2015 has been part of a national collection of Lutyens's war memorials. (Full article...)

Meh. Try it with a neutral offwhite:

Today's featured article
St George and the Dragon atop Mells War Memorial
St George and the Dragon atop Mells War Memorial

Mells War Memorial is a First World War memorial in the village of Mells, Somerset, in south-western England. Designed by Sir Edwin Lutyens, the memorial takes the form of a marble column topped by a sculpture of Saint George slaying a dragon (pictured). At the base of the column, the names of the village's war dead are inscribed on stone panels. The memorial is flanked by rubble walls in local stone, on top of which grows a yew hedge. Low stone benches protrude from the walls to allow wreaths to be laid. The memorial is one of multiple buildings and structures in Mells designed by Lutyens. The memorial was unveiled on 26 June 1921 by Brigadier-General Arthur Asquith, whose brother is commemorated on it and whose father was Prime Minister of the United Kingdom for much of the war. Additional panels were fixed to the wall to commemorate the Second World War. It is a grade II* listed building and since 2015 has been part of a national collection of Lutyens's war memorials. (Full article...)

Or a less intense yellow:

Today's featured article
St George and the Dragon atop Mells War Memorial
St George and the Dragon atop Mells War Memorial

Mells War Memorial is a First World War memorial in the village of Mells, Somerset, in south-western England. Designed by Sir Edwin Lutyens, the memorial takes the form of a marble column topped by a sculpture of Saint George slaying a dragon (pictured). At the base of the column, the names of the village's war dead are inscribed on stone panels. The memorial is flanked by rubble walls in local stone, on top of which grows a yew hedge. Low stone benches protrude from the walls to allow wreaths to be laid. The memorial is one of multiple buildings and structures in Mells designed by Lutyens. The memorial was unveiled on 26 June 1921 by Brigadier-General Arthur Asquith, whose brother is commemorated on it and whose father was Prime Minister of the United Kingdom for much of the war. Additional panels were fixed to the wall to commemorate the Second World War. It is a grade II* listed building and since 2015 has been part of a national collection of Lutyens's war memorials. (Full article...)

 

#ffffe1

 

#fffff1

The original is the top swatch; the new one is on the bottom. It's a subtle change, but I prefer the new (f1) to the old (e1). Now we have to get the blue (will it be blue?) to match, which I can do pending acceptance of the gold. However, it's only worth doing if we keep Featured Content in the gold column, which probably means adding either another article or a list.--HereToHelp (talk to me) 02:06, 5 December 2008 (UTC)[reply]

Becareful since the background of talk pages are off white (#f8fcff), while article pages are purewhite. This subtle differnce in color can skew your color perception, which when you see pure white it give a slight tint of yellow. (If you are using an LCD, look at the screen slightly sideways — my post is colored purewhite) I think I like the f1 as well. Is it possible to have all the featured content in gold? Perhaps, rather than sticking to the previous color scheme we can use gold and light-gold for all the featured content. ChyranandChloe (talk) 04:01, 5 December 2008 (UTC)[reply]
Now that the new header is in the proposal, I think we need to come to a consensus about white backgrounds in the content sections. It appears to me that most people generally agree with the white background - whether it be off-white or pure white. If there is no objection, I will update the code to reflect this consensus. --Dudemanfellabra (talk) 04:03, 12 December 2008 (UTC)[reply]
The header is rather austere with little colour. After you're finish implementing this in the draft, I think the next step would be looking at a more toned down version of this. ChyranandChloe (talk) 05:07, 13 December 2008 (UTC)[reply]
I just added in the white backgrounds (not pure white - actually #fcfcfc). I don't really understand your last comment; can you clarify what you're talking about? --Dudemanfellabra (talk) 21:39, 14 December 2008 (UTC)[reply]
The white looks ok, though I'd also like to see a version very lightly saturated with the color of the column, like the last mockup above.--HereToHelp (talk to me) 22:38, 14 December 2008 (UTC)[reply]


[edit]

Your template has a bug that I just found (It was in mine too). For today (December 1), the "Recently Featured" pictures result in an error when it tries to call {{POTD/2008-11-31}}.. When you were typing your code, you accidentally shifted the dates for each month (in the #switch parameter) up one. You're using {{CURRENTMONTH}} in that code, so it gives you the current month. Doing the subtraction of days would make the month decrease one; therefore, you have to shift the numbers for each month down one. I don't think I'm doing a very good job at explaining this, so just take a look at this diff to see what I did. The template is fixed now, though I think ours differ slightly.. something about CSS I think.. not exactly sure. Later! --Dudemanfellabra (talk) 16:21, 1 December 2008 (UTC)[reply]

I just found another bug dealing with recently featured pictures when the CURRENTMONTH is larger than 10. Your code was forcing a zero at the beginning of the subtracted month, so today (December 2), the template was trying to call {{POTD/2008-011-30}}. This diff shows how to fix the code by adding an #ifexpr statement to determine whether or not the month will need a zero after subtraction. Haha apparently we'll get all the bugs worked out sometime.. I can't forsee anything else going wrong with it because I was forced to look at the code in detail this time to figure out how you were doing the math, but if anything does go wrong, I'm sure we'll find it. --Dudemanfellabra (talk) 17:30, 2 December 2008 (UTC)[reply]
Thanks for the update, I'm a bit busy right so it makes it a challenge to keep the patches up with the code. Nevertheless it's applied. Sorry about not breaking the lines or indenting the code, it must be a challenge to read and understand; and I appriciate the effort you've placed into this. ChyranandChloe (talk) 03:15, 3 December 2008 (UTC)[reply]

This is not necessarily a bug, but in my template, I redirected the links for recently featured images to the POTD templates themselves instead of the article in which the picture is displayed. Sometimes the articles (such as Pink Cliffs on 2008-12-07) are very short and stubby and hardly look appropriate to be linked on the main page. The current main page links to the POTD template, so I did the same. Another reason I think this is appropriate is that these links are in the featured MEDIA of the day section.. not featured ARTICLE; when a user clicks on that link, (s)he expects to see a media file - not an article. Yes, this effectively doubles the code because you have to determine the right date twice (once for the image title and again for the link text - image and texttitle respectively), but unless you can think of a better way to do it than in this diff, I see no avoiding the size problem. I will try to come up with a better system of determining the date, though, because at over 7kb, the template is massive IMO. --Dudemanfellabra (talk) 21:38, 8 December 2008 (UTC)[reply]

Update: I've been working on a new method of determining time (by researching the underworkings of {{CURRENTDATE}}, etc.) and found the #time function. By implementing this into the design and rethinking the method of displaying the dates, I've been able to shrink the code drastically. Unlike the old code, I split determining current year, month, and day each into its own respective #ifexpr branch; this allows the code for each recently featured picture's year and month to be identical - the only thing that changes among them is the code for determining which day to display. Even though I effectively doubled the old code by making the links go to the POTD template, I still came out with a net reduction of template size. The code size isn't 7 kb any more.. nor is it even 4.1 kb (as it was before the doubling).. it is now only 3.3 kb.. a net reduction of about 750 bytes from it's pre-doubled condition. I believe that since the #time method takes much less space(<50%!), it is the way to go. Check out the code here. --Dudemanfellabra (talk) 01:18, 9 December 2008 (UTC)[reply]
Congratulations, I think you're building the foundations for a new method of importing content into the main page. See one the key reasons why I like the POTD template so much is because of how modulated it is. Effectively, the entire template is built of small pieces: which allows us to build the template for the main page rather than the main page for the templates. If we could do this with with the FA, OTD, and so on—we could make those drastic changes (especially some of those Pretzels wanted) entirely feasible, given that we do not have to go through the arduous process of proposing a change to the template and praying that the Wikiproject will pass. ChyranandChloe (talk) 04:09, 9 December 2008 (UTC)[reply]

Update: So umm.. I'm gonna stop writing on here about this template sometime haha... but I just found something that makes the template even smaller. Apparently the #time function has a built in parameter that allows one to call the current date, minus x number of days.. this is done by calling {{#time:Y-m-d| -x days}}. There's no need for all of our ifexpr and months and leap year and crap like that haha... the thing already does it for us.. Now instead of being 7 kb... or even 3 kb.. the template is only 848 bytes haha.. big improvement I'd say. --Dudemanfellabra (talk) 21:17, 9 December 2008 (UTC)[reply]

I think that's a good idea, I'll migrate all this discussion into the MPRP. Now, this is starting to bother me seeing that I didn't find that in the code research back when I started witting the template; I'm laughing, nice job. ChyranandChloe (talk) 04:57, 11 December 2008 (UTC)[reply]
Now that this is publicized, can anyone figure out how to fix another bug I found? If the caption has a list (numbered or bulleted), the right margin of the picture go wacko. I tried putting the picture in a div with a right margin of 2em, and when that didn't work, I tried floating it left and giving it a right margin of 2em. The latter worked, but when there isn't a list, there's a big space between the picture and the caption.. I also tried floating the caption right and adding a br style="clear:right" after the picture, but if the template was used in a wide bar (such as that on the current main page), there would be an even bigger space between picture and caption (On a small setup like that in my design, it would work, though). Anyone know how to fix it to be able to work in both a wide and narrow format regardless of whether or not there is a list in the caption? The bug is showing up currently (2008-12-11) with the numbers cut off by the picture. --Dudemanfellabra (talk) 05:26, 11 December 2008 (UTC)[reply]
You can embed it in a table, with the if statements. If you have trouble I can do it tommorow. ChyranandChloe (talk) 06:18, 11 December 2008 (UTC)[reply]
Drupe development
Drupe development

A six-image montage showing the development of a typical drupe, the nectarine (Prunus persica) over a 7½ month period:

  1. Bud formation (early winter)
  2. Leaves start to develop (early spring)
  3. Flowers are pollinated (early spring)
  4. After successful pollination, incipient fruit forms (mid-spring)
  5. Fruit is well developed and continues to grow (late spring)
  6. Fruit fully ripens (midsummer)

Photo credit: John O'Neill

Recently featured: Reconstruction political cartoon - Shanty town, Soweto - Shanty town, Soweto

Yes, but if I put it in a table, the caption won't wrap around the picture (I'll essentially be recreating the current POTD template). I would like the margins to be correct and for the text to wrap around the picture. (Unless I'm totally off base as to what "embedding in a table" means. --Dudemanfellabra (talk) 07:01, 11 December 2008 (UTC)[reply]
Ok, I've imported the code into the discussion, and froze the time. Let's see what we can do. ChyranandChloe (talk) 05:33, 13 December 2008 (UTC)[reply]
(outdent) I also think we need to talk about panoramas. Currently the code is set up to show scrollbars on panoramas that would stretch the column width. Well the pixel-width of the section is set to 800x600, so on any larger screen, the layout looks horrid. Is there any way to make the width parameter flexible with the different monitor sizes? --Dudemanfellabra (talk) 22:31, 14 December 2008 (UTC)[reply]
The list issue, to my understanding, is universial. That is, this is a browser issue and is outside the scope of our template. Most websites don't float images left and next to a list item, therefore this issue has effectively evaded bug fixes. I did, however, find a solution; and that is to embed the list in a table. This will prevent it from wrapping, but at least the numbers are covered by the image. We should probably tell the POTD that next time they release a similar item.

Can you better articulate about the panoramas? I believe I understand the general idea, but not the details. Yes, there is a way to allow the panorama to be flexible with the different monitor size, however that involves some Java Script: if (window.width) {...set the width of the panorama. However, I don't think this is what we're trying to do. If you're talking about the POTD above, it was just some code I put smashed together so that we can experiment with fixes for the list; otherwise I don't think we need to worry about panoramas. I'm not sure if that answers your question, if you can give me an example that would be great. ChyranandChloe (talk) 04:42, 15 December 2008 (UTC)[reply]

Well if we're going to just embed the image in a table, we may as well not even create a new template; the existing template already embeds the image in a table. If this new template is implemented, though, POTD captions can't have lists in them, or it will break. Is there a way to determine if the caption has an <li> tag in it without using Javascript? If so, then we could make some code that would only embed the image in a table when there's an li tag.
About panoramas, on 2008-12-14 (the tank), the template looked horrible. The width of the div containing the image is set to 350px, the largest it could be to be in a 60% column on an 800x600 screen. If your screen is any larger, the div doesn't get any larger, so the image just stops before it reaches the end of the column. I think the only way to make the div width dynamic (dependant upon screen size) is to use Javascript. I've been around the site, and I've actually come up with some code to determine the screen size and return it as a variable. I tried to get this implemented as a Magic Word, but Magic Words won't work with javascript. The people over at WP:VPT told me to go to MediaWiki:Common.js and see if they'd implement the code, but I have bigger goals. I'm not ready just to throw some small code I worked together (the code btw can be seen here) in 5 minutes and see if they'll by some miracle implement it. I have a vision (and am now working on the code) to allow several different parameters to be returned. When I get the bugs worked out, I'll paste the code here for testing, and after we're sure we have all the kinks worked out, we can send it over there and see if they'll accept it. --Dudemanfellabra (talk) 06:07, 15 December 2008 (UTC)[reply]
My solution was a bit more blunt, tell the POTD wikiproject to embed the list in a table everytime they want to use one. Javascript, in my opinion, would be too invasive; furthermore we'd go back to the compatibility crisis, and this time it would be real, unlike the show/hide which degrades gracefully. I think I understand the panorama issue. You have the older version of code which specified a specific width. I actually solved that some time ago; however it takes a few more steps. The first step is to remove the "width:350px;", the second is to move away from tables and into straight CSS. We can do that after we finish some of the other proposals, I don't want to be overwhelmed by the discussions—like David I'm a bit busy this week. ChyranandChloe (talk) 04:59, 16 December 2008 (UTC)[reply]

Additions that can be made

[edit]
[edit]

One of the great things about a new redesign is that it gives us a chance to update the MP to reflect new developments in Wikipedia. We've seen the great success of Featured Lists over the last year or so, and I think it's time that we honor the lists and the project with a spot on the MP with Articles and Images (soon to be media). I've created a mockup, {{Today's featured list mockup}}, which we can incorporate into the design to see if it works or not. TFL (we could usurp WP:TFL from a semi-inactive Wikiproject) would be a great additional to our daily showcase.--HereToHelp (talk to me) 04:49, 28 November 2008 (UTC)[reply]

Thanks for the mockup, there are two things I'd like to go over before we begin drafts with the Featured Lists installed:
  • Do we have enough featured lists or potential featured lists to run in its own section
  • Will it be too much featured content on a single page; perhaps we should link to the Featured content page.
ChyranandChloe (talk) 21:24, 29 November 2008 (UTC)[reply]
For the first point, there are 1120 Featured lists, which is more than three years' worth if we did one a day. We won't, because some are in two parts or are asking to be combined (like song listings from six Guitar Hero games). Even so, go through the Signpost Archives and you'll discover that the FL people are incredibly prolific, often featuring about fifteen or twenty lists a week (we only need seven). I think it's very sustainable. We should definitely link to Portal:Featured content if we can find a convenient place to do it. They're already running FL snippets, except with alphabetical lists they just have a bunch of As; with the mockup I tried to find the more interesting or useful words. As for Featured Content inundation, that's subjective. I guess the only way to know is to make two mockups, with and without, and ask for (non binding) opinions.--HereToHelp (talk to me) 22:12, 29 November 2008 (UTC)[reply]
I don't support a new section for featured lists. I'm fine with allowing lists to be on the main page, but I think they should be included with today's featured article. Lists are articles... they're the same thing. With today's featured picture, we changed it to today's featured MEDIA by adding videos and sound. The section still appears the same, except on some days, the featured item will be a video or a sound instead of a picture. We should do the same thing with today's featured article - some days the article would be a list and others it would be a regular article. Most featured lists have a descriptive lead section, so when a list is featured, the lead section would appear on the main page, and the (more...) link would be changed to (See the list...). --Dudemanfellabra (talk) 22:26, 29 November 2008 (UTC)[reply]
  • I support the new section for the featured list; but before we'll begin a draft, lets have to modulate it into pieces like: the excerpt, title, read more, archive, and so forth.This will give us much more flexibility in the future.
  • Next off, how will we keep the content balanced? Is it its own section like the Today's featured media (TFM)? Do we merge it into a column with te TFM? Will we introduce a selected GA to keep it balanced?
  • Lastly, will there be too much featured content? There are five now, with the TFL that'll be six. ChyranandChloe (talk) 02:07, 30 November 2008 (UTC)[reply]
Dudemanfellabra's idea is a minimum, but then there'd be too much content (all 1000+ lists, several dozen? hundred? unshown articles, and about three weeks worth of new stuff every week). I'm afraid nothing (relatively speaking) would get to be shown. Some might argue that this means we can be more selective in out FAs/FLs, but I'd argue that if it passes the featured gauntlet, it should be allowed to be shown on the MP. Others say we should have two articles a day; I'm saying one should be an article and one should be a list. As for formatting, again please see User:HereToHelp/sandbox, which has the nice benefit of putting all Featured content together. And as for too much content, I think the best way to judge that is to make different versions and compare.--HereToHelp (talk to me) 03:08, 30 November 2008 (UTC)[reply]
I'd like to address and explore the point where we would have to say "Is there too much featured content". I'm not against, but I think it would be beneficial to understand how much we can put into the main page before it becomes a problem. Also do we have support from WP:FL? Or should we check. ChyranandChloe (talk) 04:29, 3 December 2008 (UTC)[reply]
I got mixed support from the FL people. As for Featured Content overload, it's something that's very difficult to evaluate in the abstract. I would like to see and evaluate a mockup, perhaps like this one. --HereToHelp (talk to me) 21:47, 3 December 2008 (UTC)[reply]

Out of ~1100 FLists, 394 are about sports or video games, 301 about music or media (mostly episode listings). Compare Image:FL barchart by number 2008-11-30.svg vs Image:FA articles 2008-11-16 bar.svg (that's a gross modern content bias). It's not PC to keep repeating, but FLs are drastically easier to build than FAs. See also the earlier survey results and various comments in the 3 archives, plus previous proposals. There is a significant and strong opposition to the idea, and no chance of consensus to add a new section for FLs. -- Quiddity (talk) 22:32, 9 December 2008 (UTC)[reply]

Dates on news items

[edit]

One idea I've been experimenting with that got quite a lot of support in the straw poll was adding dates to ITN. The reason for this is that users expect news to be associated with dates (which is standard on the web today) and that news notices without dates is confusing. An event spanning over multiple days are generally connected to the event's starting day, so this is not a problem.

Here's an example of how this could look. - Wintran (talk) 14:54, 28 November 2008 (UTC)[reply]

Looks good to me, and it shouldn't be too hard to implement.--HereToHelp (talk to me) 15:23, 28 November 2008 (UTC)[reply]
I think this decision belongs to the Wikiproject responsible for the featured content. A lot of what we're doing is to use it. ChyranandChloe (talk) 21:29, 28 November 2008 (UTC)[reply]
Some events span multiple dates... how would this be handled? PretzelsTalk! 21:53, 28 November 2008 (UTC)[reply]
As Wintran said, "An event spanning over multiple days are generally connected to the event's starting day, so this is not a problem." The beginning date would be listed. --Dudemanfellabra (talk) 23:30, 28 November 2008 (UTC)[reply]
tentative Support, based on responsible-wikiprojects enthusiasm. -- Quiddity (talk) 21:54, 9 December 2008 (UTC)[reply]
Oppose: For reasons see Template_talk:In_the_news#Dates_on_news_items ----GPPande 19:03, 10 December 2008 (UTC)[reply]
Oppose: It's unnecessary, surplus information. We need to reduce the amount of clutter on the Main Page, not increase it. PretzelsTalk! 02:22, 11 December 2008 (UTC)[reply]
Agree: It's not called "in the news" without reason. — Blue-Haired Lawyer 13:36, 14 December 2008 (UTC)[reply]
I agree with most of the objections raised on the ITN talk page. Many of our news items do not go up right away, as inclusion is based on minimum update and article quality standards. Also, the key focus of ITN is not to provide news, but to link readers to article about topical events they may have already heard about. We're not a primary source. It's an interesting idea, but I don't think it quite fits with the current form of ITN. Oppose. Random89 19:57, 15 December 2008 (UTC)[reply]

Add Question mark to "Did you know"

[edit]

Without the ellipses, "Did you know" by itself looks more fragmented. Maybe it should be "Did you know?" - Zero1328 Talk? 03:08, 11 December 2008 (UTC)[reply]

The question mark is at the end of each DYK hook.. that would make 2 question marks.. I was actually fine with leaving the ellipsis in; I think they should be removed from each individual hook instead of the header. Something I think needs to be changed is where "From Wikipedia's newest articles" appears. IMO, that should be moved to the bottom (where start an article, etc. is) so that each hook forms a complete sentence and isn't interrupted by this clause. --Dudemanfellabra (talk) 03:18, 11 December 2008 (UTC)[reply]
I think of it as a title and nothing more, however ellipses and question marks are justifiable. ChyranandChloe (talk) 06:05, 11 December 2008 (UTC)[reply]

Collapsible section headers

[edit]

Seeing this sandbox of the main page, I was inspired to give more focus to one box. Instead of using five separate section headers (TFA, ITN, etc.), there could be one box where TFA is now and five section header rollover links in a box to the right. This may seem out of place for an encyclopedia but I see many key benefits to structure the main page in this way:

  • Users have a chance to see all five sections at the top. No scrolling is needed and users are more likely to interact with this dynamic content.
  • There is more room to display static links (like portals or help) outside the main box that contains the five sections.
  • The text could be enlarged (as seen here.)
  • Because of the larger box, the featured picture section would double in dimension.

There are also potential problems with this idea:

  • I don't think MediaWiki is ready for mouseover reactions.
  • Some may see this change as morphing Wikipedia into a portal site. This feature is simply meant to improve use of screen space.

I don't want to develop this idea too much until I have a general understanding of what the community thinks. Reactions? --Blackjack48  t c 02:28, 10 December 2008 (UTC)[reply]

I'm still a little unclear as to what you're proposing, but you mean one section at a time fills the entire space, right? Yeah, it's probably too advanced to be implemented technically. But if someone can help BlackJack sandbox it, I'll certainly consider it. (Sandboxing gives us a concrete idea of what we're dealing with, and proves that the technicals are feasible.)--HereToHelp (talk to me) 03:06, 10 December 2008 (UTC)[reply]
Well, I don't know how it would be implemented...but it does sound good. – Alex43223 T | C | E 08:15, 10 December 2008 (UTC)[reply]
I think I know what you're talking about: it's the hide/show controversy. We can go over this once we get the header in, because that's a rather large topic. Alex43223, we've implemented it in our preliminary designs, I had it in mine if you want to have a look: link User:ChyranandChloe/Workshop 2. ChyranandChloe (talk) 06:01, 11 December 2008 (UTC)[reply]
I was thinking something like this (except the headers on the side are rollover, this is a very rough sketch.) The box where TFA is would change based on the rollover. --Blackjack48  t c 00:55, 12 December 2008 (UTC)[reply]
It's not functional, but I see what you're getting at. I'm afraid that such a design would inherently favor one project over another and cause to much internal conflict…like the GA debate above. But an intriguing possibility - if it can be implemented.--HereToHelp (talk to me) 03:08, 13 December 2008 (UTC)[reply]

Special Main Page formatting

[edit]

I've borrowed and changed some of the code from Dudemanfellabra's proposal to make the proposal look more like the actual main page. The code moves the page up so the header and slogan aren't visible, and mimics a white background. Sorry for the mass of edits trying to perfect the numbers. PretzelsTalk! 23:03, 3 December 2008 (UTC)[reply]

That's great. Can you show us the link?  Marlith (Talk)  00:47, 4 December 2008 (UTC)[reply]
Uh... it's this article haha.. at the top, click the "project page" tab. This is the talk page of that article. --Dudemanfellabra (talk) 00:57, 4 December 2008 (UTC)[reply]
I like knowing that I've actually arrived at the MPRP rather than the current main page in that I can simply spot the title. The administrators applied their own custom code, my assumption is display:none for the header. I'm against applying a relative position for the main page for two reasons: when we export it to the current we'd want to remove it, which can be a hassle; and second it cuts the left border of the content module. ChyranandChloe (talk) 04:16, 5 December 2008 (UTC)[reply]
...You just removed the code in one edit. How is that a hassle? I didn't have a problem with the left border, but if there is a problem (which browser are you in?), it can be fixed simply by modifying margins. The code makes the page look more like it will look when/if we copy it over. I've readded the code (modified a little) and added a banner across the top of the page so people don't get confused. --Dudemanfellabra (talk) 04:57, 5 December 2008 (UTC)[reply]
I've added a collapsible header, which should satisfy everyone. It is displayed by default. PretzelsTalk! 12:01, 5 December 2008 (UTC)[reply]

I personally think it looks too much like the current page but with things moved around and resized! Highfields (talk, contribs, review) 16:00, 5 December 2008 (UTC)[reply]

Please clarify Highfields, and I think you're getting into another topic; we'll probably run that one later. Dudemanfellbra, I'm using Google Chrome, which uses web-kit as its rendering engine. I think it's essential that we match the background colour with that of the current main page (project pages use an offwhite, the main page uses pure white) so that we are sure to get the colours right when we're experimenting; this works in your favor. But my argument is we'll have to cut some of that code out when we export it in the final draft, because the real main page has their own custom features that allows the cut the header without going to the measures we are invoking. I'm sorry if the revert was too extreme, and the hassle is in that in the argument above. I think it's more ammendable if we separate the code that is the draft and that of the proposal (porposal, header, so on). I've applied the patch. ChyranandChloe (talk) 04:00, 6 December 2008 (UTC)[reply]

OMG. All these months of discussion and thats what you're proposing? Hardly a change Count Blofeld 10:57, 6 December 2008 (UTC)[reply]

If you look through all the discussion on this page, we're discussing tons more.. such as white backgrounds on dynamic sections, creating a completely new header, changing the color scheme and possibly including gold for featured content, and many other things. We're in the discussion stage right now, though, so we can all come to a consensus as to what exactly we want. If you read the box at the top of the proposal page, you will see it says discuss everything before editing; that's what we're doing. The current state of the proposal page is by no means our final design. --Dudemanfellabra (talk) 18:21, 6 December 2008 (UTC)[reply]
I forgot to mention, that patch I applied earlier fixed the problem. Also em is the wrong unit, it's relative to the default text size on the computers. Although it's not significant, those people who have their text sized increased for accessibility will have the padding increased as well. I recommend using px. ChyranandChloe (talk) 06:09, 11 December 2008 (UTC)[reply]

Removing the side bar

[edit]

I'm jumping right in here but it wouldn't be that different to removed the whole of the left side bar using css or perhaps a small patch to the software. The home page of most sites have a different layout to the rest of the site. Removing the side bar would allow much more horizontal width and remove duplicate elements like the search bar and links. — Blue-Haired Lawyer 20:24, 13 December 2008 (UTC)[reply]

It also would eliminate a valuable opportunity to introduce readers to our interface. —David Levy 20:43, 13 December 2008 (UTC)[reply]
David has it. We'd only gain about 150px anyway, and would have to find somewhere to put all the sidebar content anyway. PretzelsTalk! 16:22, 14 December 2008 (UTC)[reply]

Assorted comments

[edit]

I'm sorry that I've been too busy to keep up with this endeavor. I'll take this opportunity to comment on the current draft.

Header

  • Background image - This was removed from the last main page redesign when we realized that it caused problems on some displays (by being unrecognizable and/or rendering the accompanying text difficult to read). And in this particular instance, it duplicates the logo that would appear next to it in the default skin.
  • Date and time - This has been suggested on several occasions, but it simply wouldn't work; because of caching, it would frequently be incorrect. Perhaps we could include the date alone, provided that a bot were set up to purge the page's cache at 00:00 (UTC).
  • Removal of links - I'm fine with this. The omitted links are either redundant or unnecessarily prominent.
  • Removal comma and full stop from "Welcome to Wikipedia, the free encyclopedia that anyone can edit." - Is this intentional?

Footer

What's going on here?
What is the point of combining the two sections in one? It only seems to make it confusing to read.
Why have the other languages been moved back up, but with most of them removed (and a plain text mention of English)? In the previous redesign, we established broad consensus for the solution of moving the "Wikipedia languages" section to the bottom, thereby enabling us to include any number of languages without forcing readers to scroll through them to access other content. This seems like a major step backwards.
Why are there now five sister projects on each line (including a plain text mention of Wikipedia)? The code that causes this to change makes the layout look terrible when there are four sister projects listed on each of the first two lines and only two on the third line (left-aligned instead of centered). How is this supposed to be an improvement?
I don't mean to be negative, and perhaps I'm missing something. —David Levy 20:43, 13 December 2008 (UTC)[reply]

I agree, the header needs work. There's not enough contrast between the image and the text, and, at least in my browser, the 't' in "the" slightly overlaps the image, which looks awkward. The right side seems rather cluttered. "Currently hosting 2,657,770 articles in English" - currently hosting? What's wrong with the current "2,657,774 articles in English"? It gets the same information across without being overly wordy and sounding incorrect (a wiki is more than just a web host). I have to agree with Majorly below, what was the point of all the asking for designs and straw polls and discussions if the design is just a slight tweak to the current page? Mr.Z-man 21:19, 13 December 2008 (UTC)[reply]
If the previous design was so good, how could you expect anything but tweaks? And who says we're done? As for the header, please read (or at least skim) this discussion. I brought up the points regarding the background image, but Dudemanfella felt that it helped add vibrancy to an otherwise empty left side of the header. I do support the larger "Welcome to Wikipedia," although the links are still under debate. I removed "hosting" from the article count; "currently" can go too. The time is already present in the OTD templates (we've changed the title to "This day in history" because ellipses were felt to be informal and did not yield a complete sentence). By moving it up, we hoped to introduce readers to UTC and why the Main Page was not showing the correct date (for them). I'm not sure why the English Wikipedia has plain text links; I don't like them. (Maybe the globe balances the icon layout?) I prefer this for additional links as far a s layout (not specific links) and this for sister projects - yes, left aligning looks awful. Color is still very much up in the air. We had the idea of using gold for featured (scroll up; you can't miss the mockups) but it probably won't work without some new form of featured content.--HereToHelp (talk to me) 21:43, 13 December 2008 (UTC)[reply]
"If the previous design was so good"? Are we thinking of the same main page here? The current one is drab, dull, dated, and completely uninticing to any potential reader/editor. Majorly talk 22:03, 13 December 2008 (UTC)[reply]
We're focused primarily (though not exclusively) on content, not presentation, at the moment. So as far a s drab and dull, the color scheme is not finalized. Dated, meaning that the design is bad merely because it's been in place for a few years? That's hardly actionable; we are avoiding change for the sake of change. How is it unenticing to readers? It may be, but unless you give us specifics, we can't address your concerns.--HereToHelp (talk to me) 00:13, 14 December 2008 (UTC)[reply]
Obviously, those are matters of opinion, Majorly. —David Levy 02:21, 14 December 2008 (UTC)[reply]
[message delayed by site outage]
Regarding the header image, Dudemanfella's desire to add vibrancy will have to take a backseat to usability. During the previous redesign, I was so enthusiastic about including such an image that I created one from a Commons image (and I still see it in use from time to time), but then I observed the effect that it had on some older screens. It was disappointing to give up this element, but it had to be done. This time around, the proposed image is less suitable than the one proposed last time. (It actually makes the text somewhat difficult to read on my fairly new LCD.)
I'd somehow overlooked the inclusion of the time in OTD, which was a bad idea that doesn't appear to have received very much discussion. Upon reading your message, I loaded Main Page at 1:39 (UTC), and the time displayed was 1:29 (UTC). After investigating the history of this change (and seeing that it wasn't widely discussed), I removed the time (while leaving the date intact) at 1:47 (UTC). At that point, the main page's cache still hadn't been purged. After waiting until 1:49 (UTC), I purged it myself. This means that the incorrect time was displayed for twenty minutes (and it might have remained longer if I hadn't intervened).
But why is the time even relevant? It's the difference in date that confuses people, right? —David Levy 02:21, 14 December 2008 (UTC)[reply]
So we can display the date. You mentioned a page purging bot above - how feasible is that? It might help with template switchovers for dynamic content, too. HereToHelp (talk to me) 22:40, 14 December 2008 (UTC)[reply]
My knowledge of bots is limited, but I'm fairly certain that assigning this task to one would be extremely easy. And yes, it would also expedite the dynamic content updates, so I see no reason not to request this now. I'll head over to WP:BOTREQ. —David Levy 22:51, 14 December 2008 (UTC)[reply]
(outdent) There is a reason why the main page keeps a cache, this reduces server load since it does not have to generate a new XHTML document each time the main page is loaded (which is a lot). The change is brief and minor, and thanks for notifying us about that. The Background image should be able to load correctly, we went to a lot of trouble to ensure code works all the way through. If you can produce a repeatable error, we will look into that. Welcome back David Levy. ChyranandChloe (talk) 04:46, 15 December 2008 (UTC)[reply]
Hi! What do you mean when you say that "the Background image should be able to load correctly"? —David Levy 05:49, 15 December 2008 (UTC)[reply]
I think he means that ghosted globe in the header. We can still evaluate it for redundancy and legibility, but I think it's going to display just fine, unless you can post a screenshot otherwise. (I know that might be an abuse of burden of proof but...)--HereToHelp (talk to me) 00:47, 16 December 2008 (UTC)[reply]
I assumed that the reference was to the globe, but I'm not clear on the "should be able to load correctly" part. I have no reason to doubt that the "code works," but the image is unrecognizable on some older displays and makes the accompanying text harder to read (even on my two-year-old LCD). These issues cannot be demonstrated via screen captures. —David Levy 01:05, 16 December 2008 (UTC)[reply]
(outdent) David, I think what you're talking about is "dithering"; when a colour is not support by a monitor the image is dithered, the computer attempts to compensate by interlacing two the closes colours in a short of grid in order to resemble the desired colour. This goes back to "web-safe" colours, which was a serious compatibility issue back in the late nineties. From my understanding your argument is to prevent this from happening by an outright removal of the background image. I'm holding back on a counter-argument until I get a better idea of what the issue is, because I think we can simply recolor the globe to use web safe colours.

David, I know that you are in good faith, but you need to better articulate yourself—if you can't clearly explain issue, it makes it hard for us to understand the solution. And in my opinion, I'm starting to get sick of reading your comments and chipping at a problem you bring forth only to figure out that you meant something entirely different. ChyranandChloe (talk) 04:29, 16 December 2008 (UTC)[reply]

1. No, I don't think that the color has anything to do with the issues to which I'm referring. On some older screens, the image is simply too faint to recognize (the same issue encountered with the book image proposed for the header during the last redesign). On my two-year-old LCD (which certainly doesn't require web-safe colors), the problem is the reduced contrast (which could be addressed by lightening the image, but this would worsen the other problem).
2. Please explain how my comments were inarticulate and misleading. I'll copy and paste them for you:
Needless to say, I wish to convey my thoughts with the utmost clarity, so an explanation of how the above appeared to pertain to the image failing to "load correctly" would be sincerely appreciated. Thanks! —David Levy 04:50, 16 December 2008 (UTC)[reply]
I greatly appreciate that you are interested to present the issue in the utmost clarify. You seem to be able to describe that there is an issue and several attributes pertaining to it, but I can't see what you are seeing. Nevertheless, you actually missed your first comment which stated "[...]And in this particular instance, it duplicates the logo that would appear next to it in the default skin." My assumption was that you guys used either imagemap or actually place the image behind the text rather than embedding it as a background (or you did both and the imagemap got shoved a little to the side and so you saw a duplicate). In the second, you said "it caused problems on some displays", which I assumed you got hoodwinked into buying a very (very) low-grade display (one that does not display "millions of colours" which is bar minimum in today's monitors). Now that you've essentially eliminated the more obvious problems; I am assuming that the issue may lie with the display rather than the code. If you can produce a screen capture or something similar that would greatly benefit our understanding of whether (or how) there is an issue. Also ask Cacyle to join, I think she might be able to understand the issue better than I can. ChyranandChloe (talk) 05:22, 16 December 2008 (UTC)[reply]
1. I didn't "miss" that comment. I omitted it because it has absolutely nothing to do with the problems in question; I was merely commenting that I dislike the idea of displaying the Wikipedia globe logo (the image currently in use as the background image in the draft) directly adjacent to its location (on every page) in the MonoBook skin. I don't know who "you guys" refers to or what situation you're describing.
2. The text "it caused problems on some displays" was part of the preceding sentence (quoted above), not a second comment.
No one was "hoodwinked." I'm referring to older displays that lack the brightness and clarity of new ones (due primarily to wear, I suspect). Unfortunately, many individuals and institutions cannot afford to replace such monitors at this time.
Again, I'm not claiming that there's anything wrong with the code. I'm saying that displaying such a background image is problematic. I can't imagine what sort of screen capture you want me to produce, as the issues that I'm describing are display-dependent. (On a given display, any screen capture would look identical to the actual page.) —David Levy 06:03, 16 December 2008 (UTC)[reply]
Can you take a picture (with a camera) and upload that? HereToHelp (talk to me) 00:23, 17 December 2008 (UTC)[reply]
The idea occurred to me, but I'm fairly certain that the resultant degradation (from photographing a CRT screen) would be worse than the issue that I'm describing. Regardless, I won't be in the vicinity of those screens again anytime soon.
As for my LCD, I just have a bit of difficulty making out the text on top of the background, and Mr.Z-man also commented that the contrast is insufficient (but increasing it would make the background image fainter, thereby worsening the other issue).
The only type of background image that I think could work would be one of the abstract variety. Then we could make it faint without worrying about recognizability. —David Levy 02:23, 17 December 2008 (UTC)[reply]

(outdent) And why would be want an abstract background image? We would effectively create a new piece of Wikipedia's identity arbitrarily. I suppose it could look similar to the Monobook skin, but then it would be repetitive for those using it and out of place for those who don't. If the globe can't work, leave it empty. (I'll look at mockups but I don't think any will be satisfactory.)--HereToHelp (talk to me) 02:59, 17 December 2008 (UTC)[reply]

I agree; an abstract background image wouldn't add much. I thought that the idea of a book image (proposed during the last redesign, as you might recall) was good, but the same problems arose. So yeah, we left the header empty. It was a bit disappointing, but we need to put usability before decoration. —David Levy 03:35, 17 December 2008 (UTC)[reply]
I'm sorry if you found offense, however I think you're coming through. I remember using some displays that have a lower contrast as well, however the significance feels exaggerated. The problematic spot seems to be where the "the free" intersects with the backwards letter N on the globe.

There are actually two options: the first is to lighten the background (brightness in GIMP and Photoshop), which would increase the contrast between the text and image; or the second solution, which is simply to move the background image about 100 pixels to the left: this way the text and the image would not be occupying the same space, and there wouldn't be a contrast issue in the first place.

Usability is place above aesthetics; however, and in my opinion, a solution to the problem should be place above both. Increasing your contrast should not be to difficult, depending on the display. You can usually adjust the contrast by pressing some of the buttons usually found directly below the image. Try that or give us a clear photos and I, or whoever you decide send it to, can walk you through it; that is if you don't want to look it up in the user's manual. Lastly, "you guys" refers to whoever you worked with when you guys figured out that it wouldn't display clearly on certain displays; I understood it as the previous MPRP group back in 2006. ChyranandChloe (talk) 05:11, 17 December 2008 (UTC)[reply]

1. The "backwards letter N" actually is a Cyrillic Й. And you just drew my attention to the fact that the background image was derived from an outdated version of the Wikipedia logo (from before that character was corrected).
2. There's nothing wrong with my display settings. The problem, as you noted, is the image's placement.
3. As I said, lightening the image would improve the contrast, but it also would make the image even less recognizable on some displays. And moving it won't resolve the latter issue.
The third option is to remove the image. As I said, I don't even understand the logic of displaying the Wikipedia logo directly next to itself (in the default skin). The book image that was proposed last time was a much better choice (though it caused the same problems).
4. What does "the previous MPRP group back in 2006" have to do with the logo duplication occurring now? —David Levy 06:00, 17 December 2008 (UTC)[reply]
(outdent)  Done I think moving the image is our best option; however, I do not believe that a having the background be less distinguished on low-contrast display is essential to the point, which is the clarity title. We ran the book a while ago: when the header was first proposed; however the logo seemed to be a be more pleasing, at least in the opinions of those who have supported it. Rather than attempt to characterize the opinions of others you can find the discussion at #Header (it was a comment by HereToHelp, skip down about 3/4s). ChyranandChloe (talk) 04:00, 18 December 2008 (UTC)[reply]
1. It's impossible to optimize the image's position for everyone's settings. Under my configuration, simply increasing the text size to one notch above Firefox's default pushes the text right back over the Й.
2. While not as important as legibility, I don't regard the presence of a nondescript mass of gray (on some displays) as a negligible issue.
3. Can we please discuss the fact that the same logo appears directly next to the position in which the header appears on the actual main page (in the default skin)? —David Levy 04:29, 18 December 2008 (UTC)[reply]
Non-essential to the discussion, and in my opinion, I think we should pause for a breif period of time to allow ourselves to recollect our thoughts and begin a new discussion under a more descriptive header (we need to archive some discussions as well). There are a lot of ways to configure the header, such as adjusting the header so it would not cross into the background image (something we haven't assessed yet), the significance and context of how the background image displays, and the rationale behind having the Wikipedia logo and a similar image in the header. ChyranandChloe (talk) 04:43, 18 December 2008 (UTC)[reply]

So after all this...

[edit]

...The design is almost identical to before. Apart from a few tweaks here and there, it's essentially the same, even down to the last colour. There's also numerous issues with it - David Levy mentions some above. Was it worth all this hassle, months and months of people's efforts, just to get, in the end, the same thing as before? Oh and also, it looks bad on Modern skin. Majorly talk 20:56, 13 December 2008 (UTC)[reply]

Just in case it wasn't made clear, I think this design is worse than before. What a waste of time this was - thank goodness I only got the ball rolling and didn't take part. Majorly talk 21:05, 13 December 2008 (UTC)[reply]
While I agree that the current mockup is worse than the actual main page, I believe that this endeavor finally is on the right track (following a great deal of disorganized effort). Naturally, it will take some additional time for things to come together, just as it did during the previous redesign. But that fact that people have begun collaborating instead of competing brings us much closer to progress than we were before. —David Levy 02:21, 14 December 2008 (UTC)[reply]
(outdent) The proposal has only switched from a proposal candidate based system to a consensus based system for about three weeks. Myself, HeretoHelp, and sereveral others have conceded to go over why the proposal cadidate system (experiment) has failed and what we can do to correct it. However that would be after the current MPRP is complete and we have a suitable proposal to release to the community. I am sure, David Levy, you would have a lot to say, however I implore you to hold off until we're finished with the current MPRP. ChyranandChloe (talk) 04:41, 15 December 2008 (UTC)[reply]

Simple and clear study

[edit]

Being somewhat disappointed with the outcome of the current redesign proposal as well as with the current main page, I have created a design study with the focus on a simple and clear layout, targeted at casual visitors. I have removed quite some information overload as well as many redundancies and visual clutter:

Wikipedia:2008_main_page_redesign_proposal/Cacycle (needs additional css code as described on its talk page for MS-IE or Safari/Chrome browsers for image scaling)

Please see its talk page for additional information. Cacycle (talk) 08:59, 14 December 2008 (UTC)[reply]

I'm unsure of how this "design study" differs from an attempted revival of the ill-fated competition, but I've commented at Wikipedia talk:2008 main page redesign proposal/Cacycle. —David Levy 13:41, 14 December 2008 (UTC)[reply]
Thank you for your design study. However, Cacyle, what do you consider your design study to be? Can you elaborate? You have to remember that we switched from a proposal candidate based system to a consensus based system. ChyranandChloe (talk) 04:50, 15 December 2008 (UTC)[reply]
I see it merely as a design study, not a final proposal. The main point is to demonstrate that the main page actually gets better if we do not try to put as many wikilinks as possible into a limited area. We have to keep in mind that for the vast majority of readers the main page is a portal to start their searches and that adding (too much) encyclopedic content interferes with its main function.
As for the current redesign process: It could be that other proposals did not deviate much from the existing layout in the first place or that the discussion of isolated features out of their design context lead to a convergence at a common and familiar level, so that the final proposal is indistinguishable from the current main page layout and only contains some minor and local improvements. It might have been better to focus the discussion on general design philosophies and to develop several final proposals representing these different approaches. Cacycle (talk) 14:44, 15 December 2008 (UTC)[reply]
"The final proposal"? Huh? What on Earth gave you the idea that we'd even come close to reaching that point?
And no, we had plenty of radically different designs (based on what seemed sensible to the creators) submitted. That strategy failed, so we basically started over. Now you appear to be reviving the old method and labeling it a "design study." And you're actively setting aside consensus that you know exists in favor what you believe is "better." —David Levy 17:15, 15 December 2008 (UTC)[reply]
Please face that the "2008 main page redesign proposal" did not even remotely live up to its name beside a gigantic amount of time and effort invested by so many editors. A great opportunity to improve Wikipedia has been wasted. I am convinced that this was caused by a poor planning and a wrong process from the very beginning. As already written above, the correct strategy would have been to develop and to collaboratively optimize proposals for different design philosophies instead of shredding any innovation by focusing on single elements out of their context. Cacycle (talk) 03:28, 17 December 2008 (UTC)[reply]
(Terribly grumpy, empty belly, cold room, dont mind me. however)
Your design study is terribly cramped at 1024x768, and removes key content that will upset numerous people. See WP:MPALT if you want to design a widescreen/minimal-content variation.
A lot of people proposed a lot of designs (see #Aesthetics above), and if they were a 1st-year-webdesign-college-student selection, some of them might be considered passable.
If you have time to teach a class on webdesign, to everyone who is "interested in redesigning Wikipedia's Main page" then you have more spare time than most of us.
The amateur-design-collective will only get us as far as Portal:Featured portals aesthetics. Partially compose that collective with people with an axe to grind, and numerous other subgroups who come and go, and things go in circles for 5 months.
Grumble -- Quiddity (talk) 04:00, 17 December 2008 (UTC)[reply]

Guys, why do I get the feeling not a lot has changed in the last few months? I actually think the above proposal is very good but I would definately aboid the pale blue background. Keep it white. The Bald One White cat 20:55, 15 December 2008 (UTC)[reply]

The pale blue background is merely a side effect of the "Wikipedia:" namespace (not a part of the proposal). The actual main page will retain its white background. —David Levy 21:38, 15 December 2008 (UTC)[reply]
The Bald One, a lot has happened over the past few months, however the proposal on the project page you've seen has only been around for about three weeks. If you jump to #Aesthetics you'll find a list of proposals, which we ran however due to several shortcomings we'd had to effectively throw away. If you want, you can ask either myself or David why we did it; preferably you can look in archive 2 and 3. ChyranandChloe (talk) 03:56, 16 December 2008 (UTC)[reply]

Moving on

[edit]

This is getting to point where its stagnating in the same circular discussions, every thing on this page has been discussed and argue many times IMHO its time to move forward. I suggest;

  1. that a small working group of editors be given some automony to create two final options,
    1. one reflective of the current format taking into account the discussion that have occured
    2. another without restriction to format, based solely the discussion.
  2. then present them to the community for a discussion over fixed 4-6 week period.
  3. the we can spend 2 weeks documenting process changes required for each design.
  4. send the final designs as formal proposal to whole community.

While the group makes these pages everybody can work on how we identify the final result. Gnangarra 00:02, 1 December 2008 (UTC)[reply]

I don't think discussion has stagnated at all.. if anything it's just begun. We're thoroughly going through each individual section of the main change and discussing why or why not we want to keep it and/or if we'd like to change it. If every single part of the page has tons of discussion behind it, every single part of the page will come together and have reason. Example: We're just beginning to discuss portal links and whether or not to combine them with the "other areas of wikipedia" links or just to throw them out completely. Another area of discussion is about how we want to designate what is what (dynamic vs. static; featured vs. non-featured; etc.) with color schemes, opacity, and/or size. In my opinion, there is still loads to discuss. Hurrying through something makes the final product crappy and thrown together. If we want to change the Main Page of Wikipedia... that everyone sees every day, we need to commit more time to coming up with a rational logical layout for the proposal. Rome wasn't built in a day; chill. --Dudemanfellabra (talk) 00:13, 1 December 2008 (UTC)[reply]
I completely agree. Furthermore, having two versions will likely create unhealthy division and (gasp) polling. Once we have cemented what content we want, then we can progress to designing as a group. Currently, color scheme is on the table because it can be applied to any design and takes its roots in content types. (That, and I have yet to see a formatting presentation that I consider superior to what we have now.)--HereToHelp (talk to me) 01:03, 1 December 2008 (UTC)[reply]
This is not stagnation, very few points have been recirculated and there is plenty of promise in many of the discusions. After the consensus to end exeriment of independently developed proposals and return to the more stable method of consensus based discussion, I feel that the MPRP has just begun. We can address these issues as they come, and I feel that there will be a very likely chance that this proposal may leak into 2009. ChyranandChloe (talk) 04:36, 3 December 2008 (UTC)[reply]

Change

[edit]

I think we should change the banner to this:

Welcome to Wikipedia,

Overview · Editing · Questions · Help

Contents · Categories · Featured content · A–Z index

Hereford 02:25, 2 December 2008 (UTC)[reply]
It's all under discussion: what do we do with the portals, what links to we use in the title, and color scheme. Personnaly I favor white at the top (static content) but you can bring up that point in the appropriate section. Sandboxing is welcome, but the project page associated with this talk page generally will not be updated without a clear consensus. But please, jump right in - the more the merrier.--HereToHelp (talk to me) 03:05, 2 December 2008 (UTC)[reply]

Sorry but I think that looks horrid. But we need to change it thats for sure. Here is a quote I found from a journalist on the web "and so when one goes to it, one kind of goes onto Wikipedia, finds first of all this ugly colour scheme". Count Blofeld 11:38, 2 December 2008 (UTC)[reply]

Link. That's an interesting piece, but the colour scheme is certainly not a main part of the commentary, and merely come across as a personal dislike. Nevertheless, I agree the colours are what I would expect to find on the internet ten years ago. PretzelsTalk! 12:40, 2 December 2008 (UTC)[reply]

Interesting. Well I always use my own main page but I have never been a fan of pastel colours anyway. The front page by default is far too weak as our "cover" undoubtedly, seems most of you agree. I would equally support a redesign in page formatting, an improvement of the wiki logo and the background around articles visually enchanced as much as I would support a main page change. The question is can we make a consensus and will any result actually be implemented? Count Blofeld 13:45, 2 December 2008 (UTC)[reply]

I'm opposed, the sky blue banner is counter to Wikipedia's color scheme and I find it to be distracting (I haven't seem people putting HTML together like that since the ninties—that is a museum piece). Also please move this discussion under the second Changes that can be made or archive it, we need to stay organized on what we are doing. Also Hereford, I apologize that you haven't been here a while, but please read #Previous discussions and links thereof. I don't think it's a good idea to jump on and off a ship while it's sailing, you might get left behind. ChyranandChloe (talk) 04:44, 3 December 2008 (UTC)[reply]
Almost any shade of blue is a lousy background color because it makes the standard link colours hard to read. The current colour scheme has the advantage of being well-known, and I see no benefit in making readers learn a new one. Users want to scan, not read (Jakob Nielsen), and changing any of the "signposts" that they process subconsciously forces them to start reading in order to find the links and other gizmos they want to use (sportspersons will recognise this: it takes a while to adjust to an unfamiliar playing field because the fences and all the other things they see out of the corners of their eyes are in the wrong places, so they have to look for the lines, etc.) Hence I also oppose changing any aspect of the UI unless there are clear benefits for readers. --Philcha (talk) 10:52, 3 December 2008 (UTC)[reply]

The layout is functional, easy and good. But the color scheme is very, very, ugly. We need aesthetics too.  Marlith (Talk)  00:45, 4 December 2008 (UTC)[reply]

I'm glad I'm not the only one who thought this Count Blofeld 12:29, 4 December 2008 (UTC)[reply]

  • The article mentioned above was from April 8, 2006 (from a presentation Jason Scott Sadofsky gave at the hacker convention Notacon) - things have changed a bit since then (amboxes, popularity, cleanup). More importantly, the last Main Page redesign ended in March 2006, and the main page looked like this until March 19 (when it was changed to this). I doubt he wrote his presentation in the intervening two weeks...
  • The box above has poor accessibility and is aesthetically ugly - the color doesn't match anything else in use on Wikipedia, and gives a low contrast with the text (making it hard for some people with vision or screen problems to read).
  • The portals themselves are of debatable utility - they tend to get constructed and then forgotten about. I'd prefer for them to be removed altogether (as mentioned numerous times previously by myself and others). Using something like {{Contents pages (header bar)}} instead, or as a starting point, makes more sense. -- Quiddity (talk) 20:45, 9 December 2008 (UTC)[reply]
[edit]

There appears to be a consensus here. If there is opposition, please state your grievences. ChyranandChloe (talk)

I strongly support this idea. It would allow similar content to be featured together (see the Beethoven mockup), in turn allowing more media to have a chance to be on the MP. Of course, such sets would need to be designed and approved on a case by case basis. Nevertheless, this is an important precedent for Featured lists (below) because many lists are similar or in two parts. That's assuming people like FLs in the first place, but talk about that under the next header please. Having featured collections brings up a point about diversity: should we coordinate between TFA, TFM, and possibly TFL? On one hand, it might be neat to feature a bio of a former US President, a picture of the White House, and List of Presidents of the United States, but except in extenuating circumstances (say, Election Day), I feel that we should strive to have diversity between our featured sections. --HereToHelp (talk to me) 04:49, 28 November 2008 (UTC)[reply]
 Done Ok then. ChyranandChloe (talk) 13:15, 28 November 2008 (UTC)[reply]
Changing the name is the easy part. How do we get the POTD people to use sounds from time to time. That, and just having an image might not best represent the new idea. I could template that Beethoven mockup if you like, but then it wouldn't update daily…--HereToHelp (talk to me) 14:05, 28 November 2008 (UTC)[reply]
I like the idea of being able to have multiple media types featured. However, I see a problem if audio-files start replacing images on certain days, as I think having a featured picture on the Main Page greatly increases its attractiveness. If the picture is complemented by other media types, that's nice, but I don't like it being replaced by them. - Wintran (talk) 14:34, 28 November 2008 (UTC)[reply]
In theory I agree - we could pair an optical illusion with a Shepard tone, animals with their calls, politicians with their speeches - but occasionally you'll get sounds that don't have corresponding images. So while I could go for an encouragement to incorporate sounds into groups, I don't think it should be required.--HereToHelp (talk to me) 14:44, 28 November 2008 (UTC)[reply]
In my opinion, it is not necessary to use audio files instead of pictures and so forth, but simply to provide the option to do so. This give more flexibility to the wikiprojects innvolved. ChyranandChloe (talk) 20:46, 28 November 2008 (UTC)[reply]

I think renaming to Today's Featured Media would be very confusing, to say the least. Regarding the recent change of the Image: namespace to File:, it would be more in line to name it Today's featured file. PretzelsTalk! 21:53, 28 November 2008 (UTC)[reply]

Can you better explain? Because "File" would be technically inclined and would be working against WP:CSB, furthurmore I don't see to justification to promote any file: which can include executables, docuemtns, and so forth. ChyranandChloe (talk) 00:37, 29 November 2008 (UTC)[reply]
It's just that I've not seen our non-article content referred to as "Media" anywhere on WP, but the namespace for that content is called File. PretzelsTalk! 19:37, 29 November 2008 (UTC)[reply]
Media = Images + video + sound. Media ≠ "non article content," which can be lists, portals, categories, talk, administration…--HereToHelp (talk to me) 20:17, 29 November 2008 (UTC)[reply]

Rename: "On this day" to "This day in history"

[edit]

I like "This day in history." "On this day" could confuse some readers into thinking the following content had all happened ON THIS DAY (as in.. this day in 2008). Then they'd start reading it, and be like, "What the heck? Pearl Harbor wasn't attacked this year!" Of course they would figure it out after reading one or two, but what I'm getting at is that if we put the word "history" in the title, the reader's brain is already thinking about history (past years) instead of mistakenly thinking about on this day (this year). --Dudemanfellabra (talk) 18:14, 28 November 2008 (UTC)[reply]

I like your reasoning, as it would make the title more clear. ChyranandChloe (talk) 20:50, 28 November 2008 (UTC)[reply]
Agreed. Should we change that in the draft?--HereToHelp (talk to me)22:58, 28 November 2008 (UTC)[reply]
I just changed it. --Dudemanfellabra (talk) 23:32, 28 November 2008 (UTC)[reply]

Remove the ellipses on the DYK and OTD

[edit]

The ellipses appears to be redundant and unprofessional, and I am proposing to remove them. It does make complete sense with "Did you know... From Wikipedia's newest articles:". ChyranandChloe (talk) 00:13, 28 November 2008 (UTC)[reply]

I've seen "Did you know that…" used elsewhere, but I'm not sure "On this day…" works as well, especially since it's "On this day… 1950 – Something happened." and not "On this day… in 1950, something happened." I could go for the second syntax structure, or for removing the ellipses in favor of "This day in history" or something similar.--HereToHelp (talk to me) 04:49, 28 November 2008 (UTC)[reply]
I'm talking about changing from "Did you know..." to "Did you know". It is not essential to me, but I want to know what you guys think of it. ChyranandChloe (talk) 20:50, 28 November 2008 (UTC)[reply]
 DoneI've removed the ellipses. ChyranandChloe (talk) 21:07, 29 November 2008 (UTC)[reply]

Introducing GA to main page

[edit]

Update: For those who would like to know how it would look like if GA is included on the main page, the first page shows GA on its own while the second page shows GA included alongside with DYK. OhanaUnitedTalk page 01:51, 11 December 2008 (UTC)[reply]

There is a discussion and it has established a consensus where GA should appear on main page provided that there is a process/mechanism that stops GA with below-par quality from appearing on main page. OhanaUnitedTalk page 02:13, 28 November 2008 (UTC)[reply]

I favor introducing it in DYK, which would greatly improve the quality of articles there. I am opposed to one singular GA a day, or highlighting it (them) as merely "Good" and not "Featured". Doing so would steal thunder from Featured, lowering standards. Oust the new articles (occasionally barely more than stubs!) instead.--HereToHelp (talk to me) 04:49, 28 November 2008 (UTC)[reply]
It would be more fair (to Wikipedia authors) and more appreciated (by Wikipedia readers) to introduce a second featured article. - Wintran (talk) 13:35, 28 November 2008 (UTC)[reply]
I'm not sure I follow. Firstly, I don't think it's fair that new (but still cruddy) articles can show up on DYK, but GAs cannot. (I said above that I do not advocate giving FAs the same prestige as Featured articles.) Secondly, people put a lot of work into Featured Lists, shouldn't they get a chance, too? I'm worried about how sustainable two FAs would be. According to the Signpost, we feature just over seven articles a week, while we get about twenty lists a week. If we use 14 FAs a week, we'll eventually run out. The other thing is grouping. Would we have to have two related FAs every day? Or do we risk featuring a politician and an insect on the same day, and what does that imply? (We can have the articles displayed in a random order, though.) --HereToHelp (talk to me) 14:37, 28 November 2008 (UTC)[reply]
Guys, this is the section about the inclusion of GA on main page, not the section to discuss whether 2 FAs are displayed per day. If you wish to discuss having more than 1 FA on main page (and problems for doing so), create a new section. OhanaUnitedTalk page 16:37, 28 November 2008 (UTC)[reply]
I don't think GA belongs in the DYK section. I don't think the DYK process is set up in a manner conducive to including pre-existing content, so the only GAs that would be workable through DYK are likely newly promoted GAs. Which some have stated would be unfair to all the already existing GA articles. I think the best place to incorporate GAs would be under the (one) FA for the day. There could then be a section called "Other articles you may be interested in..." And there would be, say ,5 or 6 articles listed there that would be selected from among GAs and FAs (and I think FLs should be eligible as well). The articles could be selected randomly from among all topics, or (what I think would be best) would be to select one article (or list) from each of several categories (we could use the GAN classification as a starting point) - say one article from science and mathematics, one from social sciences, one from arts, one from everyday life, and one from "other". Rlendog (talk) 17:12, 28 November 2008 (UTC)[reply]
I think GA should be added to the DYK section as well. Instead of updating DYK on the main page every few hours, it should be reduced to once a day with 6-8 good articles. As it has been said before, the main page is for readers... not editors. The theory behind DYK is that a reader will be attracted to the lackluster article and be somehow inspired to turn it into featured material. That, sadly, is not the case. Most of the articles on DYK are mediocre at best, and I believe they turn more people away than they attract. One of the main reasons some professors and high school teachers don't allow their students to use Wikipedia is probably these sub-par articles. Linking to them on the main page for all to see can't help this fact at all. If all the articles in DYK were at least GA material, the section would be much more attractive, and fewer people would be turned away. --Dudemanfellabra (talk) 18:24, 28 November 2008 (UTC)[reply]
Since it's clear that both sides (GA in or not in DYK section) won't come to agreement anytime soon, can we modify the project page to see how it looks under both circumstances? OhanaUnitedTalk page 19:06, 28 November 2008 (UTC)[reply]
I think HereToHelp's underpromoted proposal does something similar to that. If we move the POTD back into its original place, and move the GA below the FA, perhaps we're going somehwere. One thing I'd like to question is whether that is too much featured content; the main page is perhaps the most obvious advertisement in Wikipedia, and overwhelming the reader could cause them to question which to reader first, or whether they want to read at all. User:HereToHelp/Sandbox. ChyranandChloe (talk) 20:58, 28 November 2008 (UTC)[reply]
If we put GAs links next to the FA, they should be related material, but I think links in the text itself do the job better. I would like GAs to be in DYK, but if that doesn't work out, I could see a "Selected Good articles" section (placed below featured content, naturally) with a variety of articles. Would we list them, or provide a short blurb? How much of a blurb, considering we're trying to trim the FA "teaser"? Could it work? Perhaps. But I still think DYK is the ideal solution - we need to get the stubs off our welcome mat.--HereToHelp (talk to me) 22:52, 28 November 2008 (UTC)[reply]
Try add it in and see how it looks like. OhanaUnitedTalk page 23:58, 29 November 2008 (UTC)[reply]


WAIT here guys. WP:GAN already has a massive backlog. I don't suppose that any of you guys will help with that if GA's go to the main page (not trying to be mean, that's serious)! I, for one, would not want to deal with that flood to GAN... —Ed 17 (Talk / Contribs) 15:58, 8 December 2008 (UTC)[reply]

This has already been discussed widely in several other fora. How about a straw poll to see where the consensus lies? The most likely alternatives seem to be:

GA included in DYK

[edit]
  • Support This is my favoured option. It would provide a good venue for highlighting GAs, at the same time as it would raise the average quality of the DYK section. It also seems obvious that this should be reserved for new GAs, as this would encourage GA creation. "Fairness" doesn't enter into it; the main page is there for the reader, not for padding the ego of individual editors. Lampman (talk) 11:39, 3 December 2008 (UTC)[reply]
  • support, on the understanding that it's open to GAs promoted in the last week, irrespective of when the DYK fact was introduced ino tthe artcile and by how much the article has been expanded in the last X days. --Philcha (talk) 12:33, 3 December 2008 (UTC)[reply]
    • Just want some clarification, does that mean the GA must have been a previously-DYK (regardless of when) before it can be shown? OhanaUnitedTalk page 14:20, 3 December 2008 (UTC)[reply]
      • I think what Philcha is saying is that GAs in DYK space shouldn't have to comply with the normal criteria for DYKs (newly created or x5 expanded), they should simply have been recently promoted to GA. With this I would agree. Lampman (talk) 16:17, 3 December 2008 (UTC)[reply]
        • I could see a list of potential problems. Some GAN have been stuck at that stage for ages. By the time it's given the GA status, it is no longer "newly created". Same problem goes to expanding 5 folds, does the expansion has to take place within a few days before listing it on GAN? Qualify as long as expansion took place with no time limit? Or expansion took place during GAN review phrase? There are too many kinks to it that I believe GA should be better off with its own section and doesn't need other departments (such as FA or DYK) to superimpose and enforce their own rules onto GA. OhanaUnitedTalk page 18:20, 3 December 2008 (UTC)[reply]
          • I don't see the problem. The old rules will be disregarded in favor of newly-promoted GAs; when we run out, we move to older ones. I estimate that at the very minimum we need 5 GAs a cycle with 24 hour updates. How many GAs are promoted a week? Hopefully at least 35.--HereToHelp (talk to me) 21:38, 3 December 2008 (UTC)[reply]
            • Right.. We're not saying GAs would have to comply with DYK rules.. They wouldn't have to be massively expanded in the past few days (as nearly zero GAs are).. They would just have to have been recently promoted to GA status. The section could still be titled DYK (unless we want to change it), but it would just have new GAs instead of recently created/expanded/crappy articles. This would mean the end of DYK as we know it.. no more newly expanded stuff on the main page.. just new GAs..
Yes current GAs will miss out on it, but I mean look: When DYK was first instituted, there had already been thousands of articles created and expanded.. they missed out on DYK and weren't featured on the main page. As of now there are already thousands of GAs that will have the same fate. They will miss out on being featured on the main page just like the articles before DYK were first implemented.
In other words, this whole discussion (in my opinion) is about replacing DYK and all of its current rules and regulations with a new DYK which only includes recently promoted Good Articles. --Dudemanfellabra (talk) 21:47, 3 December 2008 (UTC)[reply]
Yeah, I agree with Dudemanfellabra, there is no reason why "newly promoted" should be more of a problem with GAs than "newly created" is with DYKs. Currently, over 200 GAs are created a month, on average, so about 7 a day. The problem is that a lot of these are on hurricanes/roads/TV episodes, so including all of them would seem a little farcical. If we include only one GA per DYK update (4 a day, c. 120 a month) we would be able to present a wide variety of subjects. This would also create less drama with the DYK crowd. Babysteps... Lampman (talk) 00:30, 4 December 2008 (UTC)[reply]
  • Support Will increase quality of DYK without stealing thunder from TFA.--HereToHelp (talk to me) 21:38, 3 December 2008 (UTC)[reply]
  • Support Agree with HereToHelp --Dudemanfellabra (talk) 21:47, 3 December 2008 (UTC) After discussion and enlightenment about the GA process, I remove support. If the GA process was better then maybe.. but until then, it's not happening.--Dudemanfellabra (talk) 04:29, 11 December 2008 (UTC)[reply]
  • Comment My question is how are we to implement this. We aren't the DYK wikiproject, we simply import the content. A consensus here would be fairly meaningless because we can't extend it to the DYK. ChyranandChloe (talk) 04:59, 6 December 2008 (UTC)[reply]
  • Comment, and I'm agreeing with ChyranandChloe. This wouldn't be the place to discuss it, since whether or not GAs are included in DYK would have no effect on a redesign proposal. Introducing GAs to DYK was already proposed at WT:DYK at some point, where I think it failed to get any meaningful support. Spreading the discussion into unrelated places isn't very efficient, so if this is the option you'd like to pick among the ones listed here, please consider discussing it at the dyk talk page instead. - Bobet 13:38, 8 December 2008 (UTC)[reply]
  • Oppose - and not only do I oppose, but I repudiate this attempt to circumvent debate with an ill-considered poll. This needs to be discussed much more thoroughly before leaping into a poll, but I should add that this issue has been discussed several times at DYK already and never reached consensus. New articles and GAs are not a particularly good fit, and if you want to start featuring GAs on the main page as well, I would suggest giving them their own slot. Gatoclass (talk) 16:12, 8 December 2008 (UTC)[reply]
Just to expand a little on my reasons for oppose - it seems to me that GA is not a very rigorous process in any case, it requires just one person to do a review, and many GA articles are actually not very exceptional at all - they are basically just thoroughly wikified articles of average length. We already get lots of submissions to DYK which are probably as good if not better than your average GA, they are by no means all stubby little articles. So if GA's are not actually that special, why feature them? GA subject matter also leans toward popular culture topics which enjoy the support of fanbases, or subjects which have plenty of easily available references, so they don't represent the same broad spread of subject matter that we get on DYK.
I also think having a number of short articles featured on the front page is not necessarily a bad thing, not everybody wants to dive into longer articles, that's what the FA section is for. The shorter DYK articles also in my view act as encouragement to potential new editors - people can look at them and think "hey, I could write an article like that!" It makes wikipedia look less imposing.
Another concern is that we already usually have more than enough articles to choose from. That is not the case at the moment, because the introduction of a bot, an increase in the standard length of a DYK update, and possibly fewer submissions over Christmas, has us currently faced with a temporary shortage of hooks, but this is the first and only time in my experience that this has happened. Usually it's the other way around. My concern is that if we start adding GAs to DYK, more people are going to use GA as a backdoor method of getting their articles on the front page, which has the potential to completely overwhelm the project, especially given the lack of rigour in the GA vetting process. So I currently see few compelling reasons for adding GAs to DYK. Gatoclass (talk) 05:19, 9 December 2008 (UTC)[reply]
  • Oppose - Per Gatoclass. New articles + GA is bad, and there needs to be a hell of a lot more consensus before we dismantle an effective, selective, well-established review process to replace it with something completely different. Shoemaker's Holiday (talk) 16:21, 8 December 2008 (UTC)[reply]
  • Oppose - see Wikipedia talk:Did you know/Archive 33#Radical suggestion, a recent discussion at DYK talk where Lampman brought this same proposal and it was met with almost universal disapproval. Furthermore, in general I am against giving GAs a face to the outside world; as someone else (I don't remember who) has said before me, the GA classification can be confusing to WP outsiders (since the fact that only a small portion of articles are marked as "good" might imply that the rest of the encyclopaedia is trash) and that GAs don't always undergo super-rigorous review (although they sometimes do, depending on the editor; Mattisse and Moni3, for example, are excellent reviewers)—DYK articles don't undergo extended review either, but they don't purport to be as "good" as GAs do. GA should remain a Wikipedia-internal thing. —Politizer talk/contribs 16:57, 8 December 2008 (UTC)[reply]
  • Oppose. New articles and fivefold expanded articles - the current DYK-worthy categories - are similar enough that it makes sense to include them together, but we still get people confused by the inclusion of the latter in DYK. GAs are sufficiently different that putting them in the same box will seem convoluted and messy, and confusing to the majority of our readership who aren't even aware of the existence of such projects as FAC, GAN and DYK. DYK is to showcase new content, not good content; the more people who see fledgling articles in need of non-daunting improvements the more new editors we can attract. Also, I know it's hard to keep track of all the perennial proposals to avoid remaking them, but in this case a post to WT:DYK to gauge interest, let people know and check for previous such suggestions would have been useful. Sorry to sound so critical - good luck with the rest of the proposal. Olaf Davis | Talk 17:01, 8 December 2008 (UTC)[reply]
  • Oppose per my comments in the section above. —Ed 17 (Talk / Contribs) 17:10, 8 December 2008 (UTC)[reply]
  • Oppose Completely contrary to the purpose of DYK. Everything currently on the main page has a distinct and unique purpose apart from the other content on the main page. DYK's purpose is to demonstrate the dynamism of Wikipedia in the constant creation of new content (either by new articles or by significantly expanded one). An article that has been 5x expanded on the way towards GA is fine but adding GAs to DYK, just because they're GA dilutes the purpose and, if anything, adds redundancy to the main page. In the larger scheme of things it is redundant and counter-intuitive to have FAs (representing our "Best") and GA (representing our kinda, sorta not quite "best") on the main page. AgneCheese/Wine 18:18, 8 December 2008 (UTC)[reply]
  • Oppose DYK serves a useful purpose in drawing attention to newly created/expanded articles. By bringing viewers to those articles, it encourages editors to expand the scope of Wikipedia into new areas and subjects. Additional eyes on the new articles also helps them improve more quickly than they otherwise would. Cbl62 (talk) 00:01, 9 December 2008 (UTC)[reply]
  • Oppose DYK is supposed to provide a chance for new articles to be improved. As Lampman says, the main page is there for the reader; we are not going against that. While providing the reader a chance to see an interesting new article (I admit most of them are mediocre, but they are definitely not rubbish) and if you spot a mistake or a problem while you're at it, then correct it or try to improve it if you can. A DYK article is usually read by a few thousand readers, but that doesn't mean everyone goes there to edit it. Those who do will make sure that the article is improved, whether it is by adding a citation or some more info or even a minor rewording. If we get rid of that and put GAs in that place, the main page will become just a showcase. I have nothing against GAs appearing on the main page or their editors getting some recognition for their efforts, but replacing DYK (which serves a completely different purpose) is not the way to go about it. Chamal talk 06:43, 9 December 2008 (UTC)[reply]
  • STRONGLY Oppose DYK is for new articles a/or greatly improved articles. Period.--293.xx.xxx.xx (talk) 09:38, 9 December 2008 (UTC)[reply]
  • Oppose. It reverses the point of DYKs as presentation of recent, fresh effort. GAs, usually, are a product of longer collaboration. NVO (talk) 07:13, 10 December 2008 (UTC)[reply]
  • Oppose Personally, I don't think GAs don't belong in DYKs. DYKs are for new articles or recently improved ones. I think GAs should have a place on the main page, somewhere else. – Alex43223 T | C | E 08:18, 10 December 2008 (UTC)[reply]
  • Oppose - My oppose is not because of any canvassing, as I did not know about it. I oppose for the reasons given above (DYK has a clear purpose in encouraging the creation and expansion of articles, and is open to all editors) and because GA is a positive atmosphere where I feel editors can get useful help with articles free from the pressure cooker of FAC and which now DYK seems to be becoming also, because of the drive for main page exposure. I was surprised to learn that the opportunity for being on the main page was a major reason editors went through FAC. Surely being on the main page is not worth turning GAN into an unpleasant place, which I fear (maybe wrongly) would happen. —Mattisse (Talk) 23:34, 10 December 2008 (UTC)[reply]
  • Comment There has recently been a great inflow of "Oppose" votes here, and it should be pointed out that this has occurred after what was essentially inappropriate canvassing by User:Cirt and User:Chamal N. The action violated both Campaigning (biased tone) and Votestacking (partisan forum) rules. This happened on 8 December, and while opinion went overwhelmingly for "Support" before that date, as can be seen above, it has all been "Oppose" since. Unfortunately this discussion has gotten little attention from the general community, so it is easy for one project to drown out legitimate voices, but that doesn't justify braking the rules. I was hoping for a reasonable discussion here, and I have to say I'm disappointed at this gross violation of Wikipedia guidelines.
In any case, there seems to be an understanding here that including GAs in DYK is somehow an internal decision for the DYK project to make. It seems clear to me that community-wide decisions on changes to the Main Page overrule the individual projects. But let's take an example – here are two possible layouts of seven DYKs and one GA:
  • DYK
  • DYK
  • DYK
  • DYK
  • DYK
  • DYK
  • DYK
  • GA
  • DYK
  • DYK
  • DYK
  • DYK
  • DYK
  • DYK
  • DYK
  • GA
On the left the GA is included in DYK, on the right it has its own section. In both cases DYKs have been reduced from eight to seven, to allow room for the GA. This is within the prerogative of the redesign, surely we all agree that individual projects cannot decide how much space they are allowed on the Main Page? So is the one on the left a matter for the DYK project to decide, while the one on the right is a matter for the redesign proposal? To argue this seems like a meaningless technicality to me. Lampman (talk) 14:40, 10 December 2008 (UTC)[reply]
Huh? There is nothing in the least inappropriate about alerting members of a project whose function is being debated. It's a perfectly reasonable thing to do. As for your claim about DYKers assuming this should be "an internal decision", I've seen no such statement - though I certainly think DYKers are obviously amongst the best informed people to consult when their part of the wiki is under discussion. I really think you are tilting at windmills here. Gatoclass (talk) 15:42, 10 December 2008 (UTC)[reply]
Lampman, thanks for providing the link to those canvassing activity. I knew something was fishy because more interest generated in last 24 hours than for whole 7 days since the straw poll began and Lampman showed the proof. One thing I'm sure is that there is not a single proposal to remove or eliminate DYK, but to add GA to main page by putting it under DYK or to create a section on its own, which I think the canvassers (mistakenly or purposely) misunderstood the proposal and relayed the wrong message to the rest of the crowd. OhanaUnitedTalk page 16:23, 10 December 2008 (UTC)[reply]
Isn't this nice, wikipedia style, - redefining DYK privately and keeping the "DYK mob" in the dark? Why weren't they notified in first place? NVO (talk) 17:25, 10 December 2008 (UTC)[reply]
Well, the main character here is GA yet no one alerted the GA crowd on any of its pages (GA, GAN, GAR) because we want to avoid COI and canvassing. OhanaUnitedTalk page 18:08, 10 December 2008 (UTC)[reply]
  • Comment saying "Heads up-there is a discussion involving the main page going on"--which is essentially what Cirt did on the DYK page is not canvassing in the slightest. Cirt wasn't "canvassing" for anyone to support or oppose anything thing but rather to be aware that the discussion is taking place. If anything, Cirt was correcting gross negligence on the part of the proposers here who did not seek a wide range of input while discussing their idea. Where was the notification at the WP:Village Pump? Or WP:GA? Or what about the other main page features that could potentially be affected like WP:FA, WP:ITN and WP:OTD? For something as radical as what is being proposed, there should have been a more active drive to bring in participants with diverse view points to discuss the matter. A "faux consensus" of a handful of people is not true consensus at all--which is what we had prior to a couple days ago when more view points were brought in. AgneCheese/Wine 18:10, 10 December 2008 (UTC)[reply]
  • Let me reiterate the guidelines: "Votestacking is an attempt to sway consensus by selectively notifying editors who have or are thought to have a predetermined point of view or opinion", which is clearly what Cirt was doing by exclusively alerting DYK participants. "Campaigning is an attempt to sway the person reading the message, through the use of non-neutral tone, wording, or intent." I did not say that Cirt did this, but Chamal N left a message on the DYK talk page saying "Hmm... should we join in the discussion there and present our views? What do you guys think? We might suddenly find out one day that there is no DYK section on the main page anymore :)" which is clearly campaigning. This discussion is linked directly from Wikipedia:Community portal, one of the most visited pages on WP. It's not like anyone is trying to hide it. Lampman (talk) 00:17, 11 December 2008 (UTC)[reply]
That assumes that DYK editors "have a predetermined opinion" regarding this matter. In fact until this poll was begun, I had no idea there was such opposition to GA amongst DYKers - my impression of previous debates at DYK is that it's been a case of "no consensus".
Perhaps you are correct though, that GAers should also have been notified (I note that Agne has already taken that step). However, I think the onus was primarily on you Lampman, the user who started this premature poll, to notify relevant parties, because from my POV it's not very nice to find that changes to a process to which I have devoted a considerable part of my time on Wikipedia are being voted on behind my back. Gatoclass (talk) 05:21, 11 December 2008 (UTC)[reply]
I really don't see that Chamal N's comment is 'campaigning'. He suggested people join the discussion, asked what their opinion on the proposal was, and gave part of his own opinion. None of those seem at all out of order to me: telling people your opinion and reasoning certainly isn't inappropriate campaigning, and nor as far as I can see is suggesting they take place in a discussion they've already heard about.
As for whether it's votestacking - I concede that notifying DYK regulars could be likely to produce a certain opinion (in fact, it did) but not that Cirt did so in order to get that opinion. By analogy, notifying WP:CATHOLIC about a Catholicism-related AfD might have the effect of attracting editors who think such articles are important (and therefore more keep !votes than average), but it's an allowable by-product of notifying editors whose work is closely tied to the article in question. And I certainly believe that DYK-regulars (disclaimer: I am one) ought to be informed about this proposal. As Lampman points out, some of the options here do not directly impinge on the running of DYK, but some of them do and asking for the input of the people who are acquainted with the process therefore seems perfectly natural. Olaf Davis | Talk 17:42, 11 December 2008 (UTC)[reply]
Yes, I have added it to WP:CBB on multiple occasions. I tried for a Signpost press release but it was shot down by this project. So yes, we can bring in the DYK crowd. But did you bother alerting the GA people, too? That would be "Votestacking".--HereToHelp (talk to me) 02:56, 11 December 2008 (UTC)[reply]
Ok, totally agree with Gatoclass, NVO and Olaf above. It is normal for people to notify relevant projects and people when something they are close to or have worked on is being discussed; see WP:FAR for just one. This is not canvassing in the least, and so I request that Lampman strike his slanderous comments above about Cirt and Chamal. Cheers, —Ed 17 (Talk / Contribs) 17:49, 11 December 2008 (UTC)[reply]
Also, HereToHelp, why don't you notify the GA people about this instead of simply whining about it? It is not the job of DYK'ers to notify GA. —Ed 17 (Talk / Contribs) 17:56, 11 December 2008 (UTC)[reply]
What Cirt did was not canvassing, read the guideline where it says: Editors who may wish to draw a wider range of informed, but uninvolved, editors to a discussion, might also place such neutrally-worded notices on the talk pages of a WikiProject... So saying "heads up" without expressing any opinion would be just that. Canvassing is meant to prevent notices to individual editors, not the community. Aboutmovies (talk) 18:18, 11 December 2008 (UTC)[reply]
The ed: Such is the problem of Wiki-apathy… but a valid point. HereToHelp (talk to me) 02:00, 12 December 2008 (UTC)[reply]
All I have to say about this is that I did not have canvassing anywhere in my mind when I made that comment. Anyway, I still fail to see how my comment has violated this policy. It was neutral in my opinion; all I have said is that we have discussed this before and that it looks like we will have to do it again. In reply to Cirt's comment, I have expressed my view that this is against the objectives of DYK, and I have elaborated on this here in my !vote. I don’t think my personal opinion is relevant here; I have expressed that in reply to Cirt's comment and has nothing to do with this canvassing business. It was in a later comment I suggested that maybe the DYK people should express their views on it. I have not asked them to go and type strong oppose here, I have merely suggested that they express their opinions (which may be oppose or support). Also, I have not said that we must do it, or told them "look at my earlier comment, you should !vote based on that".
Of course any Wikipedian is allowed to participate in any discussion regarding any part of Wikipedia, but if anyone directly related to such a discussion is not aware of it, something is wrong somewhere. The DYK project or anyone involved in it were not aware of this discussion, which was why Cirt posted a comment on the DYK talk page about this. Lampman says that this page is linked from a highly visited page, but then how come there were only a very few people involved in the discussion here? Come on guys, you get more !votes than this at an average AFD. If people knew about this wouldn't there be more !votes here, particularly since this is about the redesigning of the main page, the most important page in the entire project? As far as I can tell, I don't think even the people involved with the GA project are aware of this. Shouldn't they, the two projects that are directly affected by the outcome of this discussion, be informed about it and allowed a chance to express their ideas? I think that would be the real community consensus, instead of a few !votes left here by random users who stumble on to this page (not saying anything against that, nor am I calling the !voters here as random wanderers, but again the input from people who are directly related to the discussion is important).
I think my big mistake here was jokingly inserting a sentence saying "We might suddenly find out one day that there is no DYK section on the main page anymore :)". I shouldn't have done that, since Wikipedia seems to be no place for humour. I guess this line could be interpreted as saying that "DYK is going to be changed, I don't like it, so help me to stop it". All I can do about this now is assure you that nothing like this was in my mind at the time, but I don't know if my word will be taken as good enough here right now. Lampman, Ohanaunited or anyone else, please feel free to inform me and correct me if I'm wrong here or you think there's something wrong with the views I have presented here. If the community feels that this was canvassing, then I'm ready to shut up about this and accept any decision taken by it. Chamal talk 14:15, 15 December 2008 (UTC)[reply]
  • Oppose Keep it simple; the Main Page is cluttered and noisy enough as it is, and mixing in GA to the DYK section would confuse and compromise the integrity of the DYK initiative. Skomorokh 01:51, 11 December 2008 (UTC)[reply]
  • Oppose. The goals and objectives of DYK and GA are so vastly different that I doubt a merger and/or joint effort between the two projects could ever work well. Neither party would end up being satisfied and it would most likely lead to a lot of unnecessary wikidrama.Nrswanson (talk) 03:55, 11 December 2008 (UTC)[reply]
  • Support. With hige historical inertia, GA won't get a section of its own, won't be replacing FAs at TFA (I doubt if TFA would even allow other FCs like FLs to replace them seldomly), and won't be at ITN (since most of the boldfaced links are new). So that leaves DYK. I'd like a 6 new/expanded articles per one GA as a good ratio since there are lots of DYK noms and GAs are relatively fewer. –Howard the Duck 05:50, 11 December 2008 (UTC)[reply]
  • Comment - why would we put Wikipedia's 'good' work on the main page when we could just put up two articles of our 'featured' quality? What's the point? —Ed 17 (Talk / Contribs) 17:56, 11 December 2008 (UTC)[reply]

GA included in TFA

[edit]

Both

[edit]

GA section on its own

[edit]
  • Support. Trying to impose the rules from another system (such as FA or DYK) onto GA is destined to face problems and issues. There will be incompatibility issues or upsetting others because they "think" GA drags down the average of the quality of their work. The best way is to make a section on its own and use its own rules to govern it. OhanaUnitedTalk page 20:35, 3 December 2008 (UTC)[reply]
    • I'm afraid that sating "Here is a realy good featured article, and here are some merely Good articles" will degrade the quality of the work. I want the Good-ness to be ancillary. By contrast, GAs are better than most things under DYK. Even putting GAs in a separate section doesn't solve that problem.--HereToHelp (talk to me) 21:40, 3 December 2008 (UTC)[reply]
  • GA and DYK have completely different goals and merging the two would require significant changes to DYK which are not within the scope of main page redesign. - Mgm|(talk) 11:31, 4 December 2008 (UTC)[reply]
    • Perhaps allow new GAs in to DYK while retaining (more selectively) some new and expanded articles, too?--HereToHelp (talk to me) 00:52, 5 December 2008 (UTC)[reply]
      • Then why does GA have to be in DYK? We didn't say you have to choose either DYK or GA but not both. Both systems exist together in harmony is the best approach. We want to be broad and won't restrict future expansion by imposing things like new GAs go under DYK while old GAs go somewhere else. Creating too many sets of rules will be confusing and hard to understand. OhanaUnitedTalk page 04:57, 5 December 2008 (UTC)[reply]
        • I'm amenable to allowing old GAs a chance (though probably only one chance) in DYK. I favor allowing new (and possibly old) GAs in DYK, along with any article that meets the current criteria, with the assumption that with more articles to pool from, we can be more selective. (New articles may still be very weak; GAs may reflect systematic bias, such as a lot of obscure hurricanes but not much art.)--HereToHelp (talk to me) 18:50, 6 December 2008 (UTC)[reply]
  • I would like to see how this would work out in terms of main page balance and the like. I support the principle of the idea, though not there yet on the practical side. Wizardman 16:54, 8 December 2008 (UTC)[reply]
  • Oppose - In general I am against giving GAs a face to the outside world; as someone else (I don't remember who) has said before me, the GA classification can be confusing to WP outsiders (since the fact that only a small portion of articles are marked as "good" might imply that the rest of the encyclopaedia is trash) and that GAs don't always undergo super-rigorous review (although they sometimes do, depending on the editor; Mattisse and Moni3, for example, are excellent reviewers)—DYK articles don't undergo extended review either, but they don't purport to be as "good" as GAs do. GA should remain a Wikipedia-internal thing. Please note that this isn't a matter of me thinking GA is lame and I'm a way better editor than that; personally I have two GAs to my name and no FA, and I still don't want outside recognition for my GAs. —Politizer talk/contribs 16:58, 8 December 2008 (UTC)[reply]
    • Then why are other languages showcase their GAs on main page? Sorry, but your arguments just don't sound because DYK criteria is unknown to WP outsiders as well. It's time to bring GA to par, not finding PR-related reasons to shoot it down. And if you ask an outsider what constitutes an FA, their answer will be "err..." or "don't know". OhanaUnitedTalk page 17:12, 8 December 2008 (UTC)[reply]
      • The fact that other language Wikipedias do it doesn't mean it's best for us (or even for them - we don't have to agree with their decisions). For instance, most languages don't produce enough FAs to have one on the page every day so putting GAs there makes more sense. As for non-editors knowing what's going on: DYK says 'from Wikipedia's newest articles' which is fairly self-explanatory (even if the details of WP:DYK aren't), and the fact that an FA is an in-depth and neat-looking article that can get featured on the main page gives, I feel, even the uninitiated a basic idea of what they are without going into details. If they do want details they can click the little gold star without digging into talk page headers. But if we add GAs to the class of publicly visible article-types then the precise difference between FAs and GAs - and by extension the details of/existence of the FAC/GAN processes - will become relevant to readers confused about the distinction. Olaf Davis | Talk 22:04, 9 December 2008 (UTC)[reply]
  • Conditional support only for recently promoted or recently reviewed articles (recently = say, within one year. Many older FAs would not pass even DYK review today).NVO (talk) 07:11, 10 December 2008 (UTC)[reply]
  • Oppose until plan is rather better set-out. Will this be mere links to a few GAs? Will we set it up like Today's featured article? Will it be quick summaries? Selected facts like DYK? We're essentially voting on a blank proposal here, and should wait until discussion results in some concrete ideas. Shoemaker's Holiday (talk) 18:52, 13 December 2008 (UTC)[reply]

Neither

[edit]

I see nothing about GA that should allow them to be on the main page anymore than an article that has been peer reviewed should be on the main page, when it comes down to it GA is the opinion of only one other editor. DYK is meant for new articles and I don't think they should be included there. Don't get me wrong, that doesn't mean GA isn't useful, I have moved dozens of articles up to that status, I just don't see them as particularly special. --IvoShandor (talk) 13:37, 8 December 2008 (UTC)[reply]

  • Support for the same reasons as given in my comments above—GA should be a WP-internal classification. —Politizer talk/contribs 16:59, 8 December 2008 (UTC)[reply]
  • Support - WP:GAN already has a massive backlog. Without more reviewers, GAN would not be able to handle having more noms. —Ed 17 (Talk / Contribs) 17:12, 8 December 2008 (UTC)[reply]
  • Support for reasons same as above Highfields (talk, contribs, review) 17:18, 8 December 2008 (UTC)[reply]
  • Support per IvoShandor. GA is essentially a more thorough peer review and is levels apart from FAs which undergoes more rigorous scrutiny and are aimed to clearly represent our "Best". If we start featuring GA on the main page then way not "A" Class, which many projects consider above GA? AgneCheese/Wine 18:26, 8 December 2008 (UTC)[reply]
    • Yeah - like in WP:MILHIST, it's almost identical to a FA nom! —Ed 17 (Talk / Contribs) 20:14, 8 December 2008 (UTC)[reply]
      • A-class does not appear on all projects, and each project has its own criteria. This inconsistency makes it hard to compare or judge articles that are both in A-class but belong to different projects. GA, on the other hand, has a consistent criteria (same as FA) throughout all projects. OhanaUnitedTalk page 15:03, 9 December 2008 (UTC)[reply]
        • That still misses IvoShandor's point. There is nothing about GA that is special enough to deserve main page recognition. Unlike FA (and some projects' A-criteria), GA is still just the peer review opinion of one editor. It doesn't matter that it uses a "FA-like criteria"--a GA article still isn't an FA if it hasn't gone through the rigorous FA process. What makes a GA article deserving of special recognition over a Wikiproject (such as WP:MILHIST) adopting the same "FA criteria" and applying it to their A class articles? They're both still not FAs. As I mentioned above, it is somewhat redundant and counter intuitive to feature "our very best" and then make additional room for our "kinda, sorta, not really quite our very best". If a GA author wants main page recognition, why don't they go through the FA process? AgneCheese/Wine 22:28, 9 December 2008 (UTC)[reply]
          • Yet those "kinda, sorta, not really quite our very best" appears on main page as "in the news" and DYK, which are worse than GA. OhanaUnitedTalk page 04:26, 10 December 2008 (UTC)[reply]
            • Ah, but neither ITN nor DYK purport to be our "best content" (which FA does and GA attempts to do in a little brother sort of way) but rather they serve the completely different purpose of highlighting some of the "best traits" of Wikipedia--our dynamism in creating new content (DYK) and stay recent and up to date (ITN). FA, ITN and DYK all serve important and unique roles on the main page--a niche that GA doesn't have. AgneCheese/Wine 04:39, 10 December 2008 (UTC)[reply]
              • Which part of GA says GA articles are the best in Wikipedia? If GA doesn't have a specific niche, then create one! Time to stop discredit GA just to make FA looks more prominent. OhanaUnitedTalk page 04:50, 10 December 2008 (UTC)[reply]
                • Please don't take my words personally. I'm trying to demonstrate what IvoShandor's noted above-that there is "...nothing about GA that should allow them to be on the main page anymore than an article that has been peer reviewed". While FA, ITN and DYK do have distinct and unique purposes to be on the Main Page, GA has none. The folks that should be concerned about creating a "niche" for GA are the ones who want to see it on the main page. Till then, there simply is no rational or encyclopedic purpose for GA to be there. AgneCheese/Wine 05:04, 10 December 2008 (UTC)[reply]
  • Agree. -- Quiddity (talk) 22:04, 9 December 2008 (UTC)[reply]
  • Support per IvoShandor. I was initially for allowing GA onto the main page, but after looking at the GA review process more citically I really don't see what makes GA articles all that unique. If the review process was refined considerably (perhaps a committee of three editors and more specific guidelines for individual topics etc) I would consider changing my vote. At this point the quality of GA articles is inconsistant and a GA rating therefore doesn't mean all that much. I would suggest that the project focus on improving their own review process, re-evaluate all current GA rated articles, and then re-submit a main page proposal once consistancy is established.Nrswanson (talk) 04:08, 11 December 2008 (UTC)[reply]
  • Support. I was originally for it, but after inspection of the GA process, I disagree. I like Nrswanson's idea of reevaluation, etc. Maybe someone should inform them? --Dudemanfellabra (talk) 04:31, 11 December 2008 (UTC)[reply]
  • Support - can't really see the point, GA articles are not that exceptional, if there's an argument for more quality articles on the mainpage I would suggest the introduction of a second FA slot instead. Gatoclass (talk) 05:24, 11 December 2008 (UTC)[reply]
Because they are new or recently expanded, and the community has seen fit to reward new content creators. To bring an article up to GA standard, you don't necessarily have to do much at all, maybe just add a few extra cites and do a bit of wikifying and you're done. Is there any particular reason why that sort of work should be rewarded by a front page spot? Not that I can see. You are rewarded by getting the GA, that seems like a reasonable enough reward already for that sort of work.
And besides, as I've said, GA is not such a rigorous process, we probably have a couple of hundred thousand articles on the Wiki that are already close to or at GA standard, opening up DYK to GA could potentially completely overwhelm DYK when we can barely keep up with the new article submissions as it is. Gatoclass (talk) 11:11, 11 December 2008 (UTC)[reply]
To answer Ohana's question: ITN and DYK both have specific roles which are unrelated to the quality of the article: getting exposure for new / recently expanded / recently newsworthy articles. DYK in particular showcases new work to non-editors and says "look, it's not that hard to write an article and get recognition for it" to people who may have never considered it before. FA and GA, on the other hand, are solely about article quality. Olaf Davis | Talk 17:48, 11 December 2008 (UTC)[reply]
Oh, Agne had said basically the same above. Sorry. Olaf Davis | Talk 17:51, 11 December 2008 (UTC)[reply]
  • Right now, the DYK process means that DYK articles are read and checked by several contributors while for GA's it is likely to be the product of just two people cooperating. I'd be happy to support the idea if there was some community check built it to confirm the article is actually good. - Mgm|(talk) 09:32, 11 December 2008 (UTC)[reply]
    • That's not necessarily true. It's perfectly easy for a DYK to get checked by only one editor, and for that editor to look only at the 'hook fact' which is to appear on the main page without even glancing at other sections of the article. Olaf Davis | Talk 11:20, 13 December 2008 (UTC)[reply]
  • Comment - GA's don't deserve to be on the main page; it's like saying "see this article about ____ that isn't the best we have". At least DYK encourages people to join up so that they can create new articles, and with the disclaimer that they are :from Wikipedia's newest articles" allows them to not be the best in the mind of the reader. If this proposal passes, maybe we should put a disclaimer under the GA section: "This is some of Wikipedia's decent work, but it has only been reviewed by one person and may have not undergone a rigorous review process for this spot - it depends on who reviewed the article." No, just no. If anything, put up two FA's, which would show off our best work and therefore enable us to give out more rewards to editors who manage to get things through FAC. Look at this diff between "my" article's GAN passing and FAC passing, and that's all you should need to see. —Ed 17 (Talk / Contribs) 18:11, 11 December 2008 (UTC)[reply]
    How about selecting for the most unusual or interesting GAs? DYK encourages the production of new articles, but it does nothing to encourage editing the hundreds of thousands of already developed but crap articles. Geometry guy 11:39, 13 December 2008 (UTC)[reply]
  • Support Don't show good articles on the main page. Gary King (talk) 22:09, 11 December 2008 (UTC)[reply]
  • Support Having GAs on the main page simply undermines the whole point of FA. You work towards FA partially because there's the possibility of having it on the main page. Why then go to FA when you can stop at GA. Secondly, what is the caption on the box going to say? "From Wikipedia's second-best articles..." Apterygial 02:44, 13 December 2008 (UTC)[reply]
    "An interesting read..." perhaps? Your other concern may be eased simply by considering the statistics involved, in particular Image:FA-GA-monthly-growth.png. There are approximately 50 new FAs per month, so with only 30.4 TFAs per month, it stands to reason that being an FA is no guarantee of a main page appearance, but you have a pretty good chance if you give Raul a reason. Also not every FA creator pushes for a main page appearance. There are about 200 new GAs a month, and, unlike the FA growth rate (which is fairly static), this figure is rising, approximately linearly. You'd have to put at least 5 GAs per day on the main page to give a GA editor a reasonable shot, and closer to 10 per day in a year or two. That's unrealistic: selection is vital, not only because some GAs lack quality, but also because there are simply too many of them.
    So how to select? I have suggested above the more unusual or interesting ones. For instance, there are loads of GAs on Simpsons episodes: putting them on the main page would be an exercise in futility. On the other hand there are also plenty of more interesting GAs, which we can use to illustrate the broad coverage of Wikipedia, and its variety. Raul doesn't have much choice at TFA. I suggest viewing the large pool of GAs as a resource. Geometry guy 11:39, 13 December 2008 (UTC)[reply]
  • Support I don't see any good way to do this without diluting FA. Shoemaker's Holiday (talk) 18:55, 13 December 2008 (UTC)[reply]
  • Support. Putting GAs on the main page is a solution in search of a problem. As pointed out, we already have more than enough FAs so that we can show a fresh one every day; why dilute the main page with an inferior article? -- John Broughton (♫♫) 21:40, 15 December 2008 (UTC)[reply]
  • Support - I don't see the point and think that the purpose of GA will be harmed by the endless talkpage wrangling by those editors seeking main page exposure, much as FAC is now, and DYK is in the process of being harmed. —Mattisse (Talk) 22:34, 15 December 2008 (UTC)[reply]

What purpose does it serve?

[edit]

In looking at this long conversation about adding GA to the main page in some capacity, I've yet to find a reason why. What purpose will having GA articles featured on the main page serve? How will it benefit our readers or Wikipedia? While we've discussed the purpose and benefits of FA, DYK & ITN, outside of perhaps ego satisifaction for the authors, there hasn't been any distinct purpose given that featuring GA on the main page would do. Doing something just for the sake of doing something isn't worthwhile. Give us something tangible to consider. What niche will GA fill being on the main page that isn't already provided? AgneCheese/Wine 18:33, 11 December 2008 (UTC)[reply]

I agree, good reasons have to be given: "recognising GA" just won't do. One could just as well have a section on "Recently copyedited articles" to recognize and encourage all the work that WP:GOCE does to improve the encyclopedia. Without good reasons, we end up with pointless polls like this where those who are enthusiastic about the GA contribution to the encyclopedia say "Support" and others who aren't don't.
But it doesn't take much imagination to come up with reasons.
At the moment the main page showcases our newest articles and our very best work. That leaves a heck of a lot of stuff inbetween ignored! Article creation is falling as we run out of new topics to write about. Meanwhile, there is a sea of miserable looking articles meaning that once readers leave the main page and actually look something up, they are likely to find dross. Out of over 2 million articles, less than 10000 are good or featured (less than 0.5 percent). Not good for the reader or Wikipedia's reputation...
A quick glance at File:FA-GA-articles-per-million.png shows that FA is going to make little impact on this. For all the encouragement TFA has provided, FA growth is essentially static, and even if article creation falls to nearly nothing in coming years, we're gonna have to wait until the next millennium before we even begin to see an impact.
By contrast GA growth is accelerating because the process scales. The GA threshold is, in my view, a realistic aspiration for the majority of our articles, representing a reasonable hope for what we want the encyclopedia to look like. Shouldn't we be showing that to our readers?
Apart from encouraging editors old and new to bring existing articles up to scratch, there's another obvious role that GA can play on the main page, which I've suggested above. Raul doesn't have a great deal of choice at WP:TFA, because there aren't many more new FAs than there are days to feature them. Consequently the balance reflects the demographics of Wikipedia and the particular strengths of Wikipedia's most energetic contributors. This is sometimes known as systemic bias. We end up with a lot of western celebrities and pop-culture, spiced up with a good dose of military history and a hurricane or three. This again affects Wikipedia's reputation.
In contrast, there are enough GAs to be able to select articles which showcase the breadth and variety of Wikipedia. This involves regarding the GA list as a resource, and selecting from it. I've never been a big proponent of GA on the main page, but I find this reason rather strong. To those who are big proponents I say "Ask not only what the main page can do for GA, but what GA can do for the main page". Geometry guy 12:44, 13 December 2008 (UTC)[reply]
I think it's both. GAs improve the average quality articles on the MP because they are better than most articles there except TFA (which is why I do not support stealing thunder from them). However, the possibility of being featured on the MP can only draw more people to write GAs, which is a worthy goal. Conversely, though some people may take a DYK blurb and expand it. The distinction is that GAs encourage editors who understand that our quality is sporadic and want to improve it; DYK attracts new editors, which is good, but far more often alienates uninvolved readers.--HereToHelp (talk to me) 18:42, 13 December 2008 (UTC)[reply]
I agree with your reasoning, Geometry guy, and I would be on board with letting GA on the main page, if not for the flawed process. When we can allow articles like New York State Route 83, White Lies (band), SM U-21 (Austria-Hungary), and SM U-22 (Austria-Hungary) (all of which are on the list of recently promoted GAs) to be on the main page, something is wrong. In my opinion articles like these should not be listed as Good Articles - I mean the SM U-21 an 22 article text doesn't even go as far down the page as the infobox. These articles are definitely no higher than B status in my opinion.. and the Austria-Hungary articles would be rated a C by me. Articles such as Meridian, MS (biased... I wrote it) that are listed as B-Class are much better than some of these "good" articles (BTW, I could put that up for GAN - and get it - but I refuse to because IMO it's not "good" yet). The GA project needs to beef up its standards before attempting to get onto the main page. Requiring only one editor to review the article is flawed in itself; I could go get one of my editing buddies to go to the GAN page and pass my article no matter how bad it was. There should have to be at least 3 confirms if it is to be accepted. That in itself would decrease the number of new GAs drastically - to a handleable amount at least.
Yes, you mention that the GA people could sort through the new ones to find good ones.... but seems ironic that we have to sort through the so-called "good" articles to find the truly good ones.. in other words, needing to do this requires that some good articles be bad - thus exemplifying what I brought up earlier. If GA reviews their process and only allows the truly "good" articles through, I'll be more willing to put them on the main page. --Dudemanfellabra (talk) 19:07, 13 December 2008 (UTC)[reply]
A fair point. The vast pool of GAs relative to FAs should help us avoid systematic bias, but it should not weed out any sub-par articles. Unfortunately, there's probably too much social inertia behind the one person assessment scheme.--HereToHelp (talk to me) 19:38, 13 December 2008 (UTC)[reply]
For editors who agree with my reasoning, it is remarkable how little you agree with me, or even refer to my reasoning! Was it too long? :-) Who's talking about putting New York State Route 83 et al. on the main page? Not me! You then give an almost diametrically opposite case to mine for putting GAs on the main page ("when the GA process is good enough").
The main point I made is that selection is essential anyway (there are too many GAs and most of them are boring). The consistency of GAs is therefore irrelevant to my reasoning: if you want to discuss the irony of the quality of GAs, try someone else. Instead I'm proposing GA as a hurdle or filter for interesting articles. It is an imperfect filter, but it is much easier to select from a bunch of 5000 articles, almost all of which are pretty decent, than from the 2 million largely unchecked.
The one person assessment scheme is the reason that GA growth is growing linearly, while FA growth is static. You kill that difference, and GA just becomes FA-lite. What's the point of that? "Nearly our best work"? Geometry guy 20:18, 13 December 2008 (UTC)[reply]
PS. If you find any GAs that don't meet the criteria, please have them reassessed. Thanks.


I think it's safe to say that there is consensus about not allowing GA on the main page. Some people may oppose it entirely, and some may want to review the GA process, but the vast majority don't want it on there (at least not now). If there is no objection, I am going to archive this discussion because it's taking up half that page. --Dudemanfellabra (talk) 22:13, 15 December 2008 (UTC)[reply]

Combining Other Languages and Sister Projects

[edit]

The Languages section has been removed, although I do not significantly oppose it, where was the discussion for it? ChyranandChloe (talk) 00:09, 29 November 2008 (UTC)[reply]

In the Previous discussions section, HereToHelp's summary of the archived discussions seems to promote consensus. --Dudemanfellabra (talk) 01:54, 29 November 2008 (UTC)[reply]
Ok, thank's for clarifying. Moving the Other languages wasn't explicity discuss in the previous discussion, I don't think, but I guess it's passed unless someone else opposses it. ChyranandChloe (talk) 02:10, 29 November 2008 (UTC)[reply]
I don't. We don't want to do something one way on the MP and then another everywhere else. That's why I oppose an additional search bar.--HereToHelp (talk to me) 04:58, 29 November 2008 (UTC)[reply]
I think it's perfectly reasonable to treat the Main Page differently from "everywhere else". It's not an article, it's a navigation aid and display board for those articles, and as such performs a completely different purpose. PretzelsTalk! 19:32, 29 November 2008 (UTC)[reply]
The other language Wikipedia's have been established enough to no longer require an section for endorsement on the main page. I think we can simply add a link to the language coordination page in the current titled "Other areas of Wikipedia" would be sufficient. ChyranandChloe (talk) 20:36, 29 November 2008 (UTC)[reply]
I think that they're fairly unobtrusive (unnoticeable?) on the side of the page.--HereToHelp (talk to me) 20:57, 29 November 2008 (UTC)[reply]
(outdent) Can you explain? Because couldn't being less obtrusive be beneficial? ChyranandChloe (talk) 04:24, 3 December 2008 (UTC)[reply]
I've actually had a change of heart. I think we should keep the languages; interlanguage links aren't really publicized anywhere, and I believe the Main Page would be a great place to inform people of them. When I first started editing Wikipedia, I had no idea what that list was, and it took me quite a while (a month maybe?) to figure it out. If on the main page we provide a description of this list, new readers/editors will not encounter the same dilemma. In my proposal, I added the following:

The Wikimedia Foundation is committed to including any and all languages for which there are Wikipedians willing to contribute. There are currently over 250 languages, and users can also request a new language. In the left column of every article (including this page) there is a list of interlanguage links to articles about the same subject in other languages. Some of the largest Wikipedia languages are listed below:

English · Deutsch (German) · Français (French) · Polski (Polish) · 日本語 (Japanese) · Italiano (Italian) · Nederlands (Dutch) · Português (Portugese) · Español (Spanish) · Русский (Russian) · Svenska (Swedish) · 中文 (Chinese) · Bokmål (Norwegian) · Suomi (Finnish) · Català (Catalan) · (See the complete list...)

I edited some of the links to articles I thought better explained the material. Also, I think the word cloud-esque method of displaying the languages works better than the languages section on the current main page. I also combined the "Languages" section with "Sister projects" and renamed the whole thing "Wikimedia Foundation." For a look at the entire proposal, click here. --Dudemanfellabra (talk) 01:52, 4 December 2008 (UTC)[reply]
I don't like the putting it in a box (dynamic vs. static) but I like the idea of combining the two. Sister projects, with icons, is much more prominent. Do we still include the list in the sidebar?--HereToHelp (talk to me) 02:52, 4 December 2008 (UTC)[reply]
Well in the description of the interlanguage links it says "(including this page)", so I planned on keeping the sidebar list so as not to break uniformity with the articles. It doesn't necessarily have to be in a box, but I was going for more of a "Do you like the section title/contents?" type thing. The only thing I could think of to relate sister projects and languages was "Wikimedia Foundation." --Dudemanfellabra (talk) 03:10, 4 December 2008 (UTC)[reply]
I like "Wikimedia Foundation" as a heading. We could use the simple box that the interlangs are in now with a standard ==header== for both pieces.--HereToHelp (talk to me) 00:50, 5 December 2008 (UTC)[reply]
(outdent)  Done I might be getting ahead of myself, but I like the idea as well in combing the two sections. Nevertheless, I'm assuming that we aren't touching the languages in the sidebar, right? To me this isn't very essential and I feel that both methods (with or without the other language section) is acceptable. ChyranandChloe (talk) 04:19, 5 December 2008 (UTC)[reply]
I love the new languages explanatory text, but totally disagree with merging it with sister projects. There's no logical association between other languages of this project and completely different wikis. Besides, the links to other projects should come last seeing as they are the least related to Wikipedia.
On a brighter note, if nobody objects, I'm going to swap out the old sister projects section for this new, cleaner version. PretzelsTalk! 13:13, 5 December 2008 (UTC)[reply]
I like the cleaner (clearer) explanations. Specifically, though, I think "species" is a little ambiguous. Wikispecies is a fairly odd project to begin with; perhaps "species taxonomy" or "species classification"? Wikisource also seems a little vague. "Source texts" or "scholarly text" might work better.--HereToHelp (talk to me) 22:03, 5 December 2008 (UTC)[reply]
I don't like the updated Sister Projects. The table forces a scrollbar on lower resolutions (800x600 specifically) because it is 5 elements wide. I also don't like the bigger, bolder text. Having this section's text larger than all the others would make the section appear to be more important. Maybe we can redo the sister projects section if that's wanted... but this is definitely not the answer. --Dudemanfellabra (talk) 04:01, 6 December 2008 (UTC)[reply]
(outdent) I enjoy the new sister projects, nice job Pretzels. However, Dudemanfellabra has a point on accessibility, but I'm not sure about redoing the entire section. I don't have an opinion over text size. I have to proposals to solve this:
  1. the first is to cut the number of columns from six to four, however in even smaller screens we may get horizontal scroll, and in larger screens we may get unwanted blank space.
  2. the second is a little more complex; after working on the new {{Gallery}} template. I can write the code that would allow the number of columns to be determined by the width of the screen and the width of the elements; there's no Java Script involved and to my knowledge it is compatible on all main-stream web browsers.
Out of bias, I'm leaning towards the second solution, but I'd like a go ahead before I do an implementation, below is some sample code—there's some tweaking left to do, but I think this is a good representation of what I'm talking about. ChyranandChloe (talk) 04:36, 6 December 2008 (UTC)[reply]
Wikipedia Wikipedia
Encyclopedia
Wikinews Wikinews
News
Wiktionary Wiktionary
Dictionary & thesaurus
Wikibooks Wikibooks
Textbooks & manuals
Wikisource Wikisource
Source texts
Wikiquote Wikiquote
Quotations
Wikispecies Wikispecies
Species directory
Commons Commons
Free media
Wikiversity Wikiversity
Learning tools
Meta-Wiki Meta-Wiki
Coordination
Is it possible to have center the last row of content? For example, if three columns are used it forms a row of four, another row of four, and then a row of two aligned to the left. Can we put that in the middle? --HereToHelp (talk to me) 18:55, 6 December 2008 (UTC)[reply]
OK, I've adjusted the table to four columns so it fits on 800x600 better, reduced the text size, and centred the bottom row as requested. I also shifted round the projects slightly so that Commons and Meta can sit together. Pretzels (talk · contribs)
Much better.--HereToHelp (talk to me) 13:11, 7 December 2008 (UTC)[reply]
There's a lot of blank space between the columns and it'll only get worse as screen resolution increases. I've applied the patch detailed above that would allow the number of columns to be determined by the window width and the size of the elements (resize your window and see for yourself). I'm not sure what your opinions are on this, except that you want it to fit on 800x600 windows, and if its against a consensus feel free to revert. ChyranandChloe (talk) 23:52, 7 December 2008 (UTC)[reply]
There are more than fifteen sister projects, we enumerate only ten (linkhere). Perhaps we should apply the update that would enter the rest. ChyranandChloe (talk) 00:00, 8 December 2008 (UTC)[reply]
I think that we have the major ones; many of those unlisted are self-referential and not reader-facing. Personally, I liked Pretzel's implementation because it centered the last row. I don't think whitespace is a problem. --HereToHelp (talk to me) 01:56, 8 December 2008 (UTC)[reply]
I personally liked Pretzels version more than the current one as well; it worked on 800x600, and looked the same for all users. After looking around, though, I like the template at the bottom of this page the most... not sure how much different (if any) it is than Pretzels, but I support adding Pretzels's shorter descriptions to that template and leaving the text size alone as I've mentioned before. I've done this on my design if you want to take a look. --Dudemanfellabra (talk) 03:58, 8 December 2008 (UTC)[reply]
proposing centering the table on the page. --88wolfmaster (talk) 04:03, 8 December 2008 (UTC)[reply]
I figured we had the major ones, but my intent is that at least we went over it. Wikimania, BugZilla, Incubator, Test Wikipedia, and Mediawiki are the ones we do not have. In my opinion is it possible add a link like (more...) to the end to state there are more wikiprojects than the ones enumerated. In organization I like pretzels grayed out reduced-size text, it gives a more professional feel in that we can quickly scan through the titles without being held back the by the descriptions. It's subtle, and a challenge to describe, but my position is with Pretzels. I prefer my design, because when I switch to a 1680 screen (let alone a 1920), the gap between the elements in the sister projects become so great that it looses cohesion, and becomes four separate columns. This is in my opinion of course, and that's my justification for defending it. ChyranandChloe (talk) 04:34, 9 December 2008 (UTC)[reply]
Wow, for some reason, I didn't even recognize the reduced text. I don't really mind reduced text, but the top part ("Wikipedia is part of the non-profit, multilingual, free-content Wikimedia Foundation family.") being bigger than everything else on the page bugs me. I can accept the smaller text (though in my proposal, I used only 90% instead of 75%.. and I also darkened the color to #555 instead of #777 so it contrasts more with the white background. On my Mac, color differences are less apparent than on my PC, and it was semi-hard to see the lighter grey), but the bigger text I won't support. --Dudemanfellabra (talk) 05:18, 9 December 2008 (UTC)[reply]
I don't think the browser resizes the text below 90%, so the it's kind of moot; and with that I can concede with changing it to 90% (75% is really small if it actually displayed. I like the lighter gray better since #777 looks just like everything else. If you're on a mac, that means you have Safari right? Apple's Safari uses web-kit just as Google Chrome. ChyranandChloe (talk) 05:50, 11 December 2008 (UTC)[reply]
I use FF3 on Mac OS X.. I don't like Safari; Firefox is more customizeable. But it may just be my Macbook.. I've always wondered why there's a color difference between it and my PC; I definitely know that 777 was too light though.. maybe 666? (unless your religious :P). Both my PC and my Mac resize text below 90%, though.. increasing from 75 to 90 made a big difference to me.. Mine will resize all the way down to 1% haha (and maybe more, but you couldn't tell if it did).--Dudemanfellabra (talk) 06:16, 11 December 2008 (UTC)[reply]
            • Browsers will render text way below 75%; you can set a limit in your browser preferences but by default this is very small.
            • Windows and Mac do have different gamma settings, but there shouldn't be a hugely noticable difference between greys.
            • The text at the top should be bigger, because it is a header. This is what the whole page should be heading towards: a clearer hierarchy of content. It will look good when the rest of the page is redesigned for the same reason the explanatory text looks so much better small and faded than at standard size.
            • I'd like to restore the rigid five-column layout we started with, which does fit on 800x600 without scrollbars now, because of the reduced text size. PretzelsTalk! 15:47, 11 December 2008 (UTC)[reply]
(outdent) I don't think of that text as a header; the header is "Wikimedia Foundation." That text is simply a sentence. Like I said: I'm fine with making the explanations smaller and other things (such as the Languages), but making certain parts bigger I don't support. I'm fine with keeping the 5-column format as long as it works on 800x600; my design has 4 columns with Meta and Commons centered at the bottom, but either works with me; accessibility is my main concern. --Dudemanfellabra (talk) 20:25, 11 December 2008 (UTC)[reply]
User:This, that and the other mentioned something about this section above. (S)he suggested that we link to WMF in the Langauges section instead of the sister projects section because it comes first (paraphrase). I agree, and I've moved the link to WMF up from the sister projects section to the language section for now, but I disagree with the layout of the current Wikimedia Foundation section. I think Sister projects should go first followed by Languages. It makes a logical flow to first tell the reader what the Wikiedia Foundation is (in this case, non-profit, multilingual, ad free-content) and describe what they do (host other projects) before going in and talking about how they're dedicated to including all these languages. --Dudemanfellabra (talk) 18:41, 13 December 2008 (UTC)[reply]
 Done It's been brought up before and I concede, languages moved. ChyranandChloe (talk) 05:31, 15 December 2008 (UTC)[reply]
It's also been brought up that the dynamic columns are a no-go. IMO, we should switch to either the static 5-column design (as long as it works on 800x600) or the 4 column design with the 2 at the bottom centered. Which one should we go with? Also, no one has responded about the larger text atop the sister projects. I think it should be normal size and left-aligned, though centered may work. Normal size definitely, though. --Dudemanfellabra (talk) 06:16, 15 December 2008 (UTC)[reply]
What's wrong with the 3x3 sister project layout? I haven't seen anyone explain why that should be changed. —David Levy 07:30, 15 December 2008 (UTC)[reply]

I have updated the proposal, taking into account all the discussion above.
1. I've restored the five-column layout for sister projects, with the new smaller and darker text. Overall consensus from HereToHelp, ChyranandChloe, and Dudemenfellabra is that this layout is preferable to both the existing and dynamic format. It does not cause horizontal scrollbars on 800x600, and lists all the public-facing projects - sites such as Incubator, MediaWiki, Bugzilla etc are solely internal projects and not applicable to most visitors.
2. David Levy - it is better than the 3x3 layout for a few reasons. The smaller descriptions give the layout depth and make it more scannable, the "selected" inclusion of Wikipedia itself shows that Wikipedia is part of the set of wikis, and overall it takes up less space on the page. After just a quick check I can see the Wikimedia Foundation and the French Wikipedia already have a similar layout, with even smaller text than we are proposing.
3. I have boldly removed the languages section, after carefully re-reading the discussion above. We had reached consensus that it was not needed, but got distracted trying out Dudemanfellabra's idea of merging languages with sister projects. The languages links are already available in the left sidebar; we are omitting a search bar to avoid duplication, so by the same principle we should not include the list of languages. It's also notable that most other Wikipedias do not include a section on languages.
PretzelsTalk! 20:37, 15 December 2008 (UTC)[reply]

I'm fine with the 5-column thing since it doesn't create scroll bars, but the main reason I support bringing back languages (even though I was previously for taking them out) is that the language section I proposed added explanatory text about interlanguage links, which I don't believe are publicized enough. Heck, it took me several months to figure out what they were when I first came to Wikipedia. The new text also included information about the number of languages hosted by the project (hinting at Wikipedia's breadth) and how to easily request a new language. I believe this explanatory text (more than the languages themselves) should be included because it isn't really publicized anywhere else. Putting these things on the main page will increase the base knowledge of new users and make things easier on them. --Dudemanfellabra (talk) 21:07, 15 December 2008 (UTC)[reply]
Regarding the sister projects section:
  • I agree that the other projects don't belong.
  • I do have a horizontal scrollbar (and a very cramped layout) at 800x600.
  • If deemed desirable, there's no reason why the link/description style can't be applied to the 3x3 layout.
  • To me, the inclusion of "Wikipedia" seems redundant at best and confusing at worst. I don't recall anyone failing to understand that Wikipedia is a part of the Wikimedia Foundation (as clearly conveyed by the heading "Wikipedia's sister projects," which needn't be removed).
Regarding the other languages, I'm okay with the section's removal, but including an "In other languages" link in the Other areas of Wikipedia section makes absolutely no sense to me. That isn't an area of Wikipedia; it's a Meta-Wiki page that links to other Wikipedias. I do, however, think that we need to include that link somewhere, as the one appearing in the sidebar (on the actual main page) is not visible to users without JavaScript enabled. —David Levy 21:38, 15 December 2008 (UTC)[reply]
Dudemanfellabra: I think it's better to leave explanations of Wikimedia policy on languages to somewhere other than our front page, especially since there have been lots of remarks that it is bloated and has too much information. Also, how many users is the "request a new language" link actually going to be relevant to? If they are interested in setting up a new Wikipedia, I think they would be prepared to look a little harder than the front page of English WP.
David Levy: I'm sorry you have scrollbars at 800x600, I did test it and it was not the case on my end. I'm using Firefox 3 on Windows XP. Applying the smaller text to the 3x3 layout would leave acres of blank space. I placed the link in "Other areas" for now, I am aware it doesn't make semantical sense at the moment, but that section is yet to be updated as per #About_Wikipedia.
Wikipedia itself was included on the sister projects to illustrate that Wikipedia is one of many, and put it on the same level as these other projects. It shows the visitor where they are in relation to the Wikimedia "network". PretzelsTalk! 22:00, 15 December 2008 (UTC)[reply]
You have a scrollbar at 800x600? I didn't actually change my resolution, but I have a FF add-on that allows me to resize my window to any resolution desireable, and I didn't get scrollbars at 800x600. Yes the layout was somewhat cramped, but no scrollbars. I'm running FF3 on Mac OS X if it matters; what are you running?
About including "Wikipedia" in the list of Wikimedia projects, I think it should be included because it is a project hosted by the Wikimedia Foundation. If I'm not mistaken, linking to Main Page on the Main Page will cause bolded text with no link, right? Well if the template is implemented, I think "Wikipedia" should be linked to the main page. With it linked, the template can be transcluded on any Wikimedia project, and that project's title will be bolded, but links will be there for all the other projects' main pages. This template is more of a cross-project template in my opinion that can be used in more places than just the Wikipedia Main Page.
About other languages, I don't like the link in the "Other Areas of Wikipedia" section either. I still support bringing back the entire section for the "complete list" link and for the explanatory text I mentioned earlier. I don't think this text bloats the page at all; you can have a lot of information; you just need to present it in an organized, logical manner (which is not currently done on the main page). --Dudemanfellabra (talk) 22:10, 15 December 2008 (UTC)[reply]
I was viewing the page via Google Chrome in Windows XP. —David Levy 22:33, 15 December 2008 (UTC)[reply]
I'm running Windows XP. At 800x600, I see the horizontal scrollbar in Google Chrome. It isn't there when I switch to Firefox 3, Opera 9 or Internet Explorer 6, but the content appears too cramped in any of them.
How about adopting the new link/description style, but not the smaller text size? Come to think of it, we've established consensus against the latter on multiple occasions (due to accessibility concerns).
Are you aware of a widespread misconception that Wikipedia isn't a sister project of those other projects? If not, isn't a faux link a solution in search of a problem? (On top of that, I see potential for it to generate confusion when people see an apparent link to a site that they're currently at and/or attempt to click on it). —David Levy 22:33, 15 December 2008 (UTC)[reply]
Google Chrome takes away some of the window space because it doesn't fully maximize (I've always hated that).. so yea you do get scrollbars there. I suggest we still keep Wikipedia in the list and keep the smaller descriptions, but reduce the column count to 4 and center the remaining two (as seen here [ignore the screwup with POTD.. I'm working on it]). This way, there's less whitespace than the 3 column layout, there aren't any scrollbars at 800x600, and the content is less cramped than with 5 columns.
About the confusion from the link to the site they're currently on, the link wouldn't display. It would just be bold text since they're already there; they couldn't click on it. Kind of like this link: Wikipedia talk:2008 main page redesign proposal. Since you're already on this page, the link appears as bolded text; if the link was on another page, it would appear as a normal link. --Dudemanfellabra (talk) 22:52, 15 December 2008 (UTC)[reply]
(ec)The content spacing can be worked on. I'd appreciate some help in shortening some of the descriptions, and the columns themselves fluctuate in width slightly with the current code.
Accessibility due to the text size is no valid point here; the size is equal to that of the left sidebar navigation, page tabs and user links. In fact, text even smaller than this is already used on the Main Page.
There doesn't need to be an outright problem for something to be improved upon. Besides, as Dudemanfellabra has said, this design could be used on any of the wikis. There's no reason for users to click on Wikipedia; it's clearly formatted differently from the others (eg, not a link) and this technique is already used as standard in navboxes across the site.
The four-column with centred bottom row creates huge whitespace at higher resolutions, mentioned by ChyranandChloe. I'd much rather adjust the five-column to work better on 800x600. PretzelsTalk! 22:55, 15 December 2008 (UTC)[reply]
1. You're referring to the MonoBook skin's interface. Logged-in users can select a different skin (with larger links).
Very little small text is used on the main page, and not for anything important.
2. I agree that something needn't be broken to be improved, but your rationale is based upon a claim that the change will help to convey something that I believe already is clearly conveyed by text that you seek to remove (so I don't see evidence that such an improvement would occur).
It's true that the design could be used on other Wikimedia wikis, but I've long since given up hope of organizing such uniformity. It's a good idea in theory, but it's practically impossible to achieve anything close to consensus across the various projects.
You note that similar formatting is used throughout the site, but we're discussing the page most likely to be viewed by first-time visitors (lacking familiarity with those templates). —David Levy 23:17, 15 December 2008 (UTC)[reply]
I'm not fond of the 4+4+2 layout, which looks unbalanced and doesn't save any space.
I realize that the Wikipedia mention wouldn't be linked, and that's what I'm saying might confuse people. (They'll try to click on it, and nothing will happen.) —David Levy 23:17, 15 December 2008 (UTC)[reply]

(outdent) I oppose "linking" to Wikipedia, this is other sister projects. I also favor a centered layout for the sister projects.--HereToHelp (talk to me) 01:48, 16 December 2008 (UTC)[reply]

It is no longer "other" sister projects; it shows the whole family of wikis in context. Without including Wikipedia it does not show how the site you are on ties in, and looks just a bunch of external links. PretzelsTalk! 04:01, 16 December 2008 (UTC)[reply]
I've always thought that the heading "Wikipedia's sister projects" (which you seek to remove) and text "Wikipedia is hosted by the Wikimedia Foundation, a non-profit organization that also hosts a range of other projects:" (which you seek to change) conveyed the concept rather well. Do you have evidence to the contrary? —David Levy 04:17, 16 December 2008 (UTC)[reply]
I actually liked having Wikipedia listed among the sister projects since it gave the list context to what the sister projects where used for. My greatest concern is the move away from the more flexible listing technique, the dynamic columns. Is it because you guys don't understand how it works, or is there another reason? This method is perhaps the most flexible: displaying as reliably at all resolutions small or large; and the only argument that I've read so far is that you don't like it being right-aligned. I don't like elevating the issue, but this issue lacks enough discussion for consensus to change so readily. I don't have an opinion over changing the heading yet. ChyranandChloe (talk) 04:46, 16 December 2008 (UTC)[reply]
I understand how it works. I also understand that it looks terrible (IMHO). No offense, but I'll take cramped content over lopsided content any day. —David Levy 05:19, 16 December 2008 (UTC)[reply]
(outdent) You know you can just ask me to fix that, and I can have a solution which accomplishes all of the above by the end of the week. The proof of concept is to divide the the list straight down the middle; the next step is to float the left column right and the right column left: therefore it would be centered, and "dynamic". I don't think this is the entirely criteria though, so I think it is essential to wait for us to form at least some kind of consensus of what we want. When we're finished with this discussion I have a technical issue I want to go through; that is switching from tables to pure CSS, which would give us a lot more flexibility with the new POTD template. ChyranandChloe (talk) 05:31, 16 December 2008 (UTC)[reply]
You can't float something against something else that's already floated. If you floated the left column right, it would be on the far right side of the page.. not against the right column. Floats don't stop each other if they're not in the same direction. What you propose above would display one column on the far right of the screen and one on the far left - not two centered ones. I like the static display better than dynamic - not because of centered this and left-aligned that, but because everyone won't see the same thing. The main page should appear the same to everyone; if there's ever a question about this section between two users seeing different things, confusion is bound to erupt. Keeping the static design causes all users to see the same thing, eliminating that chance for confusion. —Preceding unsigned comment added by Dudemanfellabra (talkcontribs) 05:53, 16 December 2008 (UTC)[reply]
Agreed. Additionally, if I understand correctly, ChyranandChloe is proposing a layout (when triggered) of two four-link rows followed by one centered two-link row. (ChyranandChloe, please correct me if I'm mistaken.) As stated above, I'm not fond of the 4+4+2 layout, which looks unbalanced and doesn't save any space. Irrespective of the number of rows/columns, they should be uniform. —David Levy 06:03, 16 December 2008 (UTC)[reply]
Floating half the projects left and half the projects right would, unfortunately, leave a huge gap down the middle on higher resolutions. The current layout can be achieved through pure CSS, I just coded it as tables for now to make it easier for others to edit/sandbox. PretzelsTalk! 06:27, 16 December 2008 (UTC)[reply]
Ok, how about the design now? I've moved out Meta-wiki to the descriptive text because it serves as more of a coordinator for all other projects than as a project itself. The layout is 9x9 like the old one, keeps "Wikipedia" in, and shortens, shrinks, and greys descriptions - a combination of all proposals. Thoughts? --Dudemanfellabra (talk) 06:56, 16 December 2008 (UTC)[reply]
I admire your effort... but there is huge whitespace even on 1024x768, and this layout doesn't offer the same space-saving as the current one. PretzelsTalk! 07:08, 16 December 2008 (UTC)[reply]
(outdent) I'm not floating something against something that's already floated, the first part of my statement was "to divide the the list straight down the middle"; this prevents the above from happening. The statement "everyone won't see the same thing", I believe is lacks a sustainable argument: the page won't look the same for everybody anyway, for example a person on 1024 would have tighter columns than a person on 1280; and confusion over the number of rows and columns between two users seems to be a stretch of imagination. There isn't a gap as for told, which motivates me to question the constructiveness of cynicism of a concept that hasn't even fully emerged yet.

David Levy is correct, however if I reduce the width of the column I can actually get a 6 by 4 (not an serious improvement but is displayed below). The greatest issue is the fact that there are ten elements, which only has two factors: two and five. However, one thing I would like to explore is that we do not have the full list of sister projects. There are five that are omitted in this list (Wikimania, BugZilla, Incubator, Test Wikipedia, and Wikimedia founation).[1] The previous discussion branded them as "not reader-facing", however I would reopen issue in that this would be a disservice to unlist Wikimania and Wikimedia Foundation (the remainder are all back-end focused). Serendipitously, this increases the number to twelve which can factor into: two, six, three, and four—and thus significantly increasing the flexibility (uniformity if we choose factors four and six).

There are two issue I believe I'm sponsoring: the first is increasing the sister project list, and the second is the potential use of the more flexible listing technique. ChyranandChloe (talk) 04:46, 17 December 2008 (UTC)[reply]

Wikinews Wikinews
News
Wiktionary Wiktionary
Dictionary & thesaurus
Wikipedia Wikipedia
Encyclopedia
Wikibooks Wikibooks
Textbooks & manuals
Wikisource Wikisource
Source texts
Wikiquote Wikiquote
Quotations
Wikispecies Wikispecies
Species directory
Commons Commons
Free media
Wikiversity Wikiversity
Learning tools
Meta-Wiki Meta-Wiki
Coordination

It would be confusing at best to include Wikimedia Foundation itself as a sister project. As for Wikimania, it's only truly relevant for the short time that people are booking and it is happening - and it's promoted in the Sitenotice anyhow. PretzelsTalk! 11:29, 17 December 2008 (UTC)[reply]

Agreed on both counts. And of course, the Wikimedia Foundation is linked via an icon appearing at the bottom of every page. —David Levy 12:00, 17 December 2008 (UTC)[reply]
Meta-Wiki is also editor-facing; it doesn't have any content of its own about the outside world. When it's relevant, we can link to specific pages. That leaves a nice 3x3 grid, or ax Wikipedia as redundant and we get 4x2 (or 2x4 - I can never remember which value goes first). HereToHelp (talk to me) 22:10, 17 December 2008 (UTC)[reply]
Of the options presented thus far, my favorite is the status quo. My second favorite is your suggestion to eliminate the Meta-Wiki link in favor of the Wikipedia placeholder (if there's consensus for the latter's inclusion, which seems redundant to me). Either way, let's stick with the 3x3 grid. I've seen nothing else that works as well. —David Levy 22:26, 17 December 2008 (UTC)[reply]
I like the 3x3 grid as well. I dislike having Meta-Wiki in the template because, like you said, it's editor facing. Also, it isn't really a project.. but more of a coordinator of all the other projects. Removing it and replacing it with Wikipedia to keep the 3x3 grid sounds most logical to me. --Dudemanfellabra (talk) 22:46, 17 December 2008 (UTC)[reply]
I'd be okay with that, with the understanding that if we ever need to add a new project, we'll remove Wikipedia instead of switching to a ten-item grid. —David Levy 02:50, 18 December 2008 (UTC)[reply]
(outdent) I'm fine with that. I'm more willing to take out Wikipedia upon creation of a new project (and changing the name back to other projects) than I am to keep Meta-Wiki in at the current date. It appears to me that Meta-Wiki was just thrown in there to complete the 3x3 grid and doesn't really belong in the first place. Removing "other" from the title solves this dilemma. If no one objects, I'll replace the template on the proposal page. --Dudemanfellabra (talk) 03:25, 18 December 2008 (UTC)[reply]
 Done We're going back to the 3x3 grid by removal of Media-Wiki; and as conceded above we'd simply remove "Wikipedia" in the case that we want a new Sister project. The second part of the package, which I believe is more controversial, is that I ridgidified the columns: this prevents the columns from creating too much whitespace between themselves. To disable this just add "width:100%;" to the styles= element. ChyranandChloe (talk) 04:19, 18 December 2008 (UTC)[reply]
I don't like your link to other languages, David. If we're going to put one there, why not on all the other projects? They have other language versions too. Take out that link and bring back languages section with explanatory text. —Preceding unsigned comment added by Dudemanfellabra (talkcontribs) 06:04, 18 December 2008 (UTC)[reply]
Umm...can we please wait for some additional feedback? I don't object to the idea of restoring the Wikipedia languages section, but I'm trying out something different. (You haven't seen me rush to remove other people's changes from the draft, have you?)
To answer your question, there are no "other languages" links for the sister projects for the same reason why there are none on the actual main page: such links fall outside the information likely to be sought there. (The English Wikipedia's main page logically leads to other English-language projects and other Wikipedias.) Including such a link here gives the "Wikipedia" listing an actual navigational purpose. —David Levy 06:43, 18 December 2008 (UTC)[reply]
I like the 3x3 grid, but not the interlanguage link. I also dislike linking to the non-profit organization article. (Don't replace it with a donate button, either!) HereToHelp (talk to me) 01:03, 19 December 2008 (UTC)[reply]
(outdent) I wasn't saying that I was going to remove it; I was simply stating my opinion. I think the link needs to be removed, and the language section be brought back in. (I also keep forgetting to sign my comments haha) To create better flow and better tie together projects with languages, I propose the text before the language list to be:

Each project is available in many languages, and users can also request new ones. Wikipedia is currently available in over 250 languages and is committed to including any other languages for which there are editors willing to contribute. In the left column of every article (including this page) there is a list of interlanguage links to articles about the same subject in other languages. Some of the largest Wikipedia languages are listed below:

...followed by the list. This makes the transition from naming WM projects to talking about WP languages much smoother IMO. --Dudemanfellabra (talk) 01:36, 19 December 2008 (UTC)[reply]
Looks like it's worth a try.--HereToHelp (talk to me) 01:45, 19 December 2008 (UTC)[reply]
I don't mind being told that you dislike my idea, but your last sentence would have been considerably more polite if you'd appended "We should" to the beginning. —David Levy 01:52, 19 December 2008 (UTC)[reply]
To whom exactly are you referring? ("We should this makes...", "We should looks like...", huh?)--HereToHelp (talk to me) 02:10, 19 December 2008 (UTC)[reply]
Both my edit summary and my indentation indicated that I was replying to Dudemanfellabra, but I should have specified that I was referring to Dudemanfellabra's previous message (which ended with the sentence "Take out that link and bring back languages section with explanatory text."). —David Levy 02:17, 19 December 2008 (UTC)[reply]
(outdent) Within the context of "Sister projects" I think the "other languages" is an innovative position. "Other areas of Wikipedia" makes it almost feel that the other languages are subordinates, it would also burry in the links in "Other areas...". I disagree with is that the section is no longer centered, and you [David] have yet to document the reasons for this (see the notice). Therefore I've restored to Dudemanfellabra and revised to add the "other languages" link (I think we should revise to where the link goes as well). As the for the header "Wikimedia foundation", I think it's too larger and imposing: it breaks the flow. If we can reduce this attribute, I think there should be no reason why we can't have this. ChyranandChloe (talk) 04:24, 19 December 2008 (UTC)[reply]
Idk about you, but I like David's design better than what you reverted it to.. the only thing I didn't like about it was the link to other languages. No one said anything about the header except you (I thought it looked much better). I see no grounds in the above discussion for the revert you just performed. --Dudemanfellabra (talk) 04:32, 19 December 2008 (UTC)[reply]
The grounds are documentation, it would be easier to accept if David stated what he did and why. ChyranandChloe (talk) 04:38, 19 December 2008 (UTC)[reply]
My understanding was that we'd agreed to return to the style of layout currently in use, so I carefully integrated the other changes into that code. The code to which you just reverted was never intended to be used for a 3x3 grid (and therefore contains far too much white space). —David Levy 04:44, 19 December 2008 (UTC)[reply]
(edit conflict) I think the level 2 header breaks the flow, if we chose a less intrusive one I would gladly accept it. I also don't know what you guys think about centering the sections since you guys have remained largely silent. I also don't know what you guys think about switching from images to imagemap which allows the icons to link to the project (this was in David's package). I also don't know what you guys think about the left-aligning the description and increasing the font-size (referring to David's package). I know it's hard to document what you've did, because we usually package a few things into one edit; but that doesn't mean we should be getting laid back. ChyranandChloe (talk) 04:48, 19 December 2008 (UTC)[reply]
No, it makes much more sense to unilaterally revert edits on a technicality, even when the person who performed them has patiently discussed (and left in place) various changes with which he disagrees. After all, you're the boss. —David Levy 04:55, 19 December 2008 (UTC)[reply]
(outdent) There is an increase of white space on either side of the sister projects, the other solution is an increase of white space between the columns. This was, in my opinion, when I first proposed and implemented, that the white space between the columns where more damaging to cohesion than white space on either side. It is possible to tweak the values to achieve what you consider to best. I don't mean to be imposing, I think this concludes what I have to say. ChyranandChloe (talk) 04:56, 19 December 2008 (UTC)[reply]
Please point me to where it was decided that there is a reason (other than the idea of switching to a numerically different layout, which we've moved past) to replace the longstanding code currently used on the main page (which you've deemed "David's package") and reduce the text size. And since you're demanding discussion/documentation for the continued use of imagemaps and hand-optimized icons, please point me to the discussion in which those were deemed undesirable. Don't forget to dot every "i" and cross every "t," unless the rules only apply to everyone else. —David Levy 05:06, 19 December 2008 (UTC)[reply]
Ha wow guys.. so umm.. I'm gonna go do some reverting. I'm taking it back to David's layout (minus the other languages link), and adding in the new languages text.... just in case there isn't enough controversy. --Dudemanfellabra (talk) 05:37, 19 December 2008 (UTC)[reply]
I tweaked the wording and removed the highly truncated list of Wikipedias. If we aren't going to continue duplicating all of the interwiki links (which I'm okay with), we're better off pointing readers to the actual list instead of distracting them with a small sample. —David Levy 06:08, 19 December 2008 (UTC)[reply]
I strongly support reflecting established conventions on the Main Page, so pointing users to the interlang list in the sidebar is a good thing. I've removed the sentence that indicates that an abbreviated list follows when it no longer does. I also revised the sentence before that. The new version sounds good to my ear, but perhaps we should use simpler language when addressing non-native speakers? Anyway, I also support standard (==) headers. I support the 3x3 grid (and yes, Wikipedia is first out if a new project emerges, which is unlikely). Left-justified text works despite the center-ish grid of sister projects. I strongly favor linking the icons to the projects. (Keeping the user out of "backstage" overrules preserving normal functionality.) Like David, the new position of the background image looks fine in default but interferes with higher typeface sizes, thus ironically obscuring the text on the screens of vision-impaired readers. So the globe is still a mess, and I still dislike Dudemanfella's link choice for "anyone can edit" (and, less so, categories). Still, this footer formatting looks good, although I thing most or all of the community links are extraneous. So does that let you know, ChryandChloe, how I "feel"?--HereToHelp (talk to me) 23:10, 19 December 2008 (UTC)[reply]
FYI, "You are viewing our main page, on which we list the largest Wikipedias." referred not to "an abbreviated list [that] follows," but to the standard interwiki links described in the preceding sentence. I don't think that the sentence is crucial, however, and I like your rewording. —David Levy 23:19, 19 December 2008 (UTC)[reply]
Fair enough. And yes, the MP is a page, not an article, and contains one singular list. Thanks for catching that.--HereToHelp (talk to me) 23:42, 19 December 2008 (UTC)[reply]
(outdent) I think we should center the sister project icons; I do not oppose the current method of handling other languages, but I believe in saying more with less, from which I prefer the method David proposed earlier of placing "other languages" next to Wikipedia. The description at the bottom feels somewhat heavy, but I think we can asses that later on when we begin discussing distinguishing static and dynamic content.

David, with the statement of dotting the i and crossing the t, I believe you are taking my position to the extreme. In context, there was absolutely no comment or discussion between when I centered the sister projects and returned to the 3x3 layout and when your edit was made. The central point is: please do not believe your edits are self-evident, especially when it alters the appearance of the draft. All I'm asking is an acknowledgment and brief reason why, all of us have done so in one method or another (and if you want me to clarify let's move this to our talk pages). I had no intent of causing you grief or contempt when I made the revert, however I am currently (greatly) disappoint at your reaction. ChyranandChloe (talk) 01:03, 20 December 2008 (UTC)[reply]

Oh, so there was discussion behind the switch away from project-linking, custom-tweaked icons? By all means, please point me to that. —David Levy 01:12, 20 December 2008 (UTC)[reply]
I think this discussion is growing rather large, and I'd prefer to have discussion essential to improving the subject (that is the Sister projects) rather than for dispute and clarification. Let's move it to your talk page. ChyranandChloe (talk) 01:19, 20 December 2008 (UTC)[reply]
Oh yes, let's throw transparency out the window, shall we? How about we archive what isn't active (≈80% of the page)os the real discussion can be better organized. And no, I don't think there was any discussion "behind the switch away from project-linking, custom-tweaked icons". CaC mentioned it, so I replied that its a bad idea. HereToHelp (talk to me) 01:53, 20 December 2008 (UTC)[reply]
(outdent) Our discussion is non-essential to the improvement of the MPRP. And archiving would be helpful. Also I don't understand what you mean by switch away from project-linking. I can't read your mind HereToHelp, please assume good faith. ChyranandChloe (talk) 02:24, 20 December 2008 (UTC)[reply]
Not "project-linking." "Project-linking, custom-tweaked icons" (one phrase). Meaning icons that are custom-tweaked and link to projects.
Is English your native language? (That's a serious inquiry, not an insult.) —David Levy 04:02, 20 December 2008 (UTC)[reply]
"Project-linking, custom-tweaked icons" = Icons that, when you click them, take you to the sister project and not the image description page, like most images. Just so we're clear.--HereToHelp (talk to me) 04:22, 20 December 2008 (UTC)[reply]
I support the images linking to the projects, not the images themselves. I think in the midst of editing, we took out the imagemaps (probably to make the code easier to read), but we (I, at least) had every intention of adding the imagemaps back after deciding on layout. About the language text, I like removing the language list, but I'm not really satisfied with the rewording. For one, the "committed" link goes to an article talking about Wikipedia's commitment to including other languages, not the Wikimedia Foundation. I looked for an equivalent article on the WMF site, but I couldn't find an article of equal or higher quality than the one linked now. I therefore think that "..., and the Wikimedia Foundation is committed..." should be changed back to "...and is committed..." Also, I don't like that we've removed Meta entirely; it's still worth mentioning, so I've included it as a link in the intro text. I also elaborated a little more on the interlanguage links, adding in that users can request a translation or translate it themselves (subtle editing reference). See the proposal for changes. --Dudemanfellabra (talk) 05:32, 20 December 2008 (UTC)[reply]
1. "Request additional ones" (with "ones" referring to languages) is too informal and unclear to non-native Engish readers.
2. As I previously noted in my edit summary, the claim that we are "committed to including any other languages for which there are editors willing to contribute" is inaccurate, as other criteria are considered. This is why the Klingon and Siberian Wikipedias were closed and why requests for Wikipedias in other languages (such as Pig Latin) have been denied.
3. There is no multilingual body known as "Wikipedia," with or without the authority to create Wikipedia sites. The page in question refers to "the Wikipedia community," which links to Wikipedia:Wikipedians.
4. This seems moot, however, as the page appears to be terribly outdated and virtually abandoned. Until it's revived as an active resource, I see no reason to link to it at all, let alone twice.
5. The wording "To view a Wikipedia article in another language..." is problematic for two reasons. Firstly, it needlessly excludes other types of pages. Secondly (and more importantly), it accidentally implies that the articles in question are direct translations of each other (a misunderstanding that we've gone out of our way to dispel). —David Levy 06:24, 20 December 2008 (UTC)[reply]
1. I see your point; agreed.
2. I was simply transferring information from the linked article. I know Wikipedia won't add any language, but for the most part, if you can get 5-10 people willing to edit, you can start your own.
3. I see your point, and I agree with the change from "Wikipedia exists in..." to "Wikipedias exist in..."
4. I agree that the article seems abandoned (I didn't realize that before), but I see this as no reason not to link it. If it's linked from the main page, it will surely be revived. I think multilingual coordination is an important part of Wikipedia (it shows a slight sense of humility, suggesting that English isn't the center of the universe); it should be revived, and I believe that by linking to it, it will be. Yes, for the first few days/weeks, the page may be outdated, but I think people will own up and revamp the page (I'm willing to help out if anyone wants to join me). Updating the page would also allow for a different wording for #2.
5. I agree that it excludes other types of pages, but the main page is focused towards readers (that may possibly in the future become editors), and readers 99.9% of the time go to articles - not templates or portals or anything else that may have interlanguage links. Those types of pages are editor-focused. Yes, you can view those types of material in other languages, but more likely than not readers will want articles in other languages; not the other stuff. About implying articles are direct translations, how about "To view an article in another language about the same subject as an English Wikipedia article,..."
I also think that there needs to be a page about how to translate articles that can be linked by "translate it yourself." Kind of like the UTC thing I mentioned in the header discussion about why Wikipedia uses UTC instead of local time. These two articles would be great additions to Wikipedia, and, like the mutilingual coordination page, I'm willing to help create these articles if anyone would like to join me. --Dudemanfellabra (talk) 07:17, 20 December 2008 (UTC)[reply]
  • Wikipedia:Multilingual coordination has been linked from the main page nearly nonstop since 2 November 2002 and from the languages section since its introduction on 23 February 2004. I removed the link this morning (upon noticing that the page had become inactive).
  • We link directly to numerous non-article pages (some of which are geared toward readers) from the main page, so we're actively encouraging people to visit them (and we certainly want users to find the corresponding pages in their primary languages). On top of that, we want them to notice the interwiki list on the main page itself (which isn't an article, despite its presence in the article namespace).
    It's common for even experienced users to erroneously refer to such pages as "articles" (as you did several times above), and we don't want to encourage this (no offense intended, by the way). —David Levy 14:08, 20 December 2008 (UTC)[reply]

Sister projects: arbitrary edit point

[edit]

(outdent) I think that the group of Wikipedias has expanded and matured to the point that very few, if any, holes remain. Certainly we will create more and we should have that option available at multilingual coordination (The Local Embassy seems active). Still, I think that creating new Wikipedias from scratch is too ancillary to warrant placement on the MP. I'm going to go ahead and remove it, and see what I can do to dispel implications of direct translation.--HereToHelp (talk to me) 13:07, 20 December 2008 (UTC)[reply]

David: the only thing I don't like about your most recent revision is linking to English language. Is there a better link we can put in there, or leave it blank? (I don't have any ideas, sorry.) HereToHelp (talk to me) 20:01, 20 December 2008 (UTC)[reply]
What's wrong with that link? We've included it since the last main page redesign in 2006. It prevents ambiguity. (The term "English" also refers to people and things of England.) —David Levy 22:06, 20 December 2008 (UTC)[reply]
English is my native language, whether that is essential or non-essential to the discussion; and I find "Project-linking, custom-tweaked icons" as a rather roundabout statement. If you want to get in the more precise language, they are imagemaps as Dudemanfellabra stated. My question to you David is do you understand XHTML: the language Wikicode is parsed into? You need the jargon to be specific and without ambiguity. Nevertheless:
1. I've rephrased "This is the English Wikipedia, which is one of more than 250 Wikipedias currently available." for clarity. That is unless you want to continue the clause.
2. Rather than saying:
"Wikipedia pages contain lists (in the left-hand column by default) of interlanguage links to corresponding pages in other languages."
how about
"Pages in Wikipedia contain a list, in the lef-hand column by default, of interlanguage links that corresponds with that page the pages in other languages."
3. In the discussion about the "English language", I think that the idea of people assuming that this could refer to things in England is a bit of a stretch; and I don't think linking would help. Rather my position is to omit that link, and change "English" to simply saying "This is the English language Wikipedia[...]". FWIW, there is a page on the English language Wikipedia, link, whether that is helpful or not. ChyranandChloe (talk) 05:00, 21 December 2008 (UTC)[reply]
A. I previously referred to "imagemaps," so I don't know why you're implying that I'm unfamiliar with the term.
However, the type of code used to generate the functionality in question (and I know of two alternative methods) isn't germane to the discussion.
That also has absolutely nothing to do with my reversion to image files that have been "custom-tweaked" for optimal display in this section.
Please don't ask me to use "jargon" that's irrelevant to what I'm saying. And please stop blaming me for your failure to comprehend your native language. Your messages contain numerous syntactical errors that sometimes render them difficult to parse, so you might want to stop throwing stones from your glass house.
B. I have a moderate degree of familiarity with XHTML. Why?

1. Either way seems fine to me.
2. I don't mind switching from "Wikipedia pages" to "Pages in Wikipedia," but your wording contains some serious singular/plural inconsistency.
3. If that sounds like a stretch, you obviously haven't encountered users harboring such confusion. I have.
I don't know how the link could be anything other than helpful and informative, and that certainly was the consensus during the last main page redesign. —David Levy 05:45, 21 December 2008 (UTC)[reply]
Ok, I see it now "Pages in Wikipedia contain a list, in the lef-hand column by default, of interlanguage links that corresponds with the pages of other languages". In point three, could be more specific? I'd like to know "how" they get confused rather than it is. I don't know how you want me to respond to the first section of your post, or what you want me to address in it. ChyranandChloe (talk) 06:51, 21 December 2008 (UTC)[reply]
1. Let's break down the newly modified sentence:
Pages in Wikipedia contain [plural]
a list...of interlanguage links that corresponds [singular]
with the pages in other languages. [plural]
Also, "lef-hand" (in the segment that I omitted for clarity) is a typo for "left-hand."
If I correct the typo and switch to consistent plurality, I arrive at the following:
Pages in Wikipedia contain lists, in the left-hand column by default, of interlanguage links that correspond with the pages of other languages.
The lists of links (or the links themselves, as the above now could be interpreted) correspond with the pages of other languages? That isn't very clear.
2. Off the top of my head, there have been many instances in which people erroneously believed that this site should be written strictly in British English (because it's the "English Wikipedia," not the "American Wikipedia," et cetera). —David Levy 06:56, 21 December 2008 (UTC)[reply]
(outdent) I see it now, and thanks. One thing I need to stop doing is reading at a glance; since do a lot in outlining in articles (Rabies is the latest one), I have to look at it quickly and holistically so that I can't get bogged down by the details. Because of this, I don't pay anywhere near enough attention to syntax as I should: I'm in the habit of just looking for the central point. I'll try to fix that as the discussion goes on.

The issue I see with the original sentence is that it's trying to brings too many thoughts together. In that what I think I was trying to do is divide the sentence into "Pages in Wikipedia has a list of internlanguage links." and "These links correspond to the pages of other languages." ChyranandChloe (talk) 07:15, 21 December 2008 (UTC)[reply]

The intended message is that our pages correspond to other Wikipedias' pages (which we link to), not that the "links correspond to the pages of other languages." Simply referring to them as links to those pages conveys the latter concept. —David Levy 07:27, 21 December 2008 (UTC)[reply]
How about: "In the left-hand column of Wikipedia pages you'll find interlanguage links to the corresponding pages." OR: "In the left-hand column of a Wikipedia pages you'll find interlanguage links to the corresponding pages." (One page in Eglish, many pages in as many other languages.) OR: "The left-hand column of a Wikipedia page contains a list of interlanguage links to the corresponding pages." What a mess. My head is spinning… HereToHelp (talk to me) 14:11, 21 December 2008 (UTC)[reply]
None of those seem as clear as the wording currently used in the draft. All stop short of explaining how the linked pages correspond to ours. ("Interlanguage" is not a widely used term.) None reflect the fact that the list appears on the left by default (and elsewhere in non-default skins).
Are we trying to address specific problems with the current wording? —David Levy 19:04, 21 December 2008 (UTC)[reply]
(outdent) Since we are designing the main page for the reader rather than the editor, can we assume that "by default" is non-essential to the message we're trying to get across? For example, those who change their skin from monobook to something else would have to be registered and would also have to know what they are doing.

Going by what you've said earlier, could we say just that: "Pages in the English Wikipdia correspond to the pages in other language Wikipedias though the list of links in the left-column by default."? ChyranandChloe (talk) 03:16, 22 December 2008 (UTC)[reply]

1. You're assuming a level of expertise that doesn't automatically accompany account registration and skin selection.
2. You seem to think that we're using "correspond" to mean "connect" or something similar (Pages in the English Wikipdia connect to the pages in other language Wikipedias though the list of links in the left-column.). That isn't what the word means. The intended connotation is "to be similar or analogous; be equivalent in function." —David Levy 03:41, 22 December 2008 (UTC)[reply]
None of the ones proposed seem to satisfy the criteria you're putting it up to, and yet there is also disagreement about the original sentence. Do you have anything in mind that isn't the original? Or is this it? ChyranandChloe (talk) 03:57, 22 December 2008 (UTC)[reply]
I have nothing better in mind, but if you cite your specific concerns regarding the current wording, I'll do my best to address them. —David Levy 04:14, 22 December 2008 (UTC)[reply]
(outdent) "Wikipedia pages contain lists" makes it feel ambiguous whether each page contains multiple lists or each page contain one list. I don't like the parenthesis since it separates "lists of interlanguage links". "to corresponding pages in other languages" makes it sound run-on compared to the relatively short clauses that precede it. Same applies for the next sentence, but if you can't solve it or don't want to, then I guess I'm fine with what we got right now. ChyranandChloe (talk) 05:32, 22 December 2008 (UTC)[reply]
Here's another attempt:
Each project is written in multiple languages. This is the English Wikipedia, which is one of more than 250 Wikipedias currently available. Interlanguage links, appearing in the left-hand column by default, are used to connect a page to other Wikipedias' pages on the same subject. If the desired language is not listed, you can request a translation or assist in the translation yourself.
David Levy 06:41, 22 December 2008 (UTC)[reply]
I like it, although "connected" seems awkward. ChyranandChloe (talk) 05:02, 23 December 2008 (UTC)[reply]

Might it be helpful to invite the talkpage of {{Wikipedialang}} here? They've probably got a good take on the wording used to introduce our language variants. Maybe Talk:English Wikipedia too. -- Quiddity (talk) 06:14, 22 December 2008 (UTC)[reply]

I'm of the viewpoint that this information isn't even logical on the Main Page; surely this kind of text belongs on the List of Wikipedias, or a how-to-use Wikipedia type page. We don't have a passage explaining that "each Wikipedia page contains a set of tabs (at the top by default)", so why languages? It's not where people will expect to find this information. PretzelsTalk! 16:49, 22 December 2008 (UTC)[reply]
I must say that I've given some serious thought as to whether this text belongs on the page at all. I'm not sure. —David Levy 20:13, 22 December 2008 (UTC)[reply]
The reason I think why we have this statement is to place the English Wikipedia in context and to promote the other languages (WP:CSB). In my opinion, it feels a little out of place in that we could probably could merge it with the sentence above the sister projects. Dudemanfellabra brought this up before and I'm interested to see what he has to say. ChyranandChloe (talk) 05:02, 23 December 2008 (UTC)[reply]

Centering the Sister projects

[edit]

I'm proposing to center the Sister project icons as seen above. What do you guys think? ChyranandChloe (talk) 23:54, 4 January 2009 (UTC)[reply]

So they'll no longer be 100% width, in other words. I don't see the point. PretzelsTalk! 00:13, 5 January 2009 (UTC)[reply]
I agree with Pretzels. I like the current version better. --Dudemanfellabra (talk) 01:10, 5 January 2009 (UTC)[reply]
The massive previous discussion on sister projects hasn't even concluded yet. This whole redesign has fallen apart. PretzelsTalk! 02:01, 5 January 2009 (UTC)[reply]
I think we've pretty much agreed on the sister projects thing. Yes, we got bogged down in the details there for a little while, and it was a little monotonous at times, but I wouldn't say the redesign has fallen apart. We've simply hit a bump in the road. I think now that everyone has taken a little break (holidays came at a convenient time, eh?) we can get back to business. --Dudemanfellabra (talk) 02:26, 5 January 2009 (UTC)[reply]
I wouldn't say the MPRP fell apart, we had a serious conflict in interest mainly on my part; and you can find the full discussion on my user talk, it's under archive "2009-01-02". Remaining focused the on improving the MPRP, the consensus so far is that we do not want to center the table of sister project icons. "So they'll no longer be 100% width", yes, the reason for this was because as screen sizes got larger it'll keep stretching the columns apart to the point where they'll no longer resemble a cohesive set of icons. In other news I've cleaned up the code for the sister projects. ChyranandChloe (talk) 04:02, 6 January 2009 (UTC)[reply]