To see the project page with styling, use this link, or enable the "Show the new version of the Main Page currently under development" gadget under the Testing and development section in your preferences. Please share your ideas, and what you like and dislike about the design, on this talk page. Thank you.
For the current main page, see Main Page (talk).
For ten years now, the English Wikipedia has greeted its readers with the same Main Page. Back in 2006, when HTML3 and CSS1 were cutting edge, it looked fresh and modern. Today, it is very out of date, using obsolete markup and riddled with accessibility issues. That is because tables are the main method used for layout, and even back in 2006, that was frowned upon, but there was no better alternative for static layout.
Back then, screen resolutions tended to only grow. But today, web pages are displayed on a large scale of resolutions, from small mobile devices to large desktop PCs. This necessitates the use of responsive design that will fit any screen. With that in mind, the tables will have to go and make place for current technologies and standards. The 2016 redesign (which started in 2013) incorporates these methods, while still maintaining some backward compatibility for older browsers, to allow the Main Page to display on any device without the pitfalls currently imposed by the current design. The new design is responsive and will adapt to any viewport size (up to a reasonable margins).
It employs some recent technologies in CSS and HTML that were created just to address these issues, namely the flexbox model combined with media queries. It also incorporates the floating box model to maintain some backward compatibility and graceful fallback for older browsers. However, most modern browsers in use already support the flexbox model for some time now, so the share of older browsers using the fallback is negligible.
The content of the main page is still governed, maintained and generated through its core templates. Some of them will need some updating as these still use tables as well (notably Picture of the Day). The main goal of this endeavour is to change the underlying framework; to replace the tables with the flexbox model, and separate the styling (now inline) from the layout. This allows for flexible and quick adaptation of styling when so required.
The new styling itself is kept minimal, but brought up to current standards. No more colored backgrounds and a clear distinction between the several sections, while maintaining a coherent look and feel. Combined with the flexbox model, the new design will bring the Main Page of the English Wikipedia out of the HTML middle ages and make it accessible to a multitude of devices that currently cannot access the Main Page without excessive sideways scrolling.
Key improvements
No more rigid tables used for layout
Utilizes Flexbox model and media queries for a responsive design
Some backward compatibility maintained using floating box model
Separates the layout from the styling by moving style-related CSS to external stylesheet
Easy to maintain, as most inline (styling) CSS is removed, and sections clearly marked
Fresh look. Moves Wikipedia back to today!
Structure
The skeleton lists all the components used to build the main page
OK, so we have...not exactly a consensus but a number of editors who feel that something should be done about the main page. So (for those still interested) I would like to open up a discussion about what process has the best chance of accomplishing this in a way that the community will accept.
Right now, at the start of this new restarted discussion, I would politely ask everyone to refrain from suggesting what should be done, but rather the process that should be followed. Once we settle that, we can get to suggesting and opposing specific changes. I would also suggest not bothering to tell us all that this isn't worth discussing, on the theory that the best way to stop taking about something is to stop talking about it.
So, other than the "one person decides and makes the changes with or without community support" plan, which we have already rejected, does anyone have a plan or suggested process that could possibly move us forward? --Guy Macon (talk) 00:10, 7 July 2016 (UTC)[reply]
I think this was mentioned by someone- but it seems clear that redesigning the whole MP at once is an unattainable goal that will never achieve consensus. There are simply too many things that could be changed and too many views on how to change them(if at all). The process needs to be gradual- changing one thing at a time; it is easier to gain consensus on one aspect of something than rolling many aspects into one proposal. 331dot (talk) 00:52, 7 July 2016 (UTC)[reply]
What [part of "Right now, at the start of this new restarted discussion, I would politely ask everyone to refrain from suggesting what should be done, but rather the process that should be followed. Once we settle that, we can get to suggesting and opposing specific changes" was unclear? --Guy Macon (talk) 03:01, 7 July 2016 (UTC)[reply]
I'm not sure if you're suggesting this, but I don't think any redesign should be implemented without an RfC and consensus on the subject. If it isn't controversial then the RfC will pass it. Dionysodorus (talk) 01:11, 7 July 2016 (UTC)[reply]
Looks too white for me. If the main thing is the coding, then make it look identical to current main page and once implemented discuss design. Cas Liber (talk·contribs) 02:18, 7 July 2016 (UTC)[reply]
I wasn't meaning to imply that it should be implemented sans-RfC, only that it could. A question: should there be an RfC on "Main Page2" first, and then an RfC of the nature that I proposed above (get the problematic code out of the way first, then discuss visual design), or should it be lumped in with the others (less likely to lead to a major visual change)? Eman235/talk02:28, 7 July 2016 (UTC)[reply]
If this is about the process, I think the proposal @Nihiltres: suggested in this thread was a reasonable one. If I may quote it:
In particular, I suggest separating the modernization into five parts:
A procedural agreement for settling the remaining items. No consensus = no change, so agreeing on a process is the first part. Following that…
A technical upgrade, incorporating the structural changes and layout-specific CSS upgrades, but no unnecessary visual or content changes. This would be agreed upon by a simple support/oppose poll; failure to reach consensus on the technical changes nixes the rest of the process. Therefore, seriously, make a version with the new layout that uses more or less the tired 2006 look for each box, and no changes in included content. It'll be temporary, and as a first agreed-upon change it'll strongly help precipitate others.
A visual upgrade, incorporating whatever gradients, background images, borders, etc., to be the subject of its own RfC and ultimately settled through one or more ranked-voting polls (we could ask the Foundation to set that up for us), to get us past the bikeshed problem.
A content upgrade, with an RfC for the addition, removal, or relocation of specific boxes of content. The RfC would be in two parts: suggesting changes, and then voting on them (with, perhaps, 60% approval to change the status quo, or simple majority for mutually-exclusive suggestions).
Implementation of all the agreed-upon changes in a single update to the Main Page. We don't want to needlessly taunt readers with incremental updates.
I don't have anything myself to add, but this seems most reasonable to me. (Ah! I apologize Nihiltres if I stepped on your toes by mentioning it first?) ~Cheers, TenTonParasol02:32, 7 July 2016 (UTC)[reply]
I suppose I can't help but endorse this, right? :) There is the downside that it inhibits the suggestion of dramatic changes to the Main Page, but those have always been politically unlikely. {{Nihiltres |talk |edits}}04:40, 7 July 2016 (UTC)[reply]
I worry that bundling the technical upgrade with the decorative, content, and layout changes could cause users affected by the technical upgrade to be overlooked. If the technical upgrade is rolled out first, separately, relatively few users would notice it, especially users with screen readers or exotic browsers. Feedback on accessibility and technical issues from those users could be heard and addressed, before the other changes happen and many more users start weighing in. Matt Fitzpatrick (talk) 09:17, 7 July 2016 (UTC)[reply]
Ah, I seem to have overinterpreted step 2. I agree with you then; I'd prefer for step 2 to be deployed first, separately from any other changes, since it does not depend on any other consensus agreements. isaacl (talk) 22:34, 7 July 2016 (UTC)[reply]
@Matt Fitzpatrick and Isaacl: By "technical" I mainly meant "layout", i.e. the HTML and (core) CSS that scales and positions each content box on the page. Improving this system will require some visual changes, because part of the point of it as an upgrade is to make the content reflow naturally for various screen/window sizes. In particular, our current Main Page flows in two columns, with two items vertically in each column (followed by a couple of full-width items); the continuous columns, at least, are incompatible with reflowing the content for narrow screens, since we probably couldn't keep the same continuous boxes without either re-arranging the content (i.e. swapping DYK and ITN) or doing something hackish (defeats the purpose). That said, step 2 specifically isolates the technical/layout side so that we don't have to argue over appearances until we've agreed the basic layout makes sense. {{Nihiltres |talk |edits}}23:52, 7 July 2016 (UTC)[reply]
Several of the improvements I've seen in the suggested final designs would be invisible to most users. Replacing tables with semantic elements, marking up regions, removing inline styles, closing the list gap at the top, stuff like that. Maybe those could be step one-and-a-half. Matt Fitzpatrick (talk) 02:53, 8 July 2016 (UTC)[reply]
I am not invested, and never have been invested in anything to do with this design issue but here's a thought, FWIW. The committee of the whole is again likely to go nowhere, so here's a suggestion: 1)A widely advertised vote for an up-to-7 member design ctte is elected (any user in good standing may self-nom and state their qualifications (10 days) vote (30 days), one of the choices is 'none of the above/status quo'; 2)They are instructed to come up with 1 to 2 complete redesigns and/or 1 to 2 partial redesigns; 3) Their proposal(s) are put to the community, and status quo is again an option; 4) no consensus means no change. Alanscottwalker (talk) 19:51, 7 July 2016 (UTC)[reply]
Thanks for pointing me to that. Well, good luck, but my idea does have, unlike that terse RfC that I now reviewed, regular community input/approval, at several stages. Alanscottwalker (talk) 00:12, 8 July 2016 (UTC)[reply]
If the next step would be to restore the current version, which as far as I can tell, already mimics the current main page, then I'm not sure it's necessary. isaacl (talk) 12:25, 7 July 2016 (UTC)[reply]
I don't think that is the goal. Just that it shouldn't pull anything at all from the main page CSS, since we want it to be fully customizable without affecting the main page. For what its worth, go ahead, I support this. We need a wider involvement here if we are going to have any chance of changing the main page.Carl Fredrik 💌📧13:39, 7 July 2016 (UTC)[reply]
I don't have an issue with ensuring independence from the current main page CSS file, but I don't see a need for a step zero that makes this page have the same wikitext markup as the current main page. The current main page can serve as a reference without having to change this page. isaacl (talk) 22:28, 7 July 2016 (UTC)[reply]
Start an RfC at WP:VPP stating clearly how this is an improvement to the current main page, how this is only the first step so we can separate the issues of code and visual styling, etc., etc. The objective would be to get the recoded main page accepted as the actual main page.
If the RfC is widely supported (which it would probably be), continue with step 3 on the above list.
Tweaking the draft content to remove the "Be an editor" section (at least temporarily, to keep issues separate)
Drafting an RfC plan flowing through each step so that we can easily point to so that people who haven't been involved can clearly see and comment on the plan
I think that the two (or few?) of us should just go ahead with drafting a plan to make sure we get the ball rolling, since it's so easy for it to stall out before getting properly started. Importantly, I think that we should have the Plan™ clearly visible throughout so that any objections to its main thrust happen early.
That said, I think we've got the basic idea down, and here's a new draft of the Plan™ (feel free to copy this to its own section for editing):
Edit and agree on the basic Plan™ in our tiny Main Page Cabal ;) with the option of tweaking it later
Tweak the draft to get the content closer to the current Main Page
An RfC pointing to a) the Plan™ and b) a viable Main Page draft, asking "Is this layout (and only the basic layout) an improvement?" If this fails, we end there.
A preflight request to the WMF for a ranked-voting poll to identify the most preferred CSS
A call for CSS to populate the poll, with interested users posting CSS to style the basic layout. (and maybe an open discussion on preferred style elements?)
Running the poll
An RfC on content additions/removals from the Main Page. We'll probably want to establish both a quorum and support-percentage thresholds for implementation.
Protect the draft and finalize any details
A simple vote on implementing the final version
Implementation and cheers all around
Probably each of those steps will have long waiting periods for participation, so we'll want to keep this rolling; how's it looking so far? {{Nihiltres |talk |edits}}22:36, 13 July 2016 (UTC)[reply]
I noticed this got the historical tag, which kinda makes sense since it's named 2016 redesign. But on the other hand this is still ongoing, right? If not, what happend/what needs to happen for this to move forward? Most seemed fine with the process suggested above, but maybe (probably) I overlooked something. Max Nordlund (talk) 03:15, 25 December 2016 (UTC)[reply]
Reading back the talk page, the project certainly does look dead. I didn't even know it stalled since I was using this version of main page itself very well. Too bad this would never go official. Junghyeon Park (talk) 13:56, 27 December 2016 (UTC)[reply]
Sanskrit Wikipedia looking for techies for their home page
Hello there. I have an unusual request for you, and apologies if you've already seen it elsewhere.
Looks like the Sanskrit Wikipedia would like to have their home page compatible with mobile devices, because they are widely used to access that site. Unfortunately, past attempts to fix the issue didn't work. Is anyone willing to help them? User:NehalDaveND speaks English and could assist you! Thanks, --Elitre (WMF) (talk) 15:41, 22 September 2016 (UTC)[reply]
My feedback, in case anyone is still paying attention to this
I like the looks of this design without the styling applied. The box to enable styling pushes things down a little farther than I'd like, I assume that would be removed when implemented (perhaps with a with/without choice in your login or something). --Khajidha (talk) 15:54, 24 March 2017 (UTC)[reply]
I personally dislike the new redesign, as I view it to be less clean and more confusing. I feel that, if a revision is to be made to the main page, it should be more drastic than this, rather than a rehash (and in my view not a particularly clean one). Has anyone considered a style similar to the YouTube main page, with Wikimedia Commons images giving a clear indication of popular and suggested articles. Then, where the bar to the left of the main YouTube page is, we could input news and on this day. A direct link to the Wikipedia:Top 25 Report on the main page would also be nice in my view. --User:Stormy clouds (talk) 10:07 27 April 2017 (UTC)
@Stormy clouds: I still have this on my watchlist, sigh. The difficulty in Main Page updates isn't creative but rather political, i.e. getting everyone on board with any given design. No offense, but suggesting more designs is unhelpful because it inhibits consensus on any existing design. If I were to revive this discussion (as a new 2017 one), my opening strategy for making the discussion productive would be to preempt suggestion proliferation through structuring the discussion around specific, relatively atomic structural changes. {{Nihiltres |talk |edits}}21:40, 27 April 2017 (UTC)[reply]
@Nihiltres: Agreed! As many people have said over the last few attempts, we should first get the current design ported into pure CSS with as few changes as possible (we're still using tables for layouts ;_; in 2016!), and only then attempt a series of small improvement discussions in order to get relatively close to this 2016 design. Quiddity (talk) 03:54, 9 June 2017 (UTC)[reply]
I think it is pretty good overall, with one serious issue: the forced whitespace between the sidebar and the content: blech! Content width should not be capped at a specific pixel size! — xaosfluxTalk22:26, 27 April 2017 (UTC)[reply]Too much whitespace!
Minor note, that it has a narrower breakpoint with monobook vs vector, due to the decreased font-size, hence this problem wasn't initially visible for me even with a 1920x1080 resolution. Compare vector with monobook. (Or for anyone who has a narrower monitor: zoom out (decrease browser font size) until the fixed-width becomes visible)
(Sidenote 1: I made this wireframe idea a while ago, to help start discussion about what should be in a hypothetical and minimal "accessibility and aesthetics" options-system-for-everyone (i.e. including logged-out readers/editors) which includes this feature).
