Wikipedia talk:2008 main page redesign proposal/Cacycle

Note: For correct resizing of the picture of the day the following css code has to be added to the site's css or your User:Username/monobook.css page:

.POTD img { width: 100%; height: auto; }

For optimal resizing results for the picture of the day it will additionally require some site javascript code to load a correctly sized image.

For this design demo I have put the focus on making the main page simple and clear. For that I have made the following changes:

Removed elements that I think are rarely used by the average visitor such as the sister project section and some navigation links (all this content is still available through links on the page)
Removed redundant elements such as the interwiki section
Removed excessive linking to articles when it was distracting, confusing, or not necessary such as in the Current Events or the title sections
Replaced bold links and n-dashes that gave the page a busy look
I actually like the Did you know section, but I had to replace it with a link in order to keep the main page simple and clear
Shortened the Featured Article and Featured Media texts
Added a prominent search field - the single most important navigation element! - where an average or new user finds it intuitively

This is currently just a static demonstration that I have quickly hacked together, it would require formatting and style changes for the section templates. This demo might also miss some functionality that could be implemented later. Cacycle (talk) 08:02, 14 December 2008 (UTC)[reply]

Question

Are we allowed to make comments here, or is that somewhere else? Either way, the image is clean and texty and reminds me of the old Encarta CDs. That's the one thing I don't like it doesn't have that Web 2.0 feel that everywhere else has already migrated to. (Not other designs, but other high-traffic websites) It does look nice though, and compared to some of the other designs I'd put it towards the top; but that's just my taste. Thanks for reading my ramblings. §hep • ¡Talk to me! 11:09, 14 December 2008 (UTC)[reply]

I agree. Kudos for simplicity but readers are expecting more color, more pinache. That, and if the DYK crowd's opposition to adding GAs is any yardstick, they'll never let this pass.--HereToHelp ^{(talk to me)} 14:00, 14 December 2008 (UTC)[reply]

All and foremost, readers want a page that that is usable. Giving the featured media such a prominent place (top right, full column width) together with more white space was supposed to gives the layout a balance against the textiness from which the current main page and the current proposal so much suffer. Cacycle (talk) 17:59, 14 December 2008 (UTC)[reply]

There's also the niggling matter of essentially breaking the page at the 800x600 resolution... —David Levy 14:07, 14 December 2008 (UTC)[reply]

See below for a screenshot with the layout should scale nicely for 800x600. It scales without breaking at even much lower screen resolutions. Cacycle (talk) 17:49, 14 December 2008 (UTC)[reply]

The page still looks broken to me (per my below reply). —David Levy 20:16, 14 December 2008 (UTC)[reply]

Yes, 2 — 3 words per line does not qualify as scaling nicely. It's unreadable. Pretzels^Talk! 03:10, 15 December 2008 (UTC)[reply]

I have addressed this issue, please see below. Cacycle (talk) 04:15, 15 December 2008 (UTC)[reply]

The left-justified version doesn't look quite as bad, but the columns remain far too narrow. With three columns, there simply isn't a way around that. —David Levy 04:42, 15 December 2008 (UTC)[reply]

Redundant search field

Are you unfamiliar with the reasons behind the decision to omit this (each of the numerous times that it's been proposed), or do you simply disagree with them? —David Levy 12:02, 14 December 2008 (UTC)[reply]

I am familiar with the discussion about the search field and I have commented on that early on. I have a very strong opinion on it: The search field is the single most important navigation element that Wikipedia has. On our main portal it must be placed in the most prominent place that we have, which is next to the logo on top of the page. Only here will a casual reader find the field intuitively. I do not see any problems at all with having our standard search field in addition to that - again, this is the most important and most powerful element! Cacycle (talk) 18:10, 14 December 2008 (UTC)[reply]

To reiterate the arguments with which you say you're familiar, many of us believe that this would be a disservice to our readers, as it would draw their attention away from the standard search field to one that would vanish after a single search. Then they'd become frustrated and mistakenly believe that they had to return to the main page for every subsequent search. And even if they were to notice the standard search field at some point, they might be confused regarding what the difference is (and therefore continue using the one to which they'd grown accustomed).

There's also the fact that your redundant search field would appear directly below the standard search field in one skin and below/across from it in another.

Regardless, this has been very heavily discussed, and it's clear that there is no consensus for such an addition (and probably more opposition than support). I would have felt better about its inclusion here if you'd told me that you weren't aware of this fact. —David Levy 20:16, 14 December 2008 (UTC)[reply]

For me these arguments of possible reader confusion seem to lack any objective evidence. The search fields should be close to the respective logos where readers intuitively expect them and find them without actively searching around. Also, it is not always possible to discuss elements out of the context of their layout context. In the current proposal there is a very prominent title logo as an eye catcher that demands its own search field more so than the much smaller Wikipedia title logos in other layout proposals. Cacycle 20:57, 14 December 2008

1. Please explain how the redundant search field would significantly aid readers. It would make their first search (assuming that they're starting at the main page) easy, but then what? What do you expect them to do after that?

Irrespective of the ease (or lack thereof) with which users are able to locate the standard search field, do you disagree that it's important that they do? Do you disagree with the assertion that drawing them to your added search field would reduce the likelihood that they'd notice the standard one?

2. You say that your design includes "a very prominent title logo as an eye catcher that demands its own search field more so than the much smaller Wikipedia title logos in other layout proposals." Well, that's a problem. We want readers to be drawn to the standard interface, not to "an eye catcher" that disappears as soon as they leave the page.

3. You haven't addressed the skin issue. —David Levy 21:24, 14 December 2008 (UTC)[reply]

I await your reply. —David Levy 17:17, 15 December 2008 (UTC)[reply]

I think I was pretty clear on this: I think your argument of reader confusion is completely made-up and is not supported by any evidence. If you have a different belief, so be it. I think we can leave it at that unless you are willing to discuss this in a more constructive and collaborative manner. Cacycle (talk) 03:49, 17 December 2008 (UTC)[reply]

1. My above questions do not pertain to reader confusion. Please answer them. You're the one advocating the addition of a controversial element to our most viewed page, so the onus is on you to provide evidence that this would be beneficial.

2. Rather than accusing me of failing to act in a "collaborative manner," I suggest that you remind yourself which of us is ignoring a longstanding lack of consensus (including a straw poll that drew 247 votes, and that was before the standard MonoBook search field was moved to a more prominent position). —David Levy 05:21, 17 December 2008 (UTC)[reply]

800x600

Are you aware of how your design would look at the 800x600 screen resolution? Below is a comparison between it and the current main page.

—David Levy 13:38, 14 December 2008 (UTC)[reply]

Scaling of the featured image to one column needs additional css code plus site javascript code as described above. If you add the css snippet to your monobook.css page as explained on top of this page it also works in Chrome. I have added some style tricks to let it appear correct without these changes but Google Chrome and Internet Explorer have some problems with that. It will not be a problem for a final main page version in which the image will scale neatly for all browsers. This is how it should look at 800x600:

1. Whatever style tricks you're using don't appear to be working on my end, as I received comparable results in Firefox (until I added the code to my CSS).

2. You say that this fix would require JavaScript. You realize that not everyone runs JavaScript, right?

3. Do you not see serious problems (even with the fix applied)? I see awkwardly stacked links, huge gaps in text (with the "Featured Article" column actually looking worse than it did without the fix applied), and horizontal scrolling. —David Levy 20:16, 14 December 2008 (UTC)[reply]

Whatever style tricks you're using don't appear to be working on my end, as I received comparable results in Firefox (until I added the code to my CSS).

I will look into this later. Until then we have to rely on the screenshots or the addition of the css code as described on top of this page. Cacycle (talk) 21:56, 14 December 2008 (UTC)[reply]

You say that this fix would require JavaScript. You realize that not everyone runs JavaScript, right?

The rescaling does not require JavaScript, the browser does it via css. The JavaScript part would only be needed for an additional server-side rescaling that sometimes gives better results. Cacycle (talk) 21:33, 14 December 2008 (UTC)[reply]

Please elaborate. Are you saying that without the JavaScript, the image will load at the maximum size (with all of the time and bandwidth that this entails) but be scaled to a smaller size by the browser? —David Levy 22:29, 14 December 2008 (UTC)[reply]

To answer my own question (because you never did), I see that this is the case. And that's absolutely unacceptable. Browser-driven resizing is a kludge that competent website designers have known to avoid for as long as websites have existed. The idea of placing the large image at the top of the dynamic content is bad enough, and wasting time and bandwidth (which some people pay for by the megabyte, you know) to load an image at a size larger than its display dimensions is ludicrous, even if this only applies to people with low resolutions not running JavaScript. —David Levy 05:21, 17 December 2008 (UTC)[reply]

The opposite is true. The JavaScript part would cause the loading of an optimally rescaled image and could therefore save bandwidth. The minority that has JavaScript disabled gets a standard-sized image that gets resized dynamically. As discussed somewhere else on this page, I am not able to relate to your idea that an image in prominent position is a somehow bad thing. Cacycle (talk) 13:42, 17 December 2008 (UTC)[reply]

1. It's absurd to claim that your code would "save bandwidth" when the the level of bandwidth use in question stems entirely from the very same proposal. Your "standard-sized image" is too large, and even if we were to deem such scale desirable, the idea of having some users expend that time and bandwidth without realizing a benefit is unacceptable.

2. Yes, I realize that you're unable to relate to the idea that we should be considerate of people with low-end technical resources. As far as you're concerned, "there is no ethical obligation" to do so. Fortunately, the community disagrees. —David Levy 16:22, 17 December 2008 (UTC)[reply]

I urge you take Wikipedia:Assume good faith to your heart, to calm down, and to stop your aggressive and uncollaborative crusade. Take the time to re-read my explanations and you will see that many of your questions have already been answered and that many of your allegations, rhetorical question, and conclusions are outright wrong. I would then be more than willing to help you understand my position and to constructively discuss with you. Please also recognize that you neither are you the community nor should you speak for the community. Cacycle (talk) 03:15, 18 December 2008 (UTC)[reply]

I do assume that you're acting in good faith. I merely disagree with you. I don't know why you regard my interaction as "aggressive and uncollaborative," apart from the fact that I'm criticising ideas that I dislike. (Do you want me to instead pretend that I approve of them?)

Yes, some of my questions have been answered, and I'm not thrilled with all of the responses. Other questions (which aren't rhetorical, I assure you) have not been answered, seemingly because you believe that the onus is on others to prove that your proposal is bad. I don't know what "allegations" you perceive.

I certainly haven't represented myself as the community or the voice thereof. But you are deliberately ignoring consensus. You're entitled to propose whatever design you want, of course, but I'm entitled to note its non-consensus elements. —David Levy 03:28, 18 December 2008 (UTC)[reply]

Do you not see serious problems (even with the fix applied)? I see awkwardly stacked links, huge gaps in text (with the "Featured Article" column actually looking worse than it did without the fix applied), and horizontal scrolling

That is a common phenomenon for justified text at narrow column widths. We could actually dynamically switch to left-adjusted text. Cacycle (talk) 21:36, 14 December 2008 (UTC)[reply]

Or we could not use such narrow columns.

Please address the awkwardly stacked links and horizontal scrolling. Thanks. —David Levy 22:29, 14 December 2008 (UTC)[reply]

Already addressed below. Cacycle (talk) 13:42, 17 December 2008 (UTC)[reply]

Also, how do you intend to handle panoramic featured pictures? Our current design accommodates them by assigning the full available width to that section, while your design places it in one of three columns (one more than we had before we resolved this issue).

And are you aware that we've deliberately placed the featured picture section at the bottom of the dynamic content for the benefit of users with slow connections? —David Levy 20:25/20:30, 14 December 2008 (UTC)[reply]

Also, how do you intend to handle panoramic featured pictures? Our current design accommodates them by assigning the full available width to that section, while your design places it in one of three columns (one more than we had before we resolved this issue).

I do not see a major problem with more squarish images, they would actually equalize the height of the three main column items. As for panoramic images we can probably find a nice solution, such as three-column wide on top or two column-wide on the top right. As stated above, this is more a general design study to communicate the basic principles than a final proposal that has been worked out into the least detail. But I am positive that we can adjust the general principles to every possible content. Cacycle (talk) 21:10, 14 December 2008 (UTC)[reply]

I don't understand your suggestion regarding panoramic images. —David Levy 21:24, 14 December 2008 (UTC)[reply]

And are you aware that we've deliberately placed the featured picture section at the bottom of the dynamic content for the benefit of users with slow connections?

Since the image will be rescaled to the column width there will be no layout rearrangements going on as the image comes in (other that the text in that column might move down. Cacycle (talk) 21:10, 14 December 2008 (UTC)[reply]

That isn't the issue. Images load much more slowly than text does, so we've placed the large image below the primarily text-based sections. This enables people with slow connections to read all of the primarily text-based sections before scrolling to the large image (at which point it's either fully loaded or much further along than it otherwise would be). Your proposal places the slow-loading image right at the top of the dynamic content. —David Levy 21:24, 14 December 2008 (UTC)[reply]

I am not sure if I understand what you mean. The MediaWiki generated page code specifies the width and height of images so that browsers generate empty placeholders of the correct size even in the absence of the actual image. Since the html image code comes at the same time as the text content I do not see the potential problems with resizing or scrolling. Cacycle (talk) 21:43, 14 December 2008 (UTC)[reply]

I'm saying that readers with slow connections shouldn't have to stare at an empty placeholder (which consumes visible screen space that could be assigned to text that already has loaded) if it can be avoided. The current main page design allows them to read all of the primarily text-based dynamic content before scrolling to the large image (by which point it will be fully loaded or much further along than it was when they began reading). Your design, conversely, places the empty placeholder alongside the rest of the dynamic content, thereby forcing readers with lower resolutions (the ones most likely to also have slow connections) to either wait for the image to finish loading or scroll back up to it after they've finished reading the text (which requires more scrolling to get through, due to the width consumed by the empty placeholder). —David Levy 22:29, 14 December 2008 (UTC)[reply]

This is a general phenomenon for web pages on slow connections and equally applies to each and every other image, logo, or icon on any Wikipedia page as well as on any other web page. People on slow connections see images loading slowly all the time, there is no ethical obligation for us to hide images from them because of that... Cacycle (talk) 01:52, 15 December 2008 (UTC)[reply]

It's not a matter of "[hiding] images." It's a matter of selecting a layout that works well.

We have a layout that works well for people with slow connections (without adversely affecting others), and you want to replace it with one that doesn't work as well for people with slow connections. I'm sorry, but I do feel obligated to avoid doing that. —David Levy 02:20, 15 December 2008 (UTC)[reply]

Update

I have made some minor changes that make the layout look better at lower resolutions:

The column separation is now relative resulting in smaller column spacing at lower resolution
The title row no longer causes the appearance of a vertical scrollbar at 800x600 pixels
The following page variant shows how an automatic change to left-centered column text would look like: Wikipedia:2008_main_page_redesign_proposal/Cacycle_low-res

Unfortunately, it is not possible to simulate the required css addition for browsers other than Firefox, so if you want to see the pages in Chrome, Safari, or Internet Explorer, you do have to add the css code as described above. Cacycle (talk) 04:10, 15 December 2008 (UTC)[reply]

1. I assume that you meant to refer to the horizontal scrollbar, and I still see it in both Firefox and Chrome.

2. The left-justified version doesn't look quite as bad, but the columns remain far too narrow. With three columns, there simply isn't a way around that. —David Levy 04:42, 15 December 2008 (UTC)[reply]

There is no horizontal scrollbar for me in any tested browser, you might have to refresh the page. Please see the updated 800x600 screenshot for how it now looks. Cacycle (talk) 04:37, 17 December 2008 (UTC)[reply]

Indeed, the horizontal scrollbar is gone. And the page remains horribly cramped. —David Levy 05:21, 17 December 2008 (UTC)[reply]

Proposal candidate?

I think this proposal tells us something, and I am assuming that you have strong view points on information overload; it would be great to see you in the discussion. However my main concern, Cacyle, is what do you consider your design study to be? Can you elaborate? You have to remember that we switched from a proposal candidate based system to a consensus based system. ChyranandChloe (talk) 04:54, 15 December 2008 (UTC)[reply]

As already explained on Wikipedia_talk:2008_main_page_redesign_proposal#Simple_and_clear_study I see it merely as a design study, not a final proposal. The main point is to demonstrate that the main page actually gets better if we do not try to put as many wikilinks as possible into a limited area. We have to keep in mind that for the vast majority of readers the main page is a portal to start their searches and that adding (too much) encyclopedic content interferes with its main function.

As for the failure of the 2008 main page redesign project, I am convinced that this was caused by a poor planning and a wrong process from the very beginning. As already written above, the correct strategy would have been to develop and to collaboratively optimize proposals for different design philosophies instead of shredding any innovation by focusing on single elements out of their context. Cacycle (talk) 03:22, 17 December 2008 (UTC)[reply]

I understand, thank you nonetheless. The only concern that remains is that the perception of how and why the MPRP failed is a particularly sensitive issue, that doesn't mean that I disagree with you; however I would prefer to keep it taboo until we can begin discussion on how to run the next MPRP. ChyranandChloe (talk) 05:39, 17 December 2008 (UTC)[reply]

OK Cacycle (talk) 13:15, 17 December 2008 (UTC)[reply]