Wikipedia talk:2014 main page redesign proposal/Archive 2

New attempt
At Talk:Main Page, there's been some discussion of trying this again. I temporarily moved last year's talk page to this title, so it should appear on the watchlists of editors following that attempt. Any interest? —David Levy 21:50, 26 January 2013 (UTC)


 * I would be interested in helping out, but its got to be better organised than last year. There's got to be design criteria (for what wikipedians actually want), rather than just asking people to submit mockup proposals where everything and anything can be changed. - Evad37 (talk) 01:42, 27 January 2013 (UTC)


 * I couldn't agree more. I don't know whether you've read the aforementioned discussion, but that's exactly my take on the situation.  —David Levy 02:08, 27 January 2013 (UTC)


 * Support. I think it's a decent idea, and we should try it out. :-) Dodoïste (talk) 09:39, 27 January 2013 (UTC)

Procedure
Here's a first draft for a procedure based on the discussions mentioned above.


 * 1) Brainstorming principles and elements: 30 day RFC to ask community to brainstorm design principles and elements that should be included on the main page. Discussion is welcome but voting will wait until the end of the brainstorming period.
 * 2) Voting period on principles and elements: 30 day RFC for the community to vote on the principles and elements that were proposed. Voting options will be Support, Weak Support, Neutral, Weak Oppose, and Oppose.
 * 3) Tally period for votes on principles and elements: 7-14 days depending on how much work is involved to tally the votes.
 * 4) Proposal period 60 days for editors to submit and discuss designs based on the principles and elements votes. Proposals may include existing designs such as the current design, designs that were submitted during the 2012 main page redesign discussions, and/or variations of existing designs.
 * 5) Voting period on proposed designs 30 day RFC for editors to vote on proposed designs. Voting options will be Support, Weak Support, Neutral, Weak Oppose, and Oppose.
 * 6) Tally period for votes on proposed designs: 7-14 days depending on how much work is involved to tally the votes.
 * 7) Top two runoff for proposed designs 30 day RFC for editors to vote on the top two. Voting options will be Support, Weak Support, Neutral, Weak Oppose, and Oppose.
 * 8) Tally period for runoff votes 7-14 days depending on how much work is involved to tally the votes.

Comments? Should we have an RFC about the procedure itself? --Pine✉ 23:51, 27 January 2013 (UTC)


 * I would work from the feedback provided for the 2012 proposals. --Izno (talk) 00:39, 28 January 2013 (UTC)


 * I think feedback provided from the 2012 proposals could be included in the "Principles and elements" phases if editors wish to use that feedback to inform the 2013 discussions. --Pine✉ 00:41, 28 January 2013 (UTC)


 * Parts of the above suggestion make sense, but it also duplicates some of the mistakes made made last year and in 2008 (and initially in 2006).
 * Firstly, there are too many steps and formalities. This causes editors to grow impatient and lose interest.
 * Secondly, there can't be predetermined time frames. The process will take however long it takes and mustn't be hampered by deadlines.
 * Thirdly, there shouldn't be any formal competition among prospective designs. That might be the single biggest factor in the last two attempts' failure (and it almost derailed the successful 2006 redesign, which fortunately was refocused).  Users may create separate mockups, but not for the purpose of voting.  We should discuss them and seek to incorporate the best elements into a single collaborative design (and only then ask the community to vote on whether it will replace the current main page).  This is what rescued the 2006 redesign.
 * In short, history has shown that this endeavor cannot succeed unless it takes the form of a wiki-style collaboration, not a highly-structured competition. —David Levy 01:00, 28 January 2013 (UTC)


 * Here's my idea for the procedure, based on consensus decision making at each step:
 * 1. Brainstorming for the RFC discussion - to be done here by those interested. The RFC should be designed as to give us design criteria for each section of the main page, and overall (ie how much change is desired). Move onto next step after consensus is reached.
 * 2. RFC Discussion - to be widely advertised. Discussion to be based around comments which support or oppose statements (which would either be worked out in the brainstorming, or alternatives proposed by anyone at the RFC). Each section would be open a minimum of 30 days, but not be closed until there is consensus. If a section does not seem to be reaching consensus, and discussion isn't continuing, then it may need to be closed as "no consensus".
 * 3. Develop design criteria and guidelines - to be done here by those interested, following and based on the RFC. Move onto next step after consensus is reached.
 * 4. Mockup review - Mockups from previous design attempts, and newly submitted mockups, to be reviewed against the design criteria, and discussed to identify the best ideas/elements.
 * 5. Develop a main page alternative - can perhaps be done simultaneously with the last step. To be located here at a subpage, and open to editing by all editors, to include the best elements/layout as identified above. Multiple versions could be considered. At this stage it would be useful to recruit people with template and/or HTML/web design knowledge in order to create a proper, working alternative. Assistance from the wikiprojects managing the current elements of the main page may also be required. The final version will need to be edit protected.
 * 6. Community vote - after there is consensus on the final version from the above step, put it to an RFC vote. Needs to be widely advertised and open for at least 30 days. Closer should be an uninvolved admin, if possible.
 * - Evad37 (talk) 01:57, 28 January 2013 (UTC)


 * The above strikes me as an excellent plan, very much in line with what's worked in the past (and mindful of what hasn't). Provided that we remain flexible and allow for adjustments as the circumstances dictate, I think that it has a good chance of succeeding.
 * My one note would be that the community vote probably needn't remain open for 30 days. (The 2006 poll ran for 18 days, during which it generated an unprecedented level of participation.)  —David Levy 02:35, 28 January 2013 (UTC)


 * Without deadlines don't we have the risk that some steps would take long periods of time and editors would also lose interest through this process? Deadlines push the process to move forward. Also, given the large number of possible editors involved, does having so many editors working on a single set of criteria and a single mockup make it more likely that there will be edit wars and WP:OWN issues? By allowing separate proposals for elements and designs as I proposed I think heated conflicts are less likely. --Pine✉ 04:14, 28 January 2013 (UTC)


 * It's all but certain that the process will be lengthy, provided that it doesn't stall (as it did the last two times).
 * Redesigning the English Wikipedia's main page is an ambitious and challenging endeavor. It can't be expedited by imposing artificial time constraints.
 * Deadlines didn't prevent editors from losing interest and abandoning the 2008 and 2012 attempts. In fact, they helped to cause this (by prematurely halting their efforts).
 * ...ready or not. In 2008 and 2012, deadlines came and went (along with the participants).  In 2006, we worked as long as we needed to, relying on consensus to tell us when to move on to the next stage.  This was the result.
 * Yes, it does. The alternative is to allow everyone to do their own thing, thereby creating dozens of arbitrary variants that reside in the project space forevermore.
 * Likewise, we could greatly reduce the number of heated conflicts by allowing everyone to write their own versions of articles instead of collaborating and seeking consensus. We just wouldn't end up with a usable encyclopedia.
 * No one promised that this would be easy. It won't be.  But if we put in the effort and avoid the pitfalls, it can be successful.  —David Levy 05:00, 28 January 2013 (UTC)
 * Yes, it does. The alternative is to allow everyone to do their own thing, thereby creating dozens of arbitrary variants that reside in the project space forevermore.
 * Likewise, we could greatly reduce the number of heated conflicts by allowing everyone to write their own versions of articles instead of collaborating and seeking consensus. We just wouldn't end up with a usable encyclopedia.
 * No one promised that this would be easy. It won't be.  But if we put in the effort and avoid the pitfalls, it can be successful.  —David Levy 05:00, 28 January 2013 (UTC)
 * No one promised that this would be easy. It won't be.  But if we put in the effort and avoid the pitfalls, it can be successful.  —David Levy 05:00, 28 January 2013 (UTC)


 * Obviously we don't want steps to drag on for too long, but also there is no sense having a firm deadline if discussion and collaboration is ongoing. If discussion is going stale, then it needs to be closed with consensus determined. I suppose a rough timetable could be worked out, as long as it isn't used as an excuse to rush through the process.
 * The set of criteria is needed so that designs actually have a chance of passing the final vote. What is the point of any of this if we are going to let any old design come along, suck up time and effort, and then face overwhelming opposition because its not what wikipedians want?
 * There wont be a single mockup - any will be able to sumbit and effectively own a mockup - but having a single main alternative should encourage collaboration. Normal editing guidelines will still apply to the draft main page alternative, with disputes taken to the talk page, edit warring banned, no WP:OWNership of the page, and normal WP:Etiquette. If it really becomes too hard, then it can be edit protected earlier on the process, with changes implemented by an admin only after discussion on the talk page.
 * Separate designs may reduce conflict, but would also reduce collaboration - what I propose is taking the best of each mockup submitted design into a collabortaive design
 * Finally, if something like this worked in 2006, why wouldn't it work in 2013? - Evad37 (talk) 05:03, 28 January 2013 (UTC)
 * Finally, if something like this worked in 2006, why wouldn't it work in 2013? - Evad37 (talk) 05:03, 28 January 2013 (UTC)


 * OK, I am willing to support Evad37's version of how this may be workable. I think present conditions may be different than they were in 2006 but I'm still willing to support Evad37's ideas. If this attempt fails then we can try a different method. I am hopeful that this attempt will succeed. --Pine✉ 19:43, 28 January 2013 (UTC)


 * I am too. You might be right about the conditions changing since 2006 (and we may need to compensate for that), but knowing what didn't work a few months ago (and in 2008) should gives us a good idea of what to avoid.  —David Levy 20:03, 28 January 2013 (UTC)


 * OK, lets start brainstorming - Evad37 (talk) 05:18, 29 January 2013 (UTC)

Comments
(moved from brainstorming section as it focuses on the process - Evad37 (talk) 16:52, 3 February 2013 (UTC))
 * I do have a few. First, I think a major overhaul is the way to go. The current page is seven(!) years old; it's a dinosaur. Second, an RFC could be helpfull, but I also fear that it may lead to red tape. What I would like is to form a workgroup, or committee if you like, that will review all ideas coming from the initial RFC, and then translate that information into the the main page, focussing on content, layout, and design as separate focal points. Having to choose from dozens of mockups is bound to fail, because it will be impossible to focus on details. A small(er) group also ensures collaboration; involving the entire community in the entire process, with an RFC at every step, will give a flood of information and everyone will loose track, and consequently leave. — Edokter  ( talk ) — 15:41, 3 February 2013 (UTC)


 * - Whilst this is your viewpoint, it is important to know the view of the community - perhaps there are a significant number of people who think "it aint broke, don't fix it"? There would be no point in designing a "major overhaul" if there were to be only minority support for this type of change, therefore making it is unlikely to pass the final vote.
 * - This is basically what I proposed for step 3 the process in the above section, but without calling the participants a "committee" or "workgroup".
 * - basically step 5 of the process - but you have it divided into separate "focal points". Whilst it would be nice to implement content, layout, and design/style changes separately, they are inevitably tied into each other, unless only very minor changes are considered. If a content block is added or removed, than that forces a change in layout. Similarly, major design/style changes may change the relative size of content blocks, requiring layout changes and/or content changes to be considered.
 * - I agree with you on this point, however that doesn't mean we should just ignore the existing mockups. Some of them may have interesting ideas to try out, if they fit in with what we learn at the RFC
 * - I don't propose an RFC at every step, only the beginning, in order to get design criteria for the the community actually wants, and the end, to determine if there is consensus to implement the redesigned main page. However, perhaps we can form a wikiproject (perhaps WikiProject Main Page Redesign?) for organising the group of people who choose to be involved with the other steps in the process. I believe that would be better than "committee", which sound more exclusive, or like something one would be appointed to; whereas anyone can join a wikiproject. - Evad37 (talk) 16:52, 3 February 2013 (UTC)

Brainstorming for the RFC
What I envision for the RFC is a set of statements about the aims of the main page, with endorse and oppose sections. Each aim would be followed by discussion of whether the current main page achieves each aim, and if not, what needs to change. The discussion could lead to further statements, such as "The main page should include a ..... section" (with endorse and oppose sections). The degree of support for each statement would show us the relative importance of each aim, which could influence layout. Also, we will need to specify that were are not looking for just one primary aim (that seemed to be unclear in the 2011 RFC).

Some ideas for the initial statements on aims:
 * From the 2011 RFC:
 * Showcase Wikipedia's best content
 * Entice readers to become editors
 * Help readers find articles on specific topics (ie include navigation via portals or similar)
 * Showcase timely and newsworthy content
 * Promote the breadth of Wikimedia projects
 * Motivate editors to create new content
 * Others
 * Direct readers and editors seeking help to appropriate venues
 * Encourage donations to WMF
 * Describe the purpose of Wikipedia (ie an About Wikipedia section)

The other question that should be asked is: How much change is desired, with options being:
 * No change
 * Minor fixes (Minimal tweaks. Remove a couple of outdated links, update a few small things.)
 * Re-Style (Same basic layout, but change the look)
 * A major update (new style and modified layout, which would probably also entail content adjustment/s to make it work)
 * A major overhaul (something utterly different from the current main page)

Thoughts and commments (on the questions for the RFC)? - Evad37 (talk) 05:17, 29 January 2013 (UTC)


 * I guess I'm not clear on the differences between Phase 1 and Phase 2. I would think that Phase 2 could include brainstorming. I'll say right now that I oppose having "encourage donations to WMF" be an objective of the main page, WMF has many ways to ways money and the main page of this encyclopedia isn't for that purpose. --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 18:24, 3 February 2013 (UTC)
 * While phase 2, the RFC, could also include brainstorming and suggestions, phase I is meant to be designing the RFC - ie brainstorming what goes on it, rather than about the individual items, so that the important questions are there, and everything is described clearly, before the RFC opens for discussion. I've created a draft RFC here (old version - see Second draft RFC) so that it is clear what I was proposeing, and so we can work towards a final version there. - Evad37 (talk) 01:20, 4 February 2013 (UTC)
 * The poll seems sensible on paper. My main concern is that a similar one from 2011 had a disappointingly modest turnout.  It seems as though the more questions we ask, the fewer users are willing to read through them and respond.
 * So perhaps we could consider a more open-ended approach, at least to start out. Simply asking people what they like/dislike about the main page (and in the latter case, how it could be improved) might yield some useful feedback, including ideas that don't cleanly fall into a particular category.
 * Also note that a new section is due to be added to the main page soon (possibly this month), so we definitely should wait until after that occurs before opening the RfC (as it clearly stands to affect opinions, particularly regarding the concept of "enticing readers to become editors"). —David Levy 02:02, 4 February 2013 (UTC)
 * I see your point about more questions discouraging responses, and agree that we should definitely wait till after WP:TAFI is added. Having a single open-ended discussion rather than multiple sections will of course mean more work analysing the RFC (but as you said above, "No one promised that this would be easy"). What do you think about having an open ended discussion, followed by a straw poll on the amount of change needed? It would be useful to know what proportion of users want big changes compared to those wanting small changes, or no changes at all. - Evad37 (talk) 03:37, 5 February 2013 (UTC)
 * I do think that there should be a follow-up straw poll, with its exact nature determined by the responses received in the initial discussion (which might or might not give us a good idea of the amount of change desired, while hopefully narrowing our focus to a manageable subset of the ideas laid out in the draft RfC). —David Levy 03:53, 5 February 2013 (UTC)
 * Clarification, I think "Directing readers and editors seeking help to appropriate venues is an aim of the main page" should instead be "Directing readers and editors seeking information or media resources to appropriate venues is an aim of the main page". You could add "Directing readers and editors seeking help with editing to appropriate venues is an aim of the main page" as a separate point. --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 05:46, 5 February 2013 (UTC)
 * I did actually mean the various Help: pages, which cover more than just "help with editing". At this point it is not clear how the aims are to be discussed - per David Levy's comments above, having a lot of questions/subsections is not such a good idea. - Evad37 (talk) 14:14, 6 February 2013 (UTC)
 * I'm not sure I'm following the procedure about having an open ended discussion. Could we have an open ended discussion in the "brainstorming" phase and include the "brainstorming" phase in the RfC, and then have a follow-up straw poll on things that were mentioned in the "brainstorming" phase as phase 2? --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 05:50, 5 February 2013 (UTC)
 * I think this is basically what is proposed at the moment. - Evad37 (talk) 14:14, 6 February 2013 (UTC)
 * In addition to discussing what the aims of the Main page are, I think we need to discuss how those aims are accomplished. Users might want to comment on fonts, colors, or other stylistic elements, or where on the page certain elements should be located. --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 05:52, 5 February 2013 (UTC)
 * Yes, style and layout considerations are important, and they should be encouraged in the RFC discussion. - Evad37 (talk) 14:14, 6 February 2013 (UTC)

I am going to make a second RFC draft, based on the above comments. Will post the link here when done. - Evad37 (talk) 14:14, 6 February 2013 (UTC)

Advertising
Once the RFC is finalised and opened, it should obviously be advertised widely - at WP:CENT, WP:VILLAGEPUMP, Talk:Main Page, as well as WP:RFC/PROP (via the RFC template). A watchlist notice would inform editors who don't follow those pages. Is there anywhere else that I've missed? - Evad37 (talk) 03:37, 5 February 2013 (UTC)
 * Yes, and add the Wikipedia-en email list. --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 05:40, 5 February 2013 (UTC)
 * We should also leave a note for each project responsible for a main page section: TFA, DYK, ITN, OTD, TAFI, POTD, TFL. - Evad37 (talk) 02:42, 8 February 2013 (UTC)

Second draft RFC
I've made another draft RFC, located at 2013 main page redesign proposal/Draft RFC/2. What do you think? - Evad37 (talk) 15:22, 6 February 2013 (UTC)
 * Yes, I think this makes sense for a first round of the RFC. It's going to be a lot of work to close that round but I see this brainstorming round as a necessary step for moving forward if we intend to involve as many people as possible. --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 05:58, 7 February 2013 (UTC)
 * Very nice work. The wording is a good balance of brevity and thoroughness.  It solicits a great deal of useful information without seeming overwhelming.  —David Levy 06:27, 7 February 2013 (UTC)

The RfC is quite scattered
As it currently stands, the RfC appears to be a very arbitrary collection of ideas, and is bound to become repetitive, as well as hard to navigate. I wonder if summarising most of it in a points format right now is a good idea so everyone can quickly check which of the points have been already mentioned. TheOriginalSoni (talk) 08:14, 9 May 2013 (UTC)
 * +1. I was going to suggest this myself. Rd232 talk 09:25, 9 May 2013 (UTC)
 * Perhaps we should have a separate ==Discussion== section where threaded discussion can occur under ===level 3=== headers. The TOC would then show the points already being discussed. - Evad37 (talk) 02:38, 10 May 2013 (UTC)
 * Anyone ready to get their hands dirty on that? I think if we dont do it, this RfC might crumble faster than we think. Evad37? Rd232? David Levy?? Anyone? TheOriginalSoni (talk) 21:14, 10 May 2013 (UTC)
 * I've done some refactoring so that comments are now under level 3 heading of the form "Comments by ". I decided separating replies/discussion from initial comments wasn't a good way to go - would have been rather messy and complicated to do - Evad37 (talk) 04:40, 11 May 2013 (UTC)
 * It still doesnt look pretty. I suggest moving entire comments to their respective columns in the first half of the RfC. (Most of them can be done) TheOriginalSoni (talk) 11:31, 11 May 2013 (UTC)
 * WP:SOFIXIT - Evad37 (talk) 12:12, 11 May 2013 (UTC)
 * Started. Will need others to hop in and do the same. There are too many grey area comments that come everywhere. TheOriginalSoni (talk) 11:21, 13 May 2013 (UTC)

Evad37, Rd232, David Levy and anyone else reading this - I am trying to sort everything into their respective sections so we can have the discussions, but its turning out to be quite a deal of work. If we dont compete this fast enough, this Rfc might be too hard to navigate and/or manage and/or close and it would not be possible for us to move forward. May I have a hand please? TheOriginalSoni (talk)

Seems like a strange approach
It isn't clear what problem this entire process is intended to solve. Yes, people occasionally try to redesign the Main Page and it fails. Yes, the page has looked the same for a long time. But...

But what's wrong with the current Main Page? Incremental updates are always going to beat out rewrites, I think. At least at this point. Identifying what's wrong (even a small piece) and then working on just getting that fixed is the way to go. That could be just a certain section (e.g., enhance the featured picture section in some way), or a particular color (no more green!), or whatever. Just fixing up the header box to be a little less ugly would be a great first step, in my opinion, and might snowball into other good, healthy incremental updates to the page.

I appreciate the more thoughtful and considered approach that people are trying to take here (certainly better than the 2012 competition), but I think that even with a slower pace and more discussion, you have to start by identifying a specific problem (or set of problems) and focus on those. If there aren't any problems to identify with the current Main Page (besides its age), leave it alone. :-) --MZMcBride (talk) 10:32, 8 February 2013 (UTC)


 * That's what we're doing. The RfC is intended to identify specific areas in need of improvement (if any) and how to go about it.  We realize that change for the sake of change (as seen in the failed redesign attempts) doesn't work.  —David Levy 11:51, 8 February 2013 (UTC)


 * I agree, a fact finding mission is the first step, even if the mission discoveres there are no facts to find and the design is nigh perfect. I feel there is room for improvement, and the Main Page design would likely benefit from a broad discussion like this. -- Nick Penguin ( contribs ) 17:19, 8 February 2013 (UTC)

In what way will this RFC differ from the 2011 RFC?
I was browsing around a bit, and I cam across this RFC from 2011 about Main Page features, which at a glance has almost the same structure as the current draft proposal. How will this new RFC be different and gain more traction than the last one? Or maybe I should characterize this differently, how can the last RFC be used to improve and focus this RFC? -- Nick Penguin ( contribs ) 18:38, 8 February 2013 (UTC)


 * To which draft are you referring? Verson 1's format is very similar to that of the 2011 RfC, but we've moved on to version 2 (intended to greatly simplify the discussion, thereby attracting wider participation).  —David Levy 22:07, 8 February 2013 (UTC)
 * I've now added a notice to version 1 to indicate that it is an old version, with a link to version 2. - Evad37 (talk) 02:01, 9 February 2013 (UTC)
 * Being late to the party, I was looking at the old version. Looks good, a very general inquiry. -- Nick Penguin ( contribs ) 19:59, 9 February 2013 (UTC)

Current status
What is the current status of this proposal? Are we going to have a RFC at all? I liked the current draft version. -- Taku (talk) 01:18, 26 March 2013 (UTC)
 * The current status is that we're waiting for WP:TAFI to be implemented, which looks like it will be April 8 (more info). After TAFI is on the main page, and users have had a few weeks to get used to it, we'll have the RFC... so probably early May, if everything goes to schedule. - Evad37 (talk) 02:11, 26 March 2013 (UTC)

RFC start date
TAFI is now up on the main page. How does everyone feel about a starting the RFC on Monday May 6th? This gives everyone three weeks to get used to TAFI before the RFC opens. - Evad37 (talk) 00:39, 18 April 2013 (UTC)
 * I think that's an excellent start date; by then TAFI should be able to gather some data to measure the projects effectiveness, and give that input to the redesign. In truth, you have been very patient, and I think that will be a testament to this redesign's success. -- Nick Penguin ( contribs ) 01:24, 18 April 2013 (UTC)
 * OK with me. --<span style="white-space:nowrap;text-shadow:#008C3A 0.1em 0.1em 1.5em,#01796F -0.1em -0.1em 1.5em;"><b style="color:#01796F;">Pine</b><sup style="color:#01796F;">✉ 20:39, 20 April 2013 (UTC)

User:Paladox2014/Main_Page
hi I have been developing a new main page and I think I am finished with the new dsgn if you doint think it is not finishe please could I have some help at User:Paladox2014/Main_Page to improve it please Paladox2014 (talk) 12:07, 27 April 2013 (UTC)
 * Hi Paladox. Its great that you want to improve the main page, however any changes you (or anyone else) propose to make have virtually no chance of being implemented, unless there is widespread support from the community. That is why we are going to have an RFC so the community can tell us what they like about the main page, and what should be changed. The rest of the process we intend to follow is described on the project page. - Evad37 (talk)

New design for main page in sandbox
Hi I have created a cleaner and newer look in sandbox for main page it has a more new colour and has the same look just newer please visit User:Paladox2014/Main Page Paladox2014 (talk) 21:15, 5 May 2013 (UTC)
 * Hi. I've moved your redesign to your user space. The Main Mage sandbox of for testing new code before it goes live on the Main Page, not for testing new designs. Thank you. — Edokter  ( talk ) — 11:12, 11 May 2013 (UTC)

RFC has opened
The RFC is now opened. It has been advertised on Talk:Main Page, Centralized discussion, Village pump (proposals), and the main page section projects have been notified: TFA, DYK ITN, OTD (Selected anniversaries), POTD, TFL, TAFI. I have also requested a watchlist notice.

Can someone who is already subscribed to the email list for wikipedia-en post a message there? - Evad37 (talk) 01:40, 6 May 2013 (UTC)

Prior proposals
The background section mentions the 2012 proposals and mock-ups, any chance that these (and other previous?) discussions could be linked to in said section to aid those who's thinking caps may be running low on power and so people can have an idea of what has floated or sank with the community in the past? -- wintonian  talk  03:13, 17 May 2013 (UTC)
 * . (Though there were linked to from the See Also section at the bottom of the page) - Evad37 (talk) 04:21, 17 May 2013 (UTC)
 * My mistake then, didn't think to look there. -- wintonian  talk  11:57, 17 May 2013 (UTC)

Short summary of the completed steps
I suggest at 2013 main page redesign proposal to add a short summary of the results under the respective step once it is finished. For example, once the RFC is over, list a short summary of the main results at 2013 main page redesign proposal. This would provide a good overview over where we are standing and also make it easier for people who might not have followed it from the beginning to jump in in the middle of the process. --  Toshio   Yamaguchi  06:08, 23 May 2013 (UTC)


 * Is the goal of this phase of the rfc to make a list of all the ideas that have come up, and than discuss the merits of each one individually in another rfc? I worry that this process will be taken by some to be an all or nothing deal, rather than a way to discuss the best ideas and use them to guide designs. -- Nick Penguin ( contribs ) 15:21, 23 May 2013 (UTC)

Proposed Simple Main Page
I would like to propose a simple main page.

First, the reason why I am proposing this:

Page Weight Matters, by Chris Zacharias


 * "Three years ago, while I was a web developer at YouTube, one of the senior engineers began a rant about the page weight of the video watch page being far too large. The page had ballooned to as high as 1.2MB and dozens of requests. This engineer openly vented that “if they can write an entire Quake clone in under 100KB, we have no excuse for this!” Given that I agreed with him and I was excited to find a new project, I decided to champion the cause of getting the YouTube watch page to weigh in under 100KB. On the shuttle home from San Bruno that night, I coded up a prototype. I decided to limit the functionality to just a basic masthead, the video player, five related videos, a sharing button, a flagging tool, and ten comments loaded in via AJAX. I code-named the project “Feather”.


 * "Even with such a limited set of features, the page was weighing in at 250KB. I dug into the code and realized that our optimization tools (i.e. Closure compilation) were unable to exclude code that was never actually used in the page itself (which would be an unfair expectation of any tool under the circumstances). The only way to reduce the code further was to optimize by hand the CSS, Javascript, and image sprites myself. After three painstaking days, I had arrived at a much leaner solution. It still was not under 100KB though. Having just finished writing the HTML5 video player, I decided to plug it in instead of the far heavier Flash player. Bam! 98KB and only 14 requests. I threaded the code with some basic monitoring and launched an opt-in to a fraction of our traffic.


 * "After a week of data collection, the numbers came back… and they were baffling. The average aggregate page latency under Feather had actually INCREASED. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking LONGER for videos to load on Feather. This could not be possible. Digging through the numbers more and after browser testing repeatedly, nothing made sense. I was just about to give up on the project, with my world view completely shattered, when my colleague discovered the answer: geography.


 * "When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.


 * "Through Feather, I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets."

Source: [ http://blog.chriszacharias.com/page-weight-matters ]

(Reproduced under fair use: "The first factor is regarding whether the use in question helps fulfill the intention of copyright law to stimulate creativity for the enrichment of the general public, or whether it aims to only 'supersede the objects' of the original for reasons of personal profit.")

Because of the above considerations. I propose the following:

User:Guy Macon/Simple Main Page

Proposed Simple Main Page Discussion
Does anyone know how to selectively exclude sections from the table of contents? I want to keep "Proposed Simple Main Page" and "Proposed Simple Main Page Discussion" while nuking "Today's Featured Content", "Other areas of Wikipedia" and "Wikipedia's sister projects".

I tried putting NOTOC in the transclusion but that killed the TOC on this page. Feel free to delete this comment if you fix it. Thanks! --Guy Macon (talk) 09:44, 25 May 2013 (UTC)


 * Apples and oranges... You can't compare Wikipedia and Youtube. As a matter of fact, the source of the current main page weighs in at a mere 6.3 KB. The served page is about 63 KB, of which 7 KB is body text. Then there are images, CSS and scripts that are loaded. You can see that even a very simple main page will save very little. Real saving can be done by using the mobile version, which is designed to be light-weight. — Edokter  ( talk ) — 14:02, 31 May 2013 (UTC)


 * Images, CSS and scripts count too. It doesn't matter why the page loads slow in Uganda. All that matters is that it does.


 * Our main page weighs in at 342KB and 39 requests.


 * Mobile is 137 KB and 17 requests.


 * Google advanced search is 85 KB and 3 requests. (to test the Google main page, you will have to wait until they aren't showing a short movie about petri dishes on the main page)


 * My personal web page is 4 KB and 2 requests, but I don't think anyone here wants to go that simple... (smile) --Guy Macon (talk) 18:21, 31 May 2013 (UTC)

Will this succeed
Do any of the old-timers here think this will succeed where all other attemps have failed? The problem with these long drawn out and unorganized discussions is that they wear people out and people start dropping like flies. Remember 2012 main page redesign proposal? Long meandering discussions like this will never reach a consensus on anything. If you give the community 10 choices, none of them will get over 50% (or even close to it), and therefore will never reach a consensus. And a discussion like this that has perhaps hundreds of differnt ideas will be even worse.

If you want to change the main page, pick a single alternative for the community to !vote up or down. That's the only way a major change like this will ever reach a consensus. 64.40.54.145 (talk) 03:33, 28 May 2013 (UTC)


 * We're not going to present 10+ designs to vote on this time. Hopefully, theis will be a redesign from scratch with all involved. Right now, we're gathering general input which we can boil down to the core issues, then build on that, and so forth... — Edokter  ( talk ) — 14:04, 31 May 2013 (UTC)

International uniformity
Let's not reinvent the wheel; rather try to make it uniform in all languages.

My suggestion: check out what other langauges do, there might be something useful that can be copied one to one. A good example is,imho, the Dutch Main Page. Dvh369 (talk) 11:46, 28 May 2013 (UTC)

Next phase of the RFC
We should begin considering how to organize the next phase of the RFC. How do we want to integrate/summarize the points raised from this first portion of the RFC? -- Nick Penguin ( contribs ) 10:24, 1 June 2013 (UTC)


 * By issue/proposal seems to be the best option. Select the topics which have come up the most, and add the most pertinent viewpoints. This phase of the RfC was to locate our problems, now we'll be looking towards identifying potential solutions. Already suggested solutions will be another thing that needs to be added.
 * The thrid stage would then be to consolidate those solutions.
 * TheOriginalSoni (talk) 10:24, 4 June 2013 (UTC)
 * Heavens help me, I might read the entire RFC and produce a summary that should explain the current sense of the community on the redesign. I may also volunteer a first draft of this redesign, having recently finished with Wikimedia DC's main page redesign. Harej (talk) 02:30, 8 June 2013 (UTC)
 * Note that while what I linked to is quite fancy and flashy, whatever I end up designing for Wikipedia will probably be simpler and not as image-heavy. Different websites have different needs, after all. Harej (talk) 03:18, 8 June 2013 (UTC)

Time to move on to Phase two please
Hello,

Given the dwindling number of comments I think its well about time for us to start the next phase of this RfC. We must now be looking for specific points from the users on what needs to be the features for every topic mentioned, and also start voting on those points so we can have a list of requirements for the design phase. TheOriginalSoni (talk) 23:32, 9 June 2013 (UTC)

Some "conclusions"
Disclosure: I made one minor comment to the RfC.

Glancing through many (but not all) of the comments, I notice the following, in no particular order. This is not an official closing; just a rough summary of some of the major viewpoints. Please edit or object to this list at will.
 * Some people like the main page more or less as it is. Others don't.
 * In The News seems to be one of the least popular sections, perhaps because it duplicates Wikinews. For that matter, some pointed out that TFP duplicates Commons.
 * The page feels 2000-ish. The page needs to be more modern and exciting.
 * On the other hand, the page is currently low-bandwidth. More exciting would change this, causing problems for those with slow Internet.
 * Some users wanted the page to be spartan, almost like Google's home page. Others disagreed.
 * Three goals mentioned were, as Edokter put it:
 * Showcase featured content
 * Help new editor become involved efficiently
 * Help readers find what they are looking for fast
 * Goal #1 is achieved quite well. Goals #2 and #3 are not.
 * Goal #2 can be achieved by adding more prominent links to introductory pages. This might even allow the complete annihilation of the left sidebar for the main page.
 * Goal #3 could be helped by a bigger search box or links to portals. It might need more significant changes to the software, though.
 * Some Wikipedians complained that DYKs are low-quality and boring (Did you know that Hurricane Foobar hit Georgia?). Some suggested that Good Articles be added.

Again, feel free to edit this list or to present your own thoughts here. I'm just trying to get the ball rolling on the next step. Ypnypn (talk) 01:17, 12 June 2013 (UTC)
 * That captures the essence of it. In general, a future design will likely retain all the existing elements, although perhaps in smaller sections to accommodate additional sections. One thing to clarify is wither goals 1, 2 and 3 are in priority order. If they are, then designs should reflect that (50 showcase content, 35% get editors involed, 15% finding content). -- Nick Penguin ( contribs ) 02:16, 12 June 2013 (UTC)
 * I would personally give a 40% finding, 30% getting them involved, and showcasing. TheOriginalSoni (talk) 04:30, 12 June 2013 (UTC)


 * I dispute the assertion that the page is currently low-randwidth. I do not consider 342KB and 39 requests to be low-bandwidth. Google advanced search weighs in at 85 KB and 3 requests. That is low bandwidth. --Guy Macon (talk) 05:19, 12 June 2013 (UTC)
 * What is the primary cause of the high page size, is it rendering all those tables? Or is it the images? -- Nick Penguin ( contribs ) 02:35, 14 June 2013 (UTC)
 * For that matter, what is our baseline? How long would it take to load a completely blank Wikipedia page? That is our zero-bound; it can only grow from there unless MediaWiki is further optimized. Harej (talk) 22:43, 22 June 2013 (UTC)
 * Comparing a page full of content to a form is obnoxious and meaningless. <span style="font-size:0.9em; font-family:Georgia,serif; font-style:italic;">&mdash; PretzelsHii! 00:15, 23 June 2013 (UTC)
 * Considering that there's a Wikipedia search box on every page, a search form entry page is obviously ludicrous. As per NickPenguin's query, I, too, would be interested in a breakdown of where the entry page is byte heavy. 342KB does not strike me as being seriously byte-heavy and, considering that I've long since ceased to use the google home page as my own home page because it sometimes takes ridiculously long periods of time to load (dependent on their server, my server, traffic & a multitude of factors), being concerned with byte-heavy is an entirely different concern in terms of the Wikipedia entry page. Levels of logic and a sense of who the entry page 'audience' truly are should be the primary concern. I'm sticking to my guns on this issue - being that a simple feedback form for collecting information from the primary users on the current page would be a genuinely informed process of gleaning useful information rather than asking contributors/editors to guestimate what users want. That's just us piping up about our personal predilections and ignoring the majority of users. --Iryna Harpy (talk) 04:18, 23 June 2013 (UTC)

By the way, this is an excellent summary of the discussion (which I admit I could not get through all of). Anyone designing a new main page should keep those things in mind. Harej (talk) 22:43, 22 June 2013 (UTC)
 * Thanks, Ypnypn for alerting us to move further discussions here. (Oops, and apologies for correcting your spelling of bandwidth. I've been proofing for a few hours & was still in auto-edit mode!) --Iryna Harpy (talk) 03:57, 23 June 2013 (UTC)

TheOriginalSoni (talk) 03:47, 23 June 2013 (UTC)
 * Other possible suggestions for websites to emulate were - JSTOR, Vietnamese Wikitionary, Windows 8 wikipedia app and the French Wikipedia
 * Having more and bigger pictures than a Wall of Text was also among the options.

Next phase
Also, for the next phase, do we start listing and discussing the possible solutions we can have to solve the above issues/have the above features? I think that will be a good way to move forward, as those of us looking to design the main page in the next phase will know exactly what is expected. TheOriginalSoni (talk) 03:50, 23 June 2013 (UTC)
 * I feel like that was already done with the RFC, where for a month participants kvetched at length about the current Main Page. While the RFC is not necessarily conclusive, I think it does generally represent the variety of opinions regarding the Main Page. It should be up to individual designers to figure out how to address the various concerns. A good Main Page is one designed with a consistent UX vision, rather than one designed as a hodge-podge implementation of a set of criteria collated by committee. Harej (talk) 19:13, 2 July 2013 (UTC)
 * I think you're missing the point of TheOriginalSoni's suggestion (which I consider a good one) - being a list of the changes now intended to be implemented and an opportunity for some feedback on the proposed changes. A lot more than "a hodge-podge implementation of a set of criteria collated by committee" has been established. The RFC raised awareness of serious concerns. Perhaps you should re-read it and acquaint yourself with issues raised. These can be found between wish lists for cool features. "A consistent UX vision" doesn't equal a good UX vision unless it has established who the 'user' is and what could be detrimental to their experience. I feel you're being dismissive of the construction process and constructive input for those who will actually be redesigning without taking it on as a unilateral decision. It's moved past the "kvetching" to phase two. --Iryna Harpy (talk) 23:28, 2 July 2013 (UTC)

Any next phase should implement the fact that Athena will eventually be the interface (it might happen tomorrow, or ten years from now), so if we could tailor it to that, it might be a good idea. Kevin Rutherford (talk) 21:05, 5 July 2013 (UTC)
 * As a point of interest, could you provide some sort of indicator as the the backwards compatibility of the Athena interface, Kevin? Thanks in advance. --Iryna Harpy (talk) 00:17, 7 July 2013 (UTC)

Chinese main
Hi. Did you see the main page of the chinese wikipedia : 首页, that be updated in may after a redesign proposal start in 2012, which was very influenced by the redesign proposal of 2012 of wp:en.

Their precedent main page was : that (terrible thing), and that before 2010 (wp:en like).

Their version is perhaps not perfect, but I like many things : the header (perhaps a little too big), the footer, the border less left section. --Nouill (talk) 02:31, 20 July 2013 (UTC)

My proposal
I believe the main page of Wikipedia could be make a great deal bolder with a couple of small changes. The top boxes (In the News) and (Today's Featured Article} are not bold enough - the headings should be in BOLD and ALL-CAPS and the typeface should be at least 2 points larger, with the blue news headlines possibly flashing or just scrolling along the top of the page in the manner of a news ticker, also there should be a much larger image on the page, and the font is a bit square, should be replaced for something a bit more fun. I think this would get more people keen to view more parts of the site. Horatio Snickers (talk) 19:29, 5 August 2013 (UTC)
 * Oh, please, no flashing or scrolling. That was done to death early in the piece with web development. It really is irritating & distracting rather than "fun" [sic]. Bold and all-caps I can take on as being reasonable suggestions, but epileptic fits & motion sickness aren't appealing. Quite seriously, there's a reason the blink tag should not be used, and you'll find it here in Wikipedia. --Iryna Harpy (talk) 23:02, 5 August 2013 (UTC)

My proposal
Hi if you go to http://simple-random-wikisaur.tk the page was redisgn of simple wikipedia but like that but with the content from en wikipedia 109.144.229.214 (talk) 17:00, 12 August 2013 (UTC)

Basic framework
It has been too quiet, so let me kickstart the next phase by submitting my proposal.

In order to to have the main page be able to accomodate many criteria, it will need to be flexible and modular. That way, content and design can be separated. This allows for content and design criteria to be indepedent of eachother. To that end, I have been working "in secret" on a version of the main page with flexibility in mind. It's core features are:


 * 1) Inline styling is moved to file-based styling. This saves bandwith, and allows 'excitement'!
 * A bug will need to be filed requesting that MediaWiki loads the CSS for the main page from MediaWiki:Main Page.css.
 * 1) The page is based on (floating) divs; no more tables. Tables hugely restrict content flexibility.
 * 2) Moving content only requires moving two lines to its proper place.

Here are some working examples:
 * Here's my framework [//en.wikipedia.org/w/index.php?title=User:Edokter/Main_Page unstyled.]
 * Here's the same page [//en.wikipedia.org/w/index.php?title=User:Edokter/Main_Page&oldid=568674040&withCSS=MediaWiki:User:Edokter/Main_Page.css with styling.]
 * Move the Sister Project links to the left? [//en.wikipedia.org/w/index.php?title=User:Edokter/Main_Page&oldid=568663832&withCSS=MediaWiki:User:Edokter/Main_Page.css No problem!]
 * How my draft [//en.wikipedia.org/w/index.php?title=User:Edokter/Main_Page&withCSS=MediaWiki:User:Edokter/Main_Page.css currently looks like].

I don't care if you hate the styling (not to fond of it myself actually), but that is not a problem; it can be styled independently, it can even have different styles for each section. What I want to show is how simple the main page is built, and how flexible it can be, independent from it's content.

I hope to have laid down some groundwork on which we can build. The main goal of this framework is making content and design separate and independent. That way, we can have separate and independent discussions for content and design, which will hopefully speed up the process somewhat. I also hope to be involed on the technical aspects as much as possible, implementing other people's ideas into a working main page. Thank you for your consideration. — Edokter  ( talk ) — 16:45, 15 August 2013 (UTC)


 * No response after two days? That's it... this process is officially dead. I'll just work on it by myself and boldly suprise the community in the near future then. Don't want that? Talk! — Edokter  ( talk ) — 16:17, 17 August 2013 (UTC)


 * You do realize that it took you six days to comment when I posted a proposal (Wikipedia talk:2013 main page redesign proposal), right?
 * Getting back to your proposal, your numbers are:
 * 1057 DOM Elements, 55 requests, and 2,635 KB
 * Today's Wikipedia main page come in at:
 * 927 DOM Elements, 39 requests, and 342 KB
 * Britannica.com:
 * 298 DOM Elements, 62 requests, and 833 KB
 * Google:
 * 289 DOM Elements, 11 requests, and 397 KB
 * GuyMacon.com:
 * 27 DOM Elements, 2 requests, and 4 KB
 * Your version does look better and more modern that the current main page, though.
 * Also, to make sure the test is fair, I would want to put your proposed page and a copy of Wikipedia's main page in separate subpages before I would rely on the above numbers. I suspect that the history function adds a lot of bytes. --Guy Macon (talk) 19:45, 17 August 2013 (UTC)
 * The discussion was much more lively during the RFC, with dozens of messages per day. Counting DOM elements seems a bit pointless, that only affects rendering speed. As for the number of requests and KBs; I have no control over that, because that is determined by the skin and its associated CSS/scripts, and transcluded content. Page history is not a factor. Every page here suffers those same numbers. My page at least separates the CSS, avoiding lots of duplicated inline code. Plus my CSS is working code (and loaded separately) and in now way optimized (the styling is only for demontration anyway). — Edokter  ( talk ) — 20:20, 17 August 2013 (UTC)
 * It looks crisp, don't get me wrong, but it is just a restyled version of the current design. Are we just trying to achieve a visual update, or are trying to do a content/structure update? Style is nothing without substance. I thought we had identified several important criteria that would add or at least change content on the Main Page, and this design doesn't integrate any of them. -- Nick Penguin ( contribs ) 04:02, 18 August 2013 (UTC)
 * I'll just leave this here. --Guy Macon (talk) 04:32, 18 August 2013 (UTC)
 * Your cryptic post is cryptic. Are you saying that the page is too complex as it is? The thing about Apple and Google is that the initial function is simple, but each subsequent function is extremely powerful. I don't know if we can schluff things into subpages, that might detract from the goal. -- Nick Penguin ( contribs ) 04:41, 18 August 2013 (UTC)
 * Yes, I am saying that the page is too complex as it is. Far too complex. "Wikipedia's sister projects" should be a link. "Wikipedia languages" should be a link. "In the news" should be a link. "Today's featured article" should be a sentence (less than 10 words) and a link. "On this day" should be a link. That long list of languages on the left? That should be a single link.
 * We have fallen into a newspaper mentality, where as much as possible needs to be crammed in to the front page. We are not using what makes the world wide web unique: hyperlinks. The page is crowded, complex, and redundant (on the left I see "Current Events". On the right, "In the news". Below that, "More Current Events". At the bottom "Wikinews". (Yes, I know that Wikinews isn't the same, but a first-time visitor does not.) It looks like it was designed by a committee, and the results are craptacular.
 * Yes, I am saying that the page is too complex as it is. Far too complex. "Wikipedia's sister projects" should be a link. "Wikipedia languages" should be a link. "In the news" should be a link. "Today's featured article" should be a sentence (less than 10 words) and a link. "On this day" should be a link. That long list of languages on the left? That should be a single link.
 * We have fallen into a newspaper mentality, where as much as possible needs to be crammed in to the front page. We are not using what makes the world wide web unique: hyperlinks. The page is crowded, complex, and redundant (on the left I see "Current Events". On the right, "In the news". Below that, "More Current Events". At the bottom "Wikinews". (Yes, I know that Wikinews isn't the same, but a first-time visitor does not.) It looks like it was designed by a committee, and the results are craptacular.


 * Make it clean and simple, with subpages to hold all the Wikicruft, and each subpage ("In The News", "On This Day", etc. will be able to communicate far better with an entire page instead of a corner of the main page. It will be far easier for the blind, for users in third-world countries with very slow connections, and for users with older smartphones.


 * I'll just leave this here. --Guy Macon (talk) 08:58, 18 August 2013 (UTC)


 * What I'm trying to acomplish is a flexible framework on which to build content and styling indepentently. My example is based on the current main page, but only in content and pallette. The beauty is that both can be changed without affecting eachother; it is merely a technical demonstration. I'm not suggesting we put my example on the main page, but that we build the new main page based on that framework. — Edokter  ( talk ) — 09:04, 18 August 2013 (UTC)


 * It is a clean looking framework. I don't know whether it is the subtle color choices or the rounded corners, but the style looks really nice. --Guy Macon (talk) 09:15, 18 August 2013 (UTC)


 * I was actually planning on submitting my version when the process got to the design state, but because it seems like it never did, I'll get to working on it. -- Kangaroo  powah  23:50, 18 August 2013 (UTC)


 * We're not in the actual design stage yet. My proposal is for the underlying framework, not a final design. — Edokter  ( talk ) — 07:50, 19 August 2013 (UTC)


 * Visually the underlying framework presents no problems for my viewing. Is this the structure we should be basing future designs on? -- Nick Penguin ( contribs ) 15:41, 26 August 2013 (UTC)


 * I hope so, that's why I proposed it. The current styling is just a demonstration (which I can't help tinkering with), which perhaps will trigger other designs when we get there. But this framework does allow us to have separate and concurrent discussions on content/layout and styling. If however this discussion dies (and I hope not, becuase it has been awfully quiet), I'll just keep tinkering with both aspects, and someday I may just well be very bold... — Edokter  ( talk ) — 16:21, 26 August 2013 (UTC)


 * Just so you know, I have been quiet because I like the look what you have done so far. --Guy Macon (talk) 00:39, 27 August 2013 (UTC)

In order to keep this going, I think we can safely split the two subject now. I believe the framework is pretty much fleshed out. Now let's discuss content and design. — Edokter  ( talk ) — 12:15, 1 September 2013 (UTC)

Content and layout

 * Discuss content and its layout here, i.e. What should go where?


 * We are treating Hypertext as if it were paper. When you print something on a piece of paper, you need to fit everything on that page. For example, You need to provide a full address, telephone number, and email address, not just the words "Contact Page". Compare that with the Contact Page link on the page you are reading. Click on it and look. Then look at the links for Readers, Donors, Press, etc. See how we are able to provide far more detail than is possible using paper and ink? That's how we need to design our main page; like a true HTML (HyperText Markup Language) page.


 * We don't need subtle tweaks of the horrible design philosophy we are following now. We need a new, clean front page where we respect and honor the reader enough to trust that if she is interested in Wikipedia articles about current events, she will click on the "In the news" link. Treat the readers like adults who know what they want and not like children who need to be manipulated into reading what we think is best for them.


 * Some websites get this. (*cough* *Google*) So why do we still see bloated (*cough* *Wikipedia*) pages that try to cram everything on one page (*Wikipedia* *cough*)? Marketing. Advertising. Promotion. Push. They know that, given a choice, you would like to just see the actual content of the page without third-party ads, and you would like to see concise links to other, related content rather than seeing what amounts to another ad, this time promoting that other page on the site.


 * One would think that Wikipedia would be immune to this, but we aren't. People work hard on their little corners of Wikipedia, and they want their hard work to be advertised on the main page in the "Did you know..." and "From today's featured article" bloat sections. The basic theory is that the reader is too stupid to know what she wants to see and certainly far, far too dimwitted to click on a link. No, we have to shove everything in their face. It is time for a total reboot.--Guy Macon (talk) 17:14, 1 September 2013 (UTC)


 * Not to be an argument-killer, but we're past the RFC stage now. To address your points: Having only links to the several main page projects without a sample of their content is not the way to go. Sure you get a nice clean main page, but absolutely nothing to stimultate visitors to actualy go and visit those pages. What if Goolge only presented links or titles as their search results? Imagine how that would look on their news site. I would like to know if I'm even interested before I click on a link, and therefor a sample of its content is needed.


 * Comparing Wikipedia to Google is too simple; Google's homepage has only one use: search. Wikipedia has many more besides search for an article. We also try to involve new editors. And that simply does require a bit of 'marketing'. Showcasing featured content has also been an established goal in the RFC.


 * The contact page is actually several pages linked together; that creates an immense ammount of extra overhead if such a mechanism is applied to the main page. Some form of tabbed content would be nice though, if that could be done without javascript, or otherwise has proper fallback. — Edokter  ( talk ) — 19:43, 1 September 2013 (UTC)


 * Good point. All Google does is Google Android Os, Google Blogger, Google Bookmarks, Google Books, Google Calendar, Google Chrome Os, Google Chrome Web Browser, Google Chromebook, Google Chromebox, Google Chromecast, Google Code, Google Crisis Response, Google Cultural Institute, Google Docs, Google Drive, Google Driverless Car, Google Fiber, Google Finance, Google Fonts, Google Goggles, Google+, Google Groups, Google Hotel Finder, Google Ideas, Google Keep, Google Knowledge Graph, Google Mail, Google Maps, Google Music, Google News, Google Patents, Google Picasa, Google Project Glass, Google Public DNS, Google Scholar, Google Search, Google Shopping, Google Sky, Google Sync, Google Talk, Google Trader, Google Translator, Google TV, Google Voice, Google Wallet, Google Website Optimizer, Google Wireless Access, and about 200 other things. Google needs to realize that their users are to dimwitted to find any of those unless that are "featured" on the Google main page. You want to tell them or should I? --Guy Macon (talk) 22:40, 1 September 2013 (UTC)


 * You do have to know exactly what you're looking for to reach one of those projects through their search home page. All those projects do have their own homepage. — Edokter  ( talk ) — 22:54, 1 September 2013 (UTC)

Design

 * Discuss design and styling here


 * Where exactly can I see the outcome of the RfC (if there is one)? Which are the criteria that should be applied to a proposed design for the main page? --  Toshio   Yamaguchi  13:10, 27 October 2013 (UTC)


 * See above: . — Edokter  ( talk ) — 14:42, 27 October 2013 (UTC)


 * I came up with a serious proposal (Wikipedia talk:2013 main page redesign proposal) and made a later attempt to get my point across through humor (Wikipedia talk:2013 main page redesign proposal) but found that nobody was particularly interested in discussing anything other than minor tweaks to the existing byzantine and sesquipedalian loquaciousnes. This predilection for prolix exposition and visual sonorities too pleonastic to be expeditiously assimilated notwithstanding the availability of far more comprehensible albeit diminutive alternatives profundicates me greatly. --Guy Macon (talk) 16:44, 27 October 2013 (UTC)
 * Actually, I'm interested in an entirely new look for Wikipedia's front page. I agree that the current approach is stodgy and inappropriate for 2013. A better main page works on all platforms, is light, and presents information clearly and beautifully. I am interested in working on a proposal but I'm currently very busy. As soon as I have some spare time I'd be interested in getting a design draft up, using the RFC outcomes to guide me. Harej (talk) 23:35, 27 October 2013 (UTC)
 * Are you suggesting that Guy's proposal doesn't "present information clearly and beautifully"? It's clean, clear and doesn't look like a clumpy late 90's/early 2000s attempt at looking 'interesting' by using 'pretty' coloured boxes and byte heavy jpegs that are usually completely meaningless and smack of, "I just got Photoshop 4 and I'm really, really excited!" Sorry, Harej, I'm sure you have excellent intentions but, having been a web designer since the early 90's (you know, when you wrote your own html and looooong before unicode was stable), experience has taught me that simple is usually better. You can spend inordinate amounts of time working on being incredibly clever in order to make it a wizz-bang impressive site or an intuitive and clean approach with a lot more going on behind the scenes than you'd expect. Looks good; seems to work on all browsers; tried on various OS's, etc... but when you road test it IRL you suddenly discover that you didn't reinvent the wheel and the vehicle's just sitting on the asphalt (I LOVE bad analogies!). Unless you stick to absolute fundamentals, the next big thing becomes old and obsolete very quickly (and probably not even supported by the next generation of browsers). --Iryna Harpy (talk) 01:13, 28 October 2013 (UTC)
 * Iryna, I was not referring to Guy Macon's proposal. I was referring to the current main page. I was agreeing with Guy that what we need is a whole new design, not just a variation of what we have on Main Page right now. Harej (talk) 16:24, 28 October 2013 (UTC)
 * See also the Sep15-Oct6 discussion at Talk:Main Page/Archive 177. I'm still of the opinion that I left near the end of that thread (agreement with the idea of incremental change) - first update the architecture, then update the content/ordering, then (and only then) start investigating aesthetic changes - cross-browser compatibility, and http://www.csszengarden.com/ looks/functionality should be achievable, if the architecture and content-blocks are done right. –Quiddity (talk) 05:53, 28 October 2013 (UTC)
 * With my proposed design, no architecture is needed. You can achieve it using only elements found in 1995's HTML 2.0 and using the user's default CSS stylesheet. (I would recommend a minimal stylesheet designed to keep the look consistent across platforms, but the CSS doesn't need to be bloated either.) I believe that if you gave the users a choice between a lightweight main page and any version of the mainpage that has a lot of content, 90% plus of the users would choose the fast-loading version with no styling, no scripting, and minimal graphics. --Guy Macon (talk) 22:12, 28 October 2013 (UTC)
 * That's taking separatism to the very limit! I'm not sure I'd agree that a majority (let alone 90%) of users would prefer to have to click multiple times in order to see the various (updated daily) content blocks that are currently all available in a single location.
 * I can relate to the attraction to simple aesthetics (I'm not a fan of rounded corners and gradients and other superfluous stylistic flourishes - they distract from the content, and (if imperfectly done, or on imperfect platforms) take additional time to render), but I think that retaining most of the existing content-blocks in a single location is a must-have. Eg, Main Page alternative (simple layout) (c.2004) vs Main Page alternative (links only) (c.2006) vs User:Guy Macon/Simple Main Page (c.2013). Of those three, I can only forsee #1 being hypothetically accepted by a future !vote between them...
 * Some people like tabs, some people like subpages, some people like collapsed/hidden content, some people like everything in one. Different options make more or less sense in different circumstances. Eg. WP:MILHIST or Portal:Politics. If only we could A/B test the universe, and see whether more people read the subpage/tabbed versions, or if merging it all into a well-organized single page was better! :) –Quiddity (talk) 01:40, 29 October 2013 (UTC)


 * You seem to have overlooked my take on the simplicity of Guy's presentation. I made a point of how quickly even simple CSS tricks such as tabs, tooltips, hovering text dependent on div alignment, etc. become obsolete very, very quickly. Newer browsers which once supported the nifty stuff simply don't do so within a couple of generation. In fact, if you bother to check what you're developing while you're even in the process of development (which I used to do in a roomful of computers on different platforms, OS's, a myriad of browsers and user resolution preferences, ad nauseum, you'll find that anything beyond absolutely straight forward ends up as an unsightly and incoherent mess and, of the myriad of browsers available, a substantial number won't recognise your recognise or display your CSS in the first place). A basic html page deploying the minimum CSS (which defers to the user's CSS as the preference: call me crazy but accessibility and size does matter) is, quite simply, the best judgement call. Wikipedia is, essentially, text-based. Wikipedia is not competing with commercial social sites. Wikipedia does not need to compromise accessibility in order to accommodate and attract advertising. Some people like and others like doesn't come into the equation. This shouldn't be about trying to accommodate quirks and convolutions but the KISS (Keep it simple, stupid) principle. It's an entry page, not a circus. --Iryna Harpy (talk) 03:32, 29 October 2013 (UTC)
 * As a P.S. your preference (Main Page alternative (simple layout)) is the most irritating and does not adapt well to various resolutions and, for that matter, androids and the many different methods of internet access now being used. Main Page alternative (links only) is minimalism taken to the extreme, although it makes for a nice example of pedestrian postmodernist art. --Iryna Harpy (talk) 03:49, 29 October 2013 (UTC)
 * I wonder if my simple mainpage is one of those proposals where you can't find anyone who personally dislikes it, but there are plenty of people who believe that other people will dislike it... — Preceding unsigned comment added by Guy Macon (talk • contribs) 04:26, 29 October 2013‎ (UTC)
 * @Iryna Harpy: I'm an active participant in WP:WPACCESS, and fully agree that simple and valid HTML is the route to happiness. My comments to Guy were only in disagreement about the content and where it all lives...
 * @Guy: I really dislike clicking multiple times! In your version, I have to either click ten times (forward/back), or open five new tabs, in order to see the daily content. In the current mainpage, I just scroll and read.
 * @Iryna Harpy: If you were referring to my earlier comment about csszengarden, I wasn't pointing enthusiastically at the whizbang css/javascript that some of the design-variants there use - I was pointing earnestly at the valid HTML that underlies the entire premise.
 * Re: "Main Page alternative (simple layout)" - it has zero layout, that was my point. All it does is transclude the content-blocks (scroll down to see). No frills or design. None at all! –Quiddity (talk) 05:46, 29 October 2013 (UTC)
 * I have been thinking about your "I really dislike clicking multiple times" comment. Of course you can always create a page in userspace that transcludes whatever pages you prefer into one big page, but that is a lot of work. How about this: we create a wizard that automagically creates such a page, allowing either full custom or a selection menu with options for "just like the present mainpage", "just policy proposals", "Just abuse noticeboards" etc. That would be worth having around no matter what we do with the main page. --Guy Macon (talk) 10:28, 29 October 2013 (UTC)
 * Some editors use their userpages in this way (ie. transcluding: the content blocks that the main page uses, or various sections of Dashboard, and Article alerts), and I agree that a way for users to customize their userpage more easily would be helpful, especially for newcomers. There are some ideas and tentative plans in that direction, but I can't find the link. All we've had for the past few years is the slightly terrifying (overwhelming) and getting outdated User page design center, which could really use some more caretakers (especially those with more plain aesthetic tastes). –Quiddity (talk) 02:07, 3 November 2013 (UTC)
 * @, my apologies for taking so (seriously) long to respond as I was caught up in a plethora of fair dinkum Wikipedia messes I couldn't relegate to the backburner. I'm sorry that my comments read as being disparaging however, I did look at the source of your proposal and got a sense of what you are/were trying to accomplish. While I can appreciate your intent as regards delivery, it doesn't translate well in practice per your example. Unfortunately, there's many a slip between the theory and the design reality. @, I hope you didn't misunderstand. I actually like your proposed layout: it's simple and to the point. --Iryna Harpy (talk) 02:40, 29 November 2013 (UTC)
 * Agreed, and also no offence was taken. :)
 * Also, I did find the project to create a "way for users to customize their userpage more easily", GlobalProfile/design, and commented there just this morning! Sadly it hasn't seen much activity since 2011, but there are a few potentially great ideas in there. As with this page - inch-by-inch we get closer to solidity.–Quiddity (talk) 04:12, 29 November 2013 (UTC)
 * Ah, interesting. I've put it on my watchlist and will take a look at it next time I swan around WM (which I haven't done much of since their Privacy Policy child (... er, reader) friendly. Sadly, serious overhauls of the entry page are going to be scrutinized by those who were inducted into the world of cyberspace more recently and just adore gimmickry, ignoring the logic of WC3's aims. The fun of Wikipedia is, to my way of thinking, in the fantastic content to be discovered. Working on the premise that it's a commercial concern and should, therefore, reflect snazzy commercial design is counterproductive. The tortoise approach may be arduous but will, eventually, win the race. Here's to the hard plod ahead! --Iryna Harpy (talk) 04:45, 29 November 2013 (UTC)


 * This is clearly a content related discussion. A reminder; this section is for discussing design. — Edokter  ( talk ) — 18:45, 29 October 2013 (UTC)
 * As it turns out, the two are inextricably linked. Design ultimately depends on what content you're trying to present. The question is if there is consensus for a simple, Google-style home page. My own opinion is that Wikipedia's home page should at least attempt to promote content discovery (a legitimate concept, even in the era of minimalist home pages), even if the current implementation of this is excessive and/or broken and/or some other negative adjective. The RFC, as far as I can remember (I will have to double-check), was heading more in the direction of trimming *some* of the content offerings; some people were even recommending adding new content sections. Either way, I'm not sure there is strong support for a search box-only main page, but I do recognize it as a valid idea (even if I do not agree with it). Harej (talk) 22:21, 30 October 2013 (UTC)
 * What if there was a way that people could add and remove elements, like how Google News lets you? That would certainly catapault the main page into the modern era. We would have a base design (like how it looks now, maybe) but it would allow people to add or remove the content as they choose. -- Nick Penguin ( contribs ) 02:24, 3 November 2013 (UTC)
 * It's certainly a cool idea but I don't know if MediaWiki supports that kind of modularity. Harej (talk) 23:21, 3 November 2013 (UTC)

My proposal
The talkpage of the main page got archived so I'm copying my proposal from there to here. I presented a much more detailed version before without getting any feedback so I'm putting something much shorter.


 * My personal proposal (which I suggested numerous times before) is to make the main page more like a newspaper without focusing on news: we have sections on politics, math, science, arts, sports, etc. Just like newspaper site, we can let a relevant Wikipedia project to manage a section; for example, Wikipedia project math can decide what to put on the math section; e.g., maybe newly improved article.

-- Taku (talk) 12:10, 3 November 2013 (UTC)

A modest Proposal...
Why not just copy the excellent[Citation Needed] work done at http://www.osunrise.com/ ?

It's like the current Wikipedia main page, but more so. :) --Guy Macon (talk) 05:54, 4 July 2013 (UTC)


 * Why not? Who do you think the Wikipedia target audience are? That's the most irritating, unnavigable page bar none[Citation Needed]. It's like android kiddie heaven, only more so. I've just developed a migraine looking at it for more than 10 seconds. --Iryna Harpy (talk) 06:42, 4 July 2013 (UTC)


 * I have seen worse.


 * There is, however, one page that you have to experience to truly grasp the Zen of website design: The Afterlife.


 * Note that you can only scroll with the up and down keys -- no scrollbar. And you really do need to scroll, because it tells a story from top to bottom. An utterly batshit crazy story. --Guy Macon (talk) 07:55, 4 July 2013 (UTC)


 * Batshit crazy, you say. You seem to be able to read what appeals to me like a book! --Iryna Harpy (talk) 22:12, 4 July 2013 (UTC)
 * P.S. Zen, eh? I'm in one mind as to my thought on the proposal. One man's Wikipedia heaven is another's Wikipedia hell. --Iryna Harpy (talk) 00:27, 7 July 2013 (UTC)

User:Guy Macon/Simple Main Page
In my opinion, if we put up my proposal ([User:Guy Macon/Simple Main Page]]) for comment it has a reasonable chance of gaining consensus. Now I could simply post an RfC, but fragmenting the discussion is undesirable. Instead, I want to do the following:
 * 1) Ask for help tweaking my content without losing the simplicity.
 * 2) Reach consensus that my proposal, unchanged, should be part of step 4 (Mockup review) at 2013 main page redesign proposal.
 * 3) Profit!
 * 1) Profit!

Here is my proposal:

--Guy Macon (talk) 13:00, 29 November 2013 (UTC)

Status as of February 2014?
What's the status of this endeavor? The subject-space page currently says "Develop design criteria and guidelines: In progress". Is this still accurate? --MZMcBride (talk) 05:25, 27 February 2014 (UTC)
 * See: 2014 main page redesign proposal. Harej (talk) 05:27, 27 February 2014 (UTC)
 * It's dead for now. Still trying to figure out a process to get things going again. The 2014 "proposal" was bound to fail before it even started. — Edokter  ( talk ) — 13:08, 27 February 2014 (UTC)
 * Oh, well. Best of luck on that. Does anyone ever feel that IP's should only be allowed to request changes on talk pages? I swear the community would be able to get on with some of these outstanding issues if so much time & energy wasn't focussed on cleaning up after vandals and POV pushers... --Iryna Harpy (talk) 02:55, 28 February 2014 (UTC)
 * Yes, plenty of people feel that way. See PEREN. But why do you thing logged-in users can't be vandals or POV pushers? -- Ypnypn (talk) 03:04, 28 February 2014 (UTC)
 * Of course they can. I wouldn't argue against the fact that there are already more than enough POV pushers here already. I'm just getting of sick of certain users who were blocked years ago, but are still present and running the gamut of IP hopping and being disruptive for the sake of tying up those they consider their 'enemies' with reverts rather than developing articles. Evasion would be far more difficult if they had to use up their finite store of email accounts and go through the process of creating more, plus having to set up another user account. Slowing down the process certainly does put a damper on that kind of enthusiasm.


 * Naturally, I am aware of the argument for account only access having come up before and, on balance, I have to agree that it possibly wouldn't make that much impact and may be considered contrary to the spirit of this resource... but I'd still like to see what would happen if it was given a one month trial. --Iryna Harpy (talk) 03:33, 28 February 2014 (UTC)
 * Should this talk page move to Wikipedia talk:2014 main page redesign proposal?--Byfserag (talk) 08:34, 1 March 2014 (UTC)
 * Eventually, yes. — Edokter  ( talk ) — 11:22, 1 March 2014 (UTC)