Wikipedia talk:WikiProject Usability/Main Page/Draft/Archive post draft 6
From Wikipedia, the free encyclopedia
Open editing session archive
Drafts viewed on 800x600 resolution monitor
Today, I have looked through each draft on a 800x600 monitor to see how they hold up. I have posted screenshots of each, for comparison. User:Kmf164/Drafts
- The portal links, text size in Draft C work well.
- The smaller (fewer links) in the browsebar, aligned top-right work well.
- The search box header works fine, also.
--Aude (talk | contribs) 18:12, 4 February 2006 (UTC)
Draft viewed on 1600x1200 resolution monitor
For comparison with the 800x600 comparison above. →AzaToth 19:12, 4 February 2006 (UTC)
- Thanks for the large resolution screen shots. I've been looking at the differences, and (apart from wanting a bigger screen - currently have 1024 by 768) it becomes clear that some of the banners work better at some resolutions than others. How much do you all worry about this? Do you aim for something that works at either extreme? I did like the way the feature boxes display at larger resolutions, and how you just get more on the screen! Carcharoth 22:28, 4 February 2006 (UTC)
Re. current draft
Why use boxes within boxes for the titles ("Today's featured article", et al.) instead of handling it like drafts A and B did? Ral315 (talk) 21:01, 4 February 2006 (UTC)
- The current style proved considerably more popular in the straw poll. —David Levy 21:03, 4 February 2006 (UTC)
- I concur. A lot more votes went to drafts using the floating box heading style. --Go for it! 22:09, 4 February 2006 (UTC)
- That doesn't neccessarily mean that people liked those boxes the best. Personally, I think they are the worst. We need to have a straw poll on box styles. Kevin Baastalk 23:53, 4 February 2006 (UTC)
- Instead of counting votes, please read the actual comments. Numerous people singled out this element as a favorite. I personally preferred a different style, but the consensus is clear. —David Levy 00:41, 5 February 2006 (UTC)
Concerning structure and order of presentation
The order of the content
I moved the Featured pic up on the page and moved the DYK's down to the page spanning box but was quickly reverted [1]] by David, with the edit summary "Reverted. There's specific, consensus-backed logic behind this order." I'm just wondering; where can I find this consensus? I browsed through the archives and found no vote on the specific order the boxes must follow. "Logically" I would think that the featured content would be more featured. - Trevor MacInnis (Talk | Contribs) 21:37, 4 February 2006 (UTC)
- I actually liked it; it permits a larger image while also allowing for even(er) columns.--HereToHelp (talk • contribs) 22:17, 4 February 2006 (UTC)
- The picture should be fairly small, for the benefit of people with dial-up connections. Anyone may click on the image for the full-size version. —David Levy 22:25, 4 February 2006 (UTC)
- Firstly, all of the content in question (including "Did you know...") is featured.
- Secondly, there wasn't one single "vote" on this topic. I'm referring to comments from various discussions, combined with the outcome of the straw poll (in which this configuration was the most popular).
- Previously, we reached consensus that "Did you know..." should be below "Today's featured article" and "On this day..." should be below "In the news." This ensures that the two sections from each pairing are thematically similar. (The green column features highly polished articles and brand new articles, while the blue column features current news stories and news stories from years past). Additionally, "Today's featured article" and "On this day..." typically are the two longest sections, so it makes sense to place them in separate columns (for better balance).
- Numerous people have praised the featured picture section's horizontal configuration. It's the only feature that's based primarily upon an image (rather than text), and there's little thematic connection to any of the other sections, so it stands out as a separate entity. It also takes the longest to load (especially for people with dial-up connections), and it's fairly meaningless to people with text-only browsers, so it makes sense to place it below the other featured content.
- In reply to Go for it!, I didn't claim that any of the new portals are opposed by consensus. The issue is that we have no clear consensus regarding which ones to include. —David Levy 22:25, 4 February 2006 (UTC)
-
- I agree that the Featured image should be at the bottom, for the reasons given above. Besides, reading short columns of text is easier on the eyes than reading long lines, so stretching out the Did you know..-section makes the text less elegant. -- Ec5618 00:29, 5 February 2006 (UTC)
David, I for one would like to verify your conclusions. So please present the specific evidence upon which you base it. --Go for it!
I agree with Trevor that the featured picture should be in the column. Drafts B (27), C (28), G (46), J (9), K (4), and L (11) had the picture in the column and got 125 votes. Drafts D (23) and H (27) were the only drafts with the picture at the bottom and they only got 50 votes. Two and a half more votes were placed for the drafts with the picture in a column. --Go for it!
Consensus
- by David Levy, copied from Go for it!'s talk page:
As I've explained to you on several occasions, building "consensus" is not about blindly tallying votes. Aside from the fact that your raw counts are grossly inaccurate (as I noted in a message that you ignored), you're failing to consider various important factors (including the specific comments that were made).
I was promoted to sysop on a platform that was based in part upon my ability to gauge and implement consensus. I'm helping to do so, despite the fact that some of the design elements (such as the standalone headings and search box) do not match by personal preferences.
HereToHelp has lived up to his name. Conversely, many of your edits (while certainly made in good faith) have been counterproductive. I realize that you're attempting to honor consensus, but you simply don't understand what that is. You've misinterpreted the results of the straw poll, and I respectfully request that you take a step back and give my advice some serious consideration. —David Levy 03:05, 6 February 2006 (UTC)
- What is your interpretation of the straw poll, and please point out the specific steps through which you arrive at your conclusions. You have been supporting specific design elements in your edits, but I've yet to see how you arrived at the conclusion that each of those were consensus achieved in Round 6. I very much look forward to seeing your step-by-step interpretation of the data, upon which you have based your edits. --Go for it!
-
- Part of the problem is your belief that this is a purely scientific process. It isn't. If it were, we'd use a bot.
-
- I read each and every one of the comments that were posted, assessed the meaning of and motivation behind the votes, observed the various trends and patterns, and sought as much common ground and compromise as possible.
-
- You need to realize that blue plus yellow equals green, even if there's 51% blue and 49% yellow. Building consensus is about arriving at an outcome that can be widely agreed upon, not declaring the numerical majority the "winner."
-
- You also need to realize that when blue and yellow can't be mixed, the same basic principle applies. Even if 51% of people prefer blue, it's possible that most of them also like (or don't dislike) yellow. If most of the yellow fans dislike blue (and provide compelling reasons for their stance), yellow prevails.
-
- I've already gone into greater detail on the project's talk page, and I ask that you read and reply to that message before I'm forced to repeat myself more than I already have. —David Levy 03:58, 6 February 2006 (UTC)
David, you said: "I read each and every one of the comments that were posted, assessed the meaning of and motivation behind the votes, observed the various trends and patterns, and sought as much common ground and compromise as possible." But you left us out of the process, skipped straight to your conclusions, leaving us sitting here with big question marks hanging over our heads. Please point out the specific comments to which you ascribe consensus. Vague answers will not do. You mentioned that it wasn't a scientific process, but at least it is still a process. Processes can be explained and replicated by others, so please go over the process as you followed it step-by-step so that we can understand how you arrived at your conclusions. --Go for it!
- Not to be a pessimist, but if someone could soleve this problem we wouldn't have Democrats and Republicans at each other's throat all the time!--HereToHelp (talk • contribs) 00:20, 7 February 2006 (UTC)
- Again, I've already covered much of this ground. Please read and reply to the pertinent message on this talk page, and I'll be more than happy to address any remaining questions/concerns. —David Levy 00:37, 7 February 2006 (UTC)
Show/Hide button
Does anyone know how to force the Show/Hide button in the languages section to stay with the text it needs to be next to. At the moment, particularly at higher resolution screens, it floats off to the right and can be easily missed altogether. I notice that the Show/Hide button at the top of the page is also floating, this time off to the left and (for me) ending up over the Wikipedia logo. Obviously that isn't something that needs fixing, but it does show that this button can end up in weird places. Carcharoth 22:36, 4 February 2006 (UTC)
- On Konqueror, and firefox; the show and hide buttons overlap the wikipedia logo :-( The magical Spum-dandy 23:19, 4 February 2006 (UTC)
IE header display bug
As a reminder, we still haven't fixed the major header display bug in Internet Explorer. (The top of the book image is cut off.) I can think of two potential methods of eliminating this problem, but I'm not familiar enough with the coding to implement either:
1. Switch to the type of code used in the header from some of the other designs (such as draft D), but replace the portal links with the search box and magnifying glass. (This displays properly in IE.)
or
2. Change the manner in which the book image is included to be the same as that of the magnifying glass (which displays properly in IE).
Does anyone know how to do either of these things (or an alternative solution)? I've tried and failed. —David Levy 23:04, 4 February 2006 (UTC)
Also, when you hover over the text(any text in header on right side) a white background appears, staying even after the mouse leaves. This covers the image of the book. Flying Canuck 23:21, 4 February 2006 (UTC)
Blue header color
I just changed the blue header color (right column) to a shade that is halfway between the hue value used in Draft C and that used in Draft D/H/other drafts. Maybe this will make the color a little more appealing to those that preferred the blue/purple-gold colors. --Aude (talk | contribs) 23:11, 4 February 2006 (UTC)
- The problem with this is that our draft already includes a purple heading. By nudging the blue headings in this direction, you made them less distinct. —David Levy 23:14, 4 February 2006 (UTC)
-
-
- That's better, but I prefer the original shade. Does it look bad to you? (I selected it very carefully, and it directly corresponds to the shade of green used for the headers in the left-hand column.) —David Levy 00:41, 5 February 2006 (UTC)
-
-
-
-
- This color also corresponds to the green in every respect (saturation, brightness), except for hue. The way the colors were before, the green and blue were super similar. Again, it might be just me... or maybe that's part of the reason that many people voted for drafts with purple/gold colors. Probably worth more discussion here from others. --Aude (talk | contribs) 01:06, 5 February 2006 (UTC)
-
-
-
-
-
-
- That still looks too much like the bottom row color. Why do you want it to be more purple? 67.150.223.85 17:00, 5 February 2006 (UTC)
-
-
-
-
-
-
-
-
- On my laptop display it isn't purple at all. The original blue color looks very much like the green in the left column, and both the green and blue appear overly bright and saturated. This could be why so many people voted for the gold/purple color scheme in the previous voting round. By choosing a hue with slightly more "purple", the colors are calmer, and the green/blue look distinct.
- What kind of monitor/display are you using? I'm sure the issue here is that monitors vary somewhat in how they display colors. --Aude (talk | contribs) 17:10, 5 February 2006 (UTC)
- What purpose does this serve? Is this really worth arguing over? The exact shade of a background? --HereToHelp (talk • contribs) 17:20, 5 February 2006 (UTC)
-
-
-
-
-
-
-
-
-
-
-
- I'm sorry. I didn't mean to upset anyone. Chief Seattle 17:34, 5 February 2006 (UTC)
-
-
-
-
-
-
-
-
-
-
-
- That was me before I just registered an account. I have a laptop too. The blue and green look very different to me, but your blue looks too close to the purple. Not exactly the same, mind you, but less distinct like Dave said. By your own description you're adding purple, so you should expect that.
- I wasn't here for the voting, but it looks to me as though a lot of people were voting for the style that the purple and gold headers used. Then new versions were added with that style but in blue and green, and people started voting for them instead. But the new page has purple at the bottom, so purple fans should be satisfied from that. I also see complaints about the gold, so it was smart to leave that one out. Chief Seattle 17:34, 5 February 2006 (UTC)
-
-
-
-
-
-
-
-
-
-
-
- We can't possibly select colors that everyone likes. I have, however, read numerous complaints about the current main page's pink coloring, so we definitely have that in our favor. —David Levy 18:23, 5 February 2006 (UTC)
-
-
-
-
-
-
The colors of the visible light spectrum.
(adapted from the Wikipedia article, color) --Aude (talk | contribs) 19:24, 5 February 2006 (UTC).
Color | Hue | Saturation Brightness levels used in draft |
Slightly less brightness |
---|---|---|---|
red | Hue: 0 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
orange | Hue: 30 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
yellow | Hue: 60 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
green | Hue: 120 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
cyan | Hue: 180 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
cyan-blue David, Chief Seattle |
Hue: 206 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
cyan-blue Kmf164, Trevor |
Hue: 217 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
blue | Hue: 240 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
violet | Hue: 278 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
magenta | Hue: 320 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
red | Hue: 360 | Sat: 15%, B: 96% | Sat: 15%, B: 93% |
-
-
-
-
-
-
-
-
- The color Trevor and I preferred didn't appear the least bit purple to me. Here are both colors, compared against the standard palette of colors (see right). This color (preferred by Trevor and I) has a hue value of 217 (closer to blue, than cyan), while the color preferred by David and Chief Seattle is hue #206 (somewhat more cyan than blue). For reference, the green (left column) is 154 (halfway between cyan and green), and the purple (featured picture) is 263 (purple/slightly blue). --Aude (talk | contribs) 19:24, 5 February 2006 (UTC)
-
-
-
-
-
-
-
This issue is indeed very likely to be about the way different monitors display colours. There can be an amazingly wide variation between monitors. There is monitor calibration software available that could theoretically be used to make sure any two monitors display colours the same way, and I've seen them in use. After a while, the colours drift away from the calibration standard, so you have to keep recalibrating after a set number of days (depending on the quality of your monitor). So minor variation in colours is pointlessly debated unles you have colour-calibrated monitors, though I'm less certain about the difference between CRT and TFT and CRT and other monitor technologies. Hope that helps. Carcharoth 19:37, 5 February 2006 (UTC)
Don't be worried about how the vote will turn out: there were about 5 votes for the current Main Page.--HereToHelp (talk • contribs) 20:25, 5 February 2006 (UTC)
Wikipedia community, Wikipedia in other languages, Wikipedia's sister projects
All of the sections are arranged nicely, but the sections listed above are just kind of...there. Are there any ways to better integrate these sections, or make them look nicer? Morgan695 00:07, 5 February 2006 (UTC)
- In my sandbox I was playing around with a style for this section. Some people, though, are against any style at all here. Their reasoning, I think, is that this static section should feel seperate from the changing "featured" content, and a lack of color/headers etc does this. I'd try my ideas out here to see people's reactions, but I think it will probably be reverted pretty quickly since it hasn't been "approved" yet. - Trevor MacInnis (Talk | Contribs) 00:44, 5 February 2006 (UTC)
-
- I liked the grey header bars in one of the drafts, and the other languages and other projects should be switched around per usability, and other languages should have 100,000 and 10,000. Kevin Baastalk 00:45, 5 February 2006 (UTC)
Kevin's misty heading design works well for this section. I agree with Trevor's suggesting that we use it there. --Go for it!
- I can't take credit for those headings. I think they're actually Trevor's headings. I think they're great. Kevin Baastalk 01:26, 7 February 2006 (UTC)
Featured picture location
Citing census: Drafts B,C,G,J,K,&L had pic in column and got 125 votes. Only drafts D & H had pic in bottom box, and those only got 50 votes. [edit summary by Go for it!, 00:52, 5 February 2006 (UTC)]
- 1. You're counting numerous votes that were cast before drafts D & H existed, along with numerous votes that were cast before the picture was added to some of those drafts! You're also excluding the votes that were cast for a twin-column layout consisting of the four features other than the picture. In fact, you're counting some of these votes toward the "125" (because the picture was added after they were cast)!
- 2. Consensus is not determined via a straight ballot count. People were voting on the basis of various elements, and it's important to actually read the accompanying comments and gauge the reasoning behind the votes. The standalone featured picture section is something that many people (including some who formerly belonged to opposing camps) have gotten behind and explicitly praised.
- And since these sections were added after the votes of for the initial drafts were posted, those voters didn't have the opportunity to express their opinion on the placement issue because it wasnt' made known to them. So the fact that some users commented on the new placement is irrelevant because of the way that poll was run. --Go for it!
- 3. During the straw poll, no one expressed a preference for a standalone "Did you know..." section, which doesn't make sense. Did you read the pertinent discussion above?
- 4. Elsewhere, in response to my comment that the featured picture must be small enough to load reasonably quickly for people with relatively slow Internet connections, you stated that "we can have Main Page alternates for dial-up users - the Main Page needs to be the best of the best for the best." That type of attitude directly contradicts the goal of WikiProject Usability and the spirit of the greater community. This is the main page, so accessibility is of the utmost concern. —David Levy 01:21/01:32, 5 February 2006 (UTC)
-
- When viewing all the drafts on a 800x600 screen, draft D & H looked best, with the featured picture below the other items. Swapping DYK and the featured picture puts the two columns out of balance, with substantial whitespace beneath the right column features. This is due to the amount of caption text and the size of the picture. --Aude (talk | contribs) 01:49, 5 February 2006 (UTC)
-
-
- Sorry to say, but 125 votes between 6 drafts works out to 20 something. 50 between two is 25. There goes that logic.--HereToHelp (talk • contribs) 02:30, 5 February 2006 (UTC)
-
-
-
-
- Equally sorry to say, using your same logic, that B,C,&G got 100 votes, twice as many as D&H, or an average of 33 votes each, which beats the 25 you mentioned. Also, those 3 drafts (B,C,&G) which each represent the pic in the column approach got double the votes of those drafts that had the pic at the bottom. Draft G got almost as many votes as D&H combined, all by itself! --Go for it! 01:48, 7 February 2006 (UTC)
-
-
-
-
-
- Revisiting your logic, each of Drafts B, C, and G beat out or tied either D & H. With G almost beating them both combined. --Go for it! 01:48, 7 February 2006 (UTC)
-
-
I think featured picture shoiuld replace selected anniversaries. Kevin Baastalk 01:52, 7 February 2006 (UTC)
Lining up Featured Picture and On This Day
Would it be possible to get the Featured Picture and On This Day sections to line up? With Firefox the On This Day is maybe 10 pixels higher than the Featured Picture but has extra space at the bottom. I think they would look much nicer with the titles lined up with each other.--SirNuke 02:04, 5 February 2006 (UTC)
Only if the articles are placed in seperate boxes, which would create a line of white space above them. The consensus on the drafts presented in Round 6 favored the style with multiple features in the same box. The spacing of the articles under this format is automatic, and placement changes day-to-day based on how long the various articles are. Tomorrow, the won't line up by a different amount. See the Main Page alternate (blue boy) as an example of lining things up. --Go for it!
Show/Hide
FYI - the Show/Hide button isn't there (doesn't render) with the "Classic" skin which some of us oldtimers still use. hydnjo talk 02:21, 5 February 2006 (UTC)
- What is the default skin that new users will see the page on? Is it OK in that? Carcharoth 10:21, 5 February 2006 (UTC)
- That's the monobook.--HereToHelp (talk • contribs) 00:17, 7 February 2006 (UTC)
Header style & Search box
Which header do we use: the serach bar (redundant, but sometimes that's good) or the Portals (which can easily be added browsebar style just below the header)? I say the search bar because it does not detract from the Portals: they're there anyway. Maybe not as prominently, but hey, the search function is the best way to find stuff.--HereToHelp (talk • contribs) 02:43, 5 February 2006 (UTC)
- The vote already took place. We're supposed to be applying the consensus from Round 6, not battling it out to create a new consensus. We've got a lot more work to do in sifting through that mess and implementing all the favored features. --Go for it!
-
- The vote was sadly not decisive either way.--HereToHelp (talk • contribs) 02:58, 5 February 2006 (UTC)
- This is the *one* issue that leads me to say, let's present two versions for the vote:
- One with the extra search box and portal links below the header.
- The other with the portal links in the header and no extra search box.
- IMHO, I prefer the second option, as it has the portal links more prominent. And, if we go with the second option, then we could make the search box on the left, more noticed with bold text, color or something. I'm figuring out how to do that now. --Aude (talk | contribs) 02:53, 5 February 2006 (UTC)
- I'm all for a compromise if you can work one out.--HereToHelp (talk • contribs) 02:58, 5 February 2006 (UTC)
I would support keeping both the search box and an expanded selection of portals. If a way could be found to aesthetically include both. Though icons should be saved for a Main Page alternate. --Go for it!
Also, the IE display bug problem is resolved with the portal links header. Though, think I have a solution for the bug, with the other header. --Aude (talk | contribs) 03:10, 5 February 2006 (UTC)
- Could you please post your solution somewhere? —David Levy 03:31, 5 February 2006 (UTC)
- The loss of the search box I could take if extremely necessary. The addition of icons I will adamantly stand against until the bitter upload.
The Portals will be displayed with the search bar in the browsebar style; we can make them bigger. Put the Portals in the header and you lose the additional search bar completely.--HereToHelp (talk • contribs) 03:15, 5 February 2006 (UTC)
-
- There goes that idea:
We need to come to an agreement on this. I prefer the version without the search box, but I would rather settle for the version with the search box than risk messing up the entire election. It isn't that big of a deal!
In all honesty, I think that we should give the nod to the version with the search box (despite my personal preference). As I've attempted to stress, consensus is not determined via a raw vote count. While the opinion was split practically down the middle, the proponents of the search box expressed far stronger feelings than the opponents did. Some people stressed the fact that its inclusion was the single most important thing to them, and I don't recall reading any such sentiment regarding the boxed portal links (or the search box's exclusion). I personally believe that the page is better without the redundant search box, but its inclusion doesn't bother me very much. This seems to be the prevailing consensus; most users are either supportive or fairly apathetic. I feel that we would upset considerably more people with the search box's exclusion than we would with its inclusion. (Keep in mind that I'm placing the welfare of the project ahead of my personal opinion.)
Another issue to consider is that the search box version is more scalable; we can add or remove a portal link without throwing off the balance of the columns. This version also displays without horizontal scrolling in the 800x600 screen captures.
The appearance and location of the site-wide search box vary depending upon the skin. —David Levy 03:31, 5 February 2006 (UTC)
- Agree, except it is my personal opinion to like the search box. I took a stab at larger Portal icons, but now we have text wrap on smaller screens. We can either make them smaller again, make them bold/colorful/otherwise noticable, put them in the header, or remove some. But if that means reignighting the Health debate, I'll capitulate now and save ourselves the trouble.--HereToHelp (talk • contribs) 03:36, 5 February 2006 (UTC)
-
-
- I'd rather flip a coin. Listing more than one new candidate would be potentially disastrous. We would have vote dilution (even with approval voting), ballot box stuffing, and cries of "let's add a version with this minor difference too, or I'll vote to stick with the current design." We absolutely need to present a unified draft. We mustn't allow this trivial detail to spoil all of our hard work. —David Levy 03:59, 5 February 2006 (UTC)
-
Kmf, that design you posted above looks like it has potential. Please put it in the draft, so we can work on it. I'd like to try my hand at it. --Go for it!
I'll suggest again, that a possibly ideal compromise would be to Highlight the main location of the search bar, but just on the main page (in the default skin):
is it possible for us to implement this? if so, we'd just have to discuss where to add the "956,334 articles" statement. --Quiddity 01:33, 6 February 2006 (UTC)
- Yep, it should be possible, but may require tweaking the monobook source code. I'm looking into that now. Yellow might be the wrong color (too bold and different from the prevailing style and colors)? In my User:Kmf164/monobook.css, I have made the search box background color a light blue and changed the font color of the word "search". These changes apply across all pages, not just the main page.
- And, because of a lack of an id tag for just the search box, my monobook modifications also change the navigation and toolbox background colors. If we can get an id tag added to identify just the search box, we can resolve this and color just the search box.
- Feel free to copy my monobook.css to your user space to see the changes and play with the colors. --Aude (talk | contribs) 04:03, 6 February 2006 (UTC)
- Works great for me. This is my css suggestion (minimal). User:Quiddity/monobook.css. i'd also prefer/suggest that the search box be above the navigation box. --Quiddity 22:42, 7 February 2006 (UTC)
- I think this is a wonderful compromise - I'm still rather against dual search bars, but having the right-side searchbar easier to find is fantastic. Please try and get this to work :) Maybe then we can put the categories back on the header? :) - JustinWick 18:54, 6 February 2006 (UTC)
What is the purpose of having two search fields: one in the upper right and one on the left? Are different results obtained? Thanks Hmains 23:29, 5 February 2006 (UTC)
- It's just like amazon.com; often things are listed twice to make it easier for people to find what they're looking for the first time they go to the page.--Urthogie 23:32, 5 February 2006 (UTC)
- I'm sorry - that's just silly (and very bad design). Raul654 01:30, 6 February 2006 (UTC)
- I went and had a look at Amazon.com and Amazon.co.uk, and they do have two search boxes. One at the top and one at the bottom. In some ways this would also make sense for Wikipedia. People have to scroll down to see all of the Main Page, and in most articles in Wikipedia you have to scroll down to get to the end of the article. It would be good if a search box could be at the bottom of the page as well (having the search box move with you would be more difficult and a bit disorientating). That means that people don't have to scroll back up again to get to the search box. Has anyone tried putting the search box at the _bottom_ of this Main Page Draft?? That would be a clear justification for having a second search box. Though I personally think all this should be solved by making the search box more prominent in the surrounding MediaWiki layout (not just highlighting, but the layout as well. Going back to having a search box at the _bottom_ of all pages (i.e. in the MediaWiki layout), where is the best place to suggest this? Carcharoth 09:16, 6 February 2006 (UTC)
- I'm sorry - that's just silly (and very bad design). Raul654 01:30, 6 February 2006 (UTC)
ok, thanks Hmains 23:37, 5 February 2006 (UTC)
also it is still being discussed above in the "Header style" section. --Quiddity 01:36, 6 February 2006 (UTC)
I agree that there shouldn't be an extra search box. Duplicating this element makes no sense. Kmf's idea is an excellent compromise. --Go for it! 00:27, 7 February 2006 (UTC)
Main Page alternate link?
The Wikipedia:Main Page alternates page just got completed. It contains versions of the Main Page for special needs (such as for those with cell phones or scrawny laptops), and alternate styles as well. Some of the versions from Round 6 have already found their way there. I've also placed a couple entirely new designs there that weren't in Round 6.
Because not everybody is going to like the Main Page, whatever it turns out to be, we should put a link on the Main Page leading to the alternates, in the hopes they will find happiness there. Preferably the link should go in the header somewhere, so it is noticed by all. Any objections? --Go for it!
- What would be really neat is if there was a parameter to set what all links to the Main Page link to: more or less letting you design your own MP.--HereToHelp (talk • contribs) 03:42, 5 February 2006 (UTC)
- This project seems like a good idea, but I don't think that it's far enough along to be linked from the main page just yet. —David Levy 03:51, 5 February 2006 (UTC)
Thanks for the link to Wikipedia:Main Page alternates. I bookmarked that straightaway! Carcharoth 09:27, 5 February 2006 (UTC)
Readability of content in uppermost box
From a pure visual interpretation perspective, I find it difficult to read the "anyone can edit" link in the uppermost box, due to its location just under the bold underline of Wikipedia. Can it be moved, or the underline of Wikipedia be made a bit less bold, so that this important point be clearer to the newbie user? Alba 05:18, 5 February 2006 (UTC)
- I agree. I am sure there was a draft that had the links in the banner not underlined (while the links in the main page were). If not, then a line or two of white space is needed, but I'm not quite sure how to do that. [...] Just looked at the round 6 drafts. It was Drafts G and L that chose not to link the word Wikipedia. So white space is needed for those who have "underlined links" options turned on. Addressing Alba's point specifically: it is probably possible for you to (somehow) personally turn on and off the options where links are underlined, though you may, of course, not want to do that. Carcharoth 09:31, 5 February 2006 (UTC)
- I adjusted the position of that line of text. Does that look better? Does it look worse for other people? Carcharoth 09:37, 5 February 2006 (UTC)
Order of Wikipedia's sister projects
Having had a look, I think that it looks much better and makes more sense for sister projects to be above the "Wikipedia in other languages" section. Apologies if this already been debated and discounted. SeanMack 09:35, 5 February 2006 (UTC)
- SUPPORT - Good idea! - JustinWick 18:55, 6 February 2006 (UTC)
- Support. Kevin Baastalk 01:24, 7 February 2006 (UTC) I've always been pushing for this.
- Comment - To elaborate, the multi language piece is very bitty whereas the sister projects area is more polished looking. I personally wouldn't mind having all languages without the show/hide button - as long as it was at the bottom. Surely most new users to the english main page will be english speakers and therefore the sisters projects will be more relevant to them? Plus the multiple languages blend a bit better into the wiki boilerplate at the very bottom. Which reminds me, should contact us and donations be placed where they are at the bottom? IMO it would be a better use of screen real estate if they were in the wiki boilerplate at the very bottom - there is room on the bottom line for them. Cheers.SeanMack 13:18, 7 February 2006 (UTC)
White space in "Did You Know" box
There needs to be a line of white space in the "Did You Know" box, between "From Wikipedia's newest articles" and the following text. I tried to check the Main Page to see what it looks like there, but it is not there today (being the weekend). The other problem is that this involves the layout of one of the templates, specifically Template:Second feature (main page), and the Main Page templates are protected against editing. What can be done about this? Note also, that this might not be a problem with the template, but something wrong with this page, as when you visit the template page, there does not seem to be a lack of white space between those two lines. But we really need to see "Did You Know" when it is back on the Main Page, to see how it displays there. Carcharoth 09:49, 5 February 2006 (UTC)
Community links box
I noticed some comments in the discussions of draft 6 that some of the links in the Community links area were inappropriate, specifically the Donations link. The Reference Desk is also out of place, as that is a service for readers, not the Wikipedia community of editors. So I've removed those.
I also agree with the comments that the whole section is overdone and not strictly needed. It is the only place on the Draft where we have short bits of text trying to _explain_ things to people. Everywhere else, people are expected to click through to an explanation. I would propose having this community section as just a grouping of links, like the portals bar and browse bar at the top. There are four links at the moment (Community, Help, Village Pump, Signpost). Maybe some more can be added by looking for suitable links at the Community Portal?
Also, some of this duplicates what is in the browsebar. This is not a completely bad thing, as the browse bar and community bar (which I guess is what I am proposing) would perform different functions, but might still overlap. Carcharoth 10:02, 5 February 2006 (UTC)
- Forgot to add. I removed what other people said were inappropriate links for the Community section, but I agree that the Reference Desk should link from somewhere. I propose it links from the Browse bar. The whole Community section could just become a Community bar, but before taking that step, I wanted to see what you all thought. Carcharoth 10:19, 5 February 2006 (UTC)
What does the word "community" mean to you? What are the characteristics of a "community" page? --Go for it! 10:30, 5 February 2006 (UTC)
- I thought it was just a collection of links from the Community Portal. If not, then this section should be given a different name. I was thinking along the lines of the portal bar, where instead of "Browse by topic: <links>" you have "Explore the Wikipedia Community: <links>". Does that sound reasonable? Carcharoth 10:38, 5 February 2006 (UTC)
Go for it!, I disagree with the amount of links you are adding to the Community section and I also disagree with adding the line or two of explanations - a suitable title for each link should be self-explanatory (just as in the browse bar). I think this area should just be a way for people to explore the Community areas for the first time, clicking on links that they findd interesting. So just four to six links to well-chosen areas. The other links can be reached from those links. I also agree with the person who said that linking the header is not needed. What do you think? Carcharoth 11:17, 5 February 2006 (UTC)
Haven't had time to pare down the links in the Community section, but I've added a note to the talk page at Wikipedia:Community_Portal to ask for suggestions for the best 4-6 links from that rather overwhelming page. I think any Community Section on the Main Page should be a gentle introduction to the community areas. Carcharoth 12:26, 5 February 2006 (UTC)
- Yes, we must economize. There are way too many links there, plus they wren't as important (IMHO) as the sister Projects. I'm going to go to work in that area.--HereToHelp (talk • contribs) 12:33, 5 February 2006 (UTC)
I'd just like to re-iterate my earlier comments that the community section is inappropriate for the main page, as it totally ignores the fact the main page is for our readers, not editors or people involved in the community (who, in fact, tend to avoid the main page for other areas). Raul654 01:37, 6 February 2006 (UTC)
- 1. Some of those pages are geared as much or more toward readers (who certainly qualify as members of the community) as they are toward regular editors.
- 2. Are you implying that it's a bad idea for us to encourage and assist contributions from our readers?
- —David Levy 02:24, 6 February 2006 (UTC)
-
- Maybe "community" is the wrong term for the main page. Perhaps we should call the box something else, such as "Participate in Wikipedia" or something like that. In my opinion, this is the place to hook in new participants in the project. With that being the purpose, I think it's appropriate for the main page. --Aude (talk | contribs) 03:57, 6 February 2006 (UTC)
-
-
- I agree that "community" is maybe not the best word. I too would rather see "Participate in Wikipedia" there, with emphasis on "hooking" more users. - JustinWick 19:34, 6 February 2006 (UTC)
-
-
- The vast majority (I'd guess well in excess of 90%) of people who visit the main page are here only to read our content - not to contribute. So, to reply to your comments, (1) no, you're flatly wrong. People who are interested in our content would have NO interest in going to the new user log, the help pages (which pertain almost entirely to editing), the village pump, the communty portal, and meta news. The only page in that section that might even mildly interest them is the reference desk, which is already linked from "Questions" at the top of the page. (2) Allow me to pose an equivalent question - Why don't we link to taco, dolphin, and penis from the main page? Surely, someone must be interested in going to those fine pages? By not linking to them, are we attempting to discourage people from going there? Answer - no. It's just that the almost all of people visting the main page are there for something else. If the readers want to edit, there are already a multitude of ways for them to get started - adding a huge section to hte main page which the vast majority of visitors won't use is most certainly not a good way to do it. Raul654 04:01, 6 February 2006 (UTC)
-
-
- Firstly, upon what do you base that "well in excess of 90%" guess? I'm aware of no scientific data, but I would guess that the main page is visited by a large percentage of editors on a regular or frequent basis. Editors usually are readers too, and the featured sections are quite popular. I visit the main page several times per day. Now, onto the numbered points:
-
-
-
- 1. The help pages do not pertain almost entirely to editing. Help:Contents contains fundamental information for readers, and Wikipedia:Help desk is an ideal place for readers to seek personalized assistance. Furthermore, Wikipedia:Reference desk is highly (not mildly) useful to readers (hence the library-inspired name).
-
-
-
- 2. Your analogy is absurd, unless you believe that the taco, dolphin and penis articles are as important as the core concept on which Wikipedia is based (that this is a wiki, and everyone is welcome to edit it). This concept is very confusing to new users, and what better place to provide an explanation than the main page? I wish that such information had been laid out in this manner when I first discovered the site. I would have begun contributing much sooner. —David Levy 04:29, 6 February 2006 (UTC)
-
-
-
-
- It also took some time for me to understand what the "edit" tab at the top of each article is about. Though, with the main page, it's just "view source", so I think we need to go further to make it apparant to readers that they can edit and contribute (and how). If you haven't already read it, I suggest reading over the Openusability report for the German Wikipedia, which talks about user impressions of Wikipedia when the get to the main page, do they realize they can edit it, and how?
- If you have a better idea on how to make this fact about Wikipedia more obvious, please suggest. I'm certainly open to new ideas. I'm thinking of people we want to attract, tht are a wealth of knowledge, but not necessarily tech-savvy (e.g. grandparents). Or, how about academic experts/professors? People like William M. Connolley who's done remarkable work on the climate change and related topics. --Aude (talk | contribs) 04:46, 6 February 2006 (UTC)
-
-
Browse bar comments
Again, picking up on what some people said in the discussions of draft 6, the browse bar contains several different types of links: stuff aimed at first-time visitors and first-time and long-term readers of Wikipedia (About, FAQs, Browse, Articles A-Z), plus stuff for first-time editors (How to edit) and more experienced editors (Help Desk). Then there is site news, which links to what is essentially a mix of community links and media links, and then the donations link. There is no "contact us" link. That is at the bottom of the page.
I propose: (1) Putting the donations link with the contact link at the bottom of the page; (2) Putting the site news link in the Community section (I think how to edit and help are enough for the browse bar - no community stuff should be in the browse bar - regular readers and editors can set their own bookmarks or have their own page - I use the Community Portal link in the sidebar anyway).
If there is really a need for a link for the general public to find out sitewide news, that should go to a better page anyway - some wikimedia press officer site or something. And it could be linked from the "sister projects section", or a "wikimedia news" link could be added next to the contact us link and the (proposed) donations link, at the bottom of the page.
My final thought is to put the reference desk link that I removed from the Community section, back into the browse bar. It goes nicely with the browse option. I'm only going to do this final option, as I want to see what people think before making what may be considered drastic changes. It would also be nice to have icons for my proposed donations link and news link at the bottom of the page, together with the nice "contact us" icon that is there already. Carcharoth 10:51, 5 February 2006 (UTC)
- Actually, the phrase "Questions" covers things fine, and is better than FAQs, and leads people onwards to the Reference Desk, so that's OK. I have now been clicking through to the "Articles A-Z" area, and quite frankly we shouldn't have such a confusing link from the main page. It should be linked from within the Browse link, so people get "Browse an index" as an option when they click on that and arrive at Portal:Browse. BTW, what is the difference between Portal:Browse and Wikipedia:Browse?? Anyway, can the A-Z link safely go from the browse bar? Carcharoth 11:07, 5 February 2006 (UTC)
- The first is Portals the second is categories.--HereToHelp (talk • contribs) 12:21, 5 February 2006 (UTC)
- I think the phrase "Browse" in the _browse_ bar is more easily understood than "Portals" or "Categories", and as both portals and categories are ways of browsing Wikipedia, they should both be linked from a section called Browse. In my opinion, Help:Browse or Navigate:Browse should give links to (a) Portals; (b) Categories; and (c) Index. I really hope those pages that I made up exist... Carcharoth 12:38, 5 February 2006 (UTC)
- I don't know of a single unified page (though I like the idea) but I put in both categories and Portals into the browsebar.--HereToHelp (talk • contribs) 12:43, 5 February 2006 (UTC)
- I think the phrase "Browse" in the _browse_ bar is more easily understood than "Portals" or "Categories", and as both portals and categories are ways of browsing Wikipedia, they should both be linked from a section called Browse. In my opinion, Help:Browse or Navigate:Browse should give links to (a) Portals; (b) Categories; and (c) Index. I really hope those pages that I made up exist... Carcharoth 12:38, 5 February 2006 (UTC)
- The first is Portals the second is categories.--HereToHelp (talk • contribs) 12:21, 5 February 2006 (UTC)
The Browse by topic bar wraps on the default setup of Firefox on Linux on a 1024x768 fullscreen window; the 'Technology' tab is in the middle of the next line. If I use Ctrl-- to shrink the font the button on the search just above goes off the right of the screen. 86.16.134.121 13:11, 5 February 2006 (UTC)
Linking headers
The headers of the bottom three sections are now linked. The links for the first two (Community and Languages) are duplicated in the sections. The link for the Wikipedia sister projects one (that I added) is not. Firstly, is linking the headers a good idea? (I think it can look bad) Secondly, if the linking of headers is not carried through, can the link I found please be preserved. In fact, I'll put it in the section itself, so all three sections duplicate the link in the headers. Carcharoth 11:38, 5 February 2006 (UTC)
Sister Project/Interlanguage/Community header style
How should we make the headers on the last three sections. david Levy supports a monochromatic version of the other headers. I'm okay with that, but it can look kind of dull ("Hey! Why don't you use colors here? Some computer fluke?"). I like regular (==Text==) headers, but there's one issue. We're not supposed to have links in the headers (it's one of those rules that isn't enforced, but on the Main Page...) I'm at a loss; anyone else have an opinion or idea?--HereToHelp (talk • contribs) 13:33, 5 February 2006 (UTC)
- I'm fine with either the current style or ==Standard headers==. I object to the inclusion of color, centered text or links. —David Levy 13:43, 5 February 2006 (UTC)
-
- I agree, there should be some distinction (color) between the static and the dynamic. I'm going to try for standard headers and see If I can't work in the links outside of the title.--HereToHelp (talk • contribs) 13:48, 5 February 2006 (UTC)
-
-
- All three links already are present in their respective sections; they were entirely redundant. —David Levy 13:51, 5 February 2006 (UTC)
- Good because I just moved us over to the regular headers. Let's see if anyone else comments.--HereToHelp (talk • contribs) 13:57, 5 February 2006 (UTC)
- All three links already are present in their respective sections; they were entirely redundant. —David Levy 13:51, 5 February 2006 (UTC)
-
-
-
- I agree, it is important for color to serve as a distinctive factor for dynamic content. - JustinWick 19:35, 6 February 2006 (UTC)
-
'New users log' in Community section
I've been looking at the Wikipedia:New_user_log link from the Community section. It is a nice idea, but I had the thought that, unlike all the other links, this one might not be as carefully watched for undesirable content. As the Main Page gets such a lot of traffic, especially with new users, do we want to avoid them coming across potentially strange postings in the new users log area? First impressions can be important. Similar thoughts would apply to all of the static (ie. outside the feature boxes) links from the Main Page. Also, this Wikipedia:New_user_log could be the first link someone might click on to find out about the Wikipedia community. What is the very _best_ welcoming page that exists on Wikipedia? (Friendly, well-written, well-balanced, informative). That link should go at the top of this "Main Page Community section". Carcharoth 18:00, 5 February 2006 (UTC)
Community links
Seeing that most of the useful links in this section are linked on the left bar anyway, I'm not sure how necessary this is. I think the Main Page should remain a browsing (rather than editing) oriented approach to Wikipedia. Those who want anything else can click "Community Portal". --Oldak Quill 03:43, 6 February 2006 (UTC)
- That is exactly what I have been saying above. Renaming the section doesn't make it any less objectionable. Raul654 04:06, 6 February 2006 (UTC)
- We should use this section of the main page to attract new editors, and maybe "community" isn't the best term. I have changed the name of this section to "Participate in Wikipedia". If you can think of something better, without using the word "community", please change the heading. --Aude (talk | contribs) 04:08, 6 February 2006 (UTC)
About the objections that Raul and others are raising, would they be adequately addressed if the Community section was a Community _bar_ instead? Like the portal bar, but just a row of 4-6 links that people could click on? On the other hand, if the Community links need to go, then what about the last in the list of sister projects? The Meta-Wiki link is certainly not aimed at general readers, and you could argue that the "other languages" section (being mainly for editors) could be replaced by a single link to something like the multilingual portal, just to make readers aware that other languages are available. Carcharoth 07:10, 6 February 2006 (UTC)
- I think it's worth exploring other ideas, such as you suggest for the community section. --Aude (talk | contribs) 17:08, 6 February 2006 (UTC)
Show/Hide button on "other languages" bit - more information
In the "other languages" section, should the "over 1000" language editions be hidden by default and only shown using a Show/Hide button? Hydnjo said up above that the Show/Hide button doesn't even appear in the "Classic" skin. I've been asking around, and the Show/Hide button seems to be a navigational frame javascript feature that is part of the Monobook css settings. See MediaWiki:Monobook.css. There seems to be something at the bottom of that page about "a.NavToggle", which might be the right thing. Can anyone who knows more about this: (a) Decide whether it matters that Show/Hide only appears in the (default) Monobook skin; (b) Find out from this link to the Monobook css settings whether it is possible to force the Show/Hide button to appear immediately after the "Wikipedia encyclopedia languages with over 1,000 articles" bit. Thanks. Carcharoth 11:09, 6 February 2006 (UTC)
- OK, I seem to have found the thing that adjusts the position of the Show/Hide button. My edit summary said "Changed (div class="NavHead") width from 70% to 39% to bring Show/Hide button next to text in "over 1,000 articles" bit of "Other languages" - see talk page for further details". The relevant bit of code is: div class="NavHead" style="background:#fff;text-align:left; width: 39%". By changing the width % from 70% to 39%, I brought the Show/Hide button next to the text when it renders on my screen. Does it still look OK on other people's screen? Carcharoth 11:23, 6 February 2006 (UTC)
- I'm pretty sure it will overlap with the text on smaller resolutions, and will not be 'right next to' the text on larger resolutions. -- Ec5618 11:48, 6 February 2006 (UTC)
- It did. I changed it back so that it is OK at 800x600. Will drift off to the right for higher resolutions. Not sure whether it is possible to fix this. Speaking of screen resolutions, has there ever been a proposal to put a "best viewed at xxx resolution" notice anywhere on the Main Page? Carcharoth 12:17, 6 February 2006 (UTC)
- I'm pretty sure it will overlap with the text on smaller resolutions, and will not be 'right next to' the text on larger resolutions. -- Ec5618 11:48, 6 February 2006 (UTC)
Wikipedia's sister projects
The revised page looked good. My only minor issue would be with the "Wikipedia's sister projects" section. At certain browser widths, some of the text start below the icons while for others it begins in-line with the icon. That just makes it look a little untidy. I think it would look better with a break just after each icon so that the text starts below. Thanks. — RJH 15:39, 6 February 2006 (UTC)
- Good point. Has this been implemented? Carcharoth 08:23, 7 February 2006 (UTC)
- It looks good now. Thanks. — RJH
Left search box
I have been looking into ways to modify the appearance of the left search box. I have figured out how to make the word search into a tab, with the word "search" bold and colored. Also, it's possible to modify the background color of the div box that encompasses the search box. Though, the .css code I used to do that applies the color to the navigation and toolbox, also. I somewhat like all the boxes with some color, but with a slight modification (add an "id" tag) to the monobook source code, the background color could be applied to just the search div box. The .css codes for these changes are in my monobook, User:Kmf164/monobook.css. --Aude (talk | contribs) 17:14, 6 February 2006 (UTC)
- With my monobook.css, I've turned navigation and toolbox also into tabs. The search tab has bold, colored text, and the other tabs don't. --Aude (talk | contribs) 17:31, 6 February 2006 (UTC)
-
-
-
- I'm unsure whether the tab effects are useful in the context of this discussion, especially as they are mozilla-specific(?). I'd advocate something more minimal, like this User:Quiddity/monobook.css. --Quiddity 22:00, 8 February 2006 (UTC)
-
-
Formatting problem
There is a slight formatting problem when viewing with Opera 8.51. In the "Wikipedia in other languages" box there is the line "Wikipedia encyclopedia languages with over 1,000 articles [Show]", but the link causes the word "articles" to wrap to the next line and overwrite "Multilingual". Alan Pascoe 20:43, 6 February 2006 (UTC)
Too many pastel boxes
The proposal up there now has too many pastel boxes. The colors don't improve the page; they make it harder to read. If this is the proposal, I'd rather keep the main page we have now. Jonathunder 23:20, 6 February 2006 (UTC)
- I'm sorry you're disappointed.--HereToHelp (talk • contribs) 00:15, 7 February 2006 (UTC)
Header style (New and improved sub heading discussion!)
Go for it! keep putting up versions that a) IMHO, are just plain ugly, and more importantly B) use a slew of Portals. I'm not opposed to some Portals but all of them is just too much. It distorts the header (again the ugliness factor) and some of the Portals are not ver good. They are not maintained enough to warrant such high visibility. I appreciate the attempt at compromise, but please, use the show preview button and don't save "work in progress" versions. Use a sandbox, please!--HereToHelp (talk • contribs) 00:29, 7 February 2006 (UTC)
Expanded portal coverage got much support in the poll, both in matrix style and in icon style. We can fix the ugliness factor (like putting the magnifying glass back in, etc.). --Go for it!
The portals can be easily fixed, and with higher traffic due to being posted on the Main Page there will be more users to maintain them. Also, Wikipedia's usage is growing at an alarming rate, so more users will become available for this all the time. All that really matters is that the portals be ready for display by the time of the election. And they certainly will be. But it would help if you would be more specific - which portals aren't ready and how? --Go for it!
- See me in the next header down...ugh...--HereToHelp (talk • contribs) 00:47, 7 February 2006 (UTC)
Stop edit warring
If you like, David, go ahead and lock the page to force us to talk rather than just use edit summaries.
- This is an open editing session. Locking the draft would be extreme. --Go for it!
- It would be inappropriate for me to protect a page on which I'm involved in a dispute. —David Levy 01:29, 7 February 2006 (UTC)
- It was just an idea. You're right, never mind.--HereToHelp (talk • contribs) 21:37, 8 February 2006 (UTC) Back to the original post:
- It would be inappropriate for me to protect a page on which I'm involved in a dispute. —David Levy 01:29, 7 February 2006 (UTC)
The issues that people disagree on:
- The header style. I like it with the search bar and basic Portal links below, other like a bunch of portals with no search bar.
- The POTD position. I say it should be in the purple box because we can make the image larger (and have more info on it) without disrupting everything. If someone wants a slightly smaller picture, though, go ahead.
- The style for the static info. I say go with standard level 2 (==text==) headers. Icons and colors have indeed been disliked, especially there.
We can either talk about this or do separate straw polls on each aspect.--HereToHelp (talk • contribs) 00:46, 7 February 2006 (UTC)
If running more polls will make you happy, then do it. --Go for it! 01:09, 7 February 2006 (UTC)
The search box is getting plenty of opposition (see the header/search box discussion above). No consensus was arrived at for duplicating the search box which is already on every page. It has been strongly opposed in every Round of this redesign effort. We need to remove it or integrate it with expanded portal coverage so that everyone is happy. Why are you not willing to compromise? I'll support a search box if you can find an aesthetically pleasing way to include both it and the portal matrix in the header. --Go for it! 01:09, 7 February 2006 (UTC)
- I'm not going to get involved in the revert war... but would advise we go with the portal links in the header, as in Draft C and D.
- While there was significant support for the second search box, there was also much opposition to it. We didn't get such strong opposition to the portal links, and plenty of support for them.
- Secondly, one purpose of the redesign is to make the browse links more prominent. Sticking them below the header is, IMHO, not much better than the current main page. With them in the header, you can't miss them.
- Third, when I was viewing all the drafts on an 800x600 monitor, the browse/portal links (all lined up below the search box/header) had the last item (technology) or two wrapping onto a second line. It looked unprofessional, whereas the portal links in the header looked fine. The text size used in Draft C for the portal links worked best.
- Fourth, when looking over the German Wikipedia usability report and in discussion with them, they said that new users did find the search box on the left side of the page (though sometimes with some delay). By tweaking the appearance of the search box, I think we can improve this.
- Finally, I noticed the attempt by Go for it! to try and include both the portal links and the search box in the header. I think that makes the page just too busy and doesn't work.
- --Aude (talk | contribs) 01:16, 7 February 2006 (UTC)
- I don't believe that additional straw polls are necessary. We already have plenty of comments with which to work.
- The black and white opinion on the header style is split practically down the middle, and we're not going to arrive at a clear consensus for either style. Let's try to work out something (but not Go for it!'s ghastly solution).
- Numerous users expressed a preference for the standalone, horizontally-oriented featured picture section. Many of the people who voted for a version containing the featured picture within one of the twin columns did so before the aforementioned layout existed, and it's obvious (based on their comments) that they merely supported the inclusion of the picture seven days per week (not the specific placement). The purple box is the practical location (for many reasons that I've already cited elsewhere on this page). Go for it! has plainly stated that he doesn't care about dial-up users, and that's a patently irresponsible attitude. —David Levy 01:29, 7 February 2006 (UTC)
-
- Perhaps we should first discuss the possibility of marking the search box more clearly (through css) on the Main page only. If we can find a way to clearly mark the search box (perhaps using the same yellow we use in the tabs, to add a simple border to the search box), this discussion may be irrelevant.
- It would also make the edit warring rather foolish, and would put an end to the mentality that 'my idea has consensus, because that's how I interpret the data'. -- Ec5618 01:34, 7 February 2006 (UTC)
- I'm not trying to say that the data we have is worthless, but the fact remains it has more than one uncontrolled variable? Surely you remember the term from your science fair days? After all, you so diligently and scientifically implement the consensus data but that data itself is not scientifically acceptable. That doesn't mean throw it out; that means know that it's not infalible.
I'll support the Trevor's idea because I like it more than some other aspects, and agreeing here gives me more leverage there.
How about, even though I know it may look busy, the "Welcome to Wikipedia/the free encyclopedia that anyone can edit" on the left where it is with the search box also on the left? that opens the door for Portals on the right..
However, I still think it's fine how it is. There's no point having links to Portals that are repetitive to others—and that may mean weeding out, say, Art—or are simply not maintaned well (did someone say Economics?). Also, a "good" Portal does not necessarily mean it deserves the spotlight. I like the design for Politics but it just doesn't cover a wide enough area to be on the Main Page. Also, we don't want a large header because it pushes more stuff down where it isn't as visible.--HereToHelp (talk • contribs) 01:37, 7 February 2006 (UTC)
- I'm not trying to say that the data we have is worthless, but the fact remains it has more than one uncontrolled variable? Surely you remember the term from your science fair days? After all, you so diligently and scientifically implement the consensus data but that data itself is not scientifically acceptable. That doesn't mean throw it out; that means know that it's not infalible.
Regarding Go for it!'s edit summary
I've tried to be patient and assume good faith, but I have a difficult time believing that you're unaware of the massive opposition to header icons and colorful styling in the reference box.
And incidentally, because HTH mentioned the 3RR, I'll note that less than two days ago, you violated it by reverting five times with a couple of hours. (Ironically, you warned HTH about the 3RR in the edit summary of your fifth reversion.) I didn't report you (and I don't intend to do so in the future), but I can't promise that another admin won't block you if it happens again. Please be careful. —David Levy 01:29, 7 February 2006 (UTC)
- I agree that a lot of people dislike the colors and icons. But you can't win everything. I'd rather save my brownie points for the header.--HereToHelp (talk • contribs) 01:39, 7 February 2006 (UTC)
-
- I think wikipedia needs style. It needs to be visually attractive. This is a low-cost way to do it. And dail-up is not *that* slow. C'mon ppl. Kevin Baastalk 01:44, 7 February 2006 (UTC)
-
-
- Dial-up may not be that slow, but the speed at which some users change their opinion is.--HereToHelp (talk • contribs) 01:50, 7 February 2006 (UTC)
-
-
-
- The problem with coloring all of the text isn't just download speed. It makes the page much less readable. Good professional page design avoids this for this reason. Typically the pages of a book are white, not grey, not colored, for the same reason: readability. I will strongly oppose a move to a less readable main page. Jonathunder 14:41, 7 February 2006 (UTC)
-
-
-
-
- What are you saying, Jonathunder? The current Main page already features coloured pastel boxes (which you say reduces legibility). The draft version uses lighter colours, which should make it superior to the current version. -- Ec5618 15:03, 7 February 2006 (UTC)
-
-
-
-
-
-
- It does have, and I would prefer them white, but they are lighter (hence more readable) than the proposal and they don't color the whole page as the proposal does. Jonathunder 15:08, 7 February 2006 (UTC)
-
-
-
-
-
-
-
-
- Jonathunder: You were mistaken about the main page's colors being "lighter (hence more readable) than the proposal." All three of the draft's background colors were exactly the same saturation as the current main page's left-hand column (and one notch lighter than the current main page's right-hand column). My attempted compromise made the saturation one notch lower than the current main page's left-hand column (and two notches lower than the current main page's right-hand column). The saturation level of "2" results in color that's barely detectable. (I realize that this is what you want, but your opinion does not match that of the community.)
-
-
-
-
-
-
-
-
-
- I don't know what you mean by "color the whole page." What distinction are you drawing? —David Levy 15:44, 7 February 2006 (UTC)
-
-
-
-
This is not a book. Websites are a better analogy. Kevin Baastalk 15:17, 7 February 2006 (UTC)
- I think pure white is not a great choice, but recommend a slightly tinted, pale background color. White is a bit harsh, bright, and caues glare. A pale color is softer on the eyes. Here are some discussions from Edward Tufte on the issue of background colors:
- --Aude (talk | contribs) 15:34, 7 February 2006 (UTC)
-
- I think what we have is fine, but I'm not a color expert either.--HereToHelp (talk • contribs) 21:37, 8 February 2006 (UTC)
Link to Main Page alternates
There are now several alternate main pages listed on the Main Page alternates page. So there is now a way for users to select a different version of the Main Page based upon their specific needs and tastes. There's one for PDA's, another for laptops, etc. There are also different styles, some from Round 6 and some new. Since the best place for a link to the Main Page alternates page would be on the Main Page, this looks like the best place to discuss this issue.
It would be nice if we could provide a link in the draft. It would greatly help ease the shock of those who don't like whatever design we come up with, because they would have alternates to choose from. Some people will hate the new design no matter what it looks like. So perhaps this is a way we can appease more of the users. It also ensures that all major design approaches are made available after the election is over. After the election, the Main Page alternates page could also include the current Main Page design for those who don't want to part with it. --Go for it! 01:24, 7 February 2006 (UTC)
- The current Main Page design should _definitely_ be preserved. I would suggest placing the link to Alternate Main Pages _permananently_ in the Main Page Talk Page, not the Main Page itself. And this Alternate Main Pages link should be widely publicised _after_ this project is over. Not during the election, and only moderately publicised before the project finishes. For now, linking from the top of this draft's talk page should be enough, plus some wording for the election like "After the election, regardless of the result, a link will be placed on the Main Page talk page to a page summarising the various drafts and ideas of the redesign project. For now, this link is available in the Main Page redesign pages in the Usability project pages." Carcharoth 08:35, 7 February 2006 (UTC)
- It would be a little deceptive to show alternative designs afterwards to show the community how discursive the discxussion was, when those alternative designs where never seriously considered. The point of alt. designs is to produce the best design, not to pretend that you tried. Kevin Baastalk 15:31, 7 February 2006 (UTC)
General notice box
Perhaps we should discuss placement of an optional and temporary general notice box. There will be a number of circumstances under which we may want to include a message on the front page (ArbCom elections, Fund drives, etc.), and it might be prudent to create a box designed to match the rest of the Main page, for any such notice. At the very least we should probably agree on some general placement options. -- Ec5618 01:34, 7 February 2006 (UTC)
Good idea, especially concerning style consistency. The box could be left within comment delimiters on the source for use when it is needed. --Go for it! 01:38, 7 February 2006 (UTC)
- I'm telling you, the watchlists!--HereToHelp (talk • contribs) 01:54, 7 February 2006 (UTC)
- I'm not sure what you're trying to communicate. -- Ec5618 02:15, 7 February 2006 (UTC)
- David does. Put a message on all the watchlists like during ArbCom!--HereToHelp (talk • contribs) 02:23, 7 February 2006 (UTC)
- I was referring to notices such as "The main page has been redesigned. If you do not like this version, we may have some others." Surely, there are comments we don't need to put on all watchlists. -- Ec5618 02:27, 7 February 2006 (UTC)
- OH! I meant something like what's on the Community Portal: "the Main Page is undegoing a redesign, feel free to help."
- I was referring to notices such as "The main page has been redesigned. If you do not like this version, we may have some others." Surely, there are comments we don't need to put on all watchlists. -- Ec5618 02:27, 7 February 2006 (UTC)
- David does. Put a message on all the watchlists like during ArbCom!--HereToHelp (talk • contribs) 02:23, 7 February 2006 (UTC)
- I'm not sure what you're trying to communicate. -- Ec5618 02:15, 7 February 2006 (UTC)
Comment on Bottom section
I don't know if I am doing this right, if I am commenting in the right place, or if I am even allowed to comment (since I am really just a reader and an uncyclopedian coming over here to steal your code) but I would just like to say that i think this edit without the fading blue title bars is drastically superior to this edit with them. Please feel free to delete this comment or move it to the correct place if I have erred in posting here. --Isra1337 02:39, 7 February 2006 (UTC)
- You put it in the right place, and I agree.Ashibaka tock 02:45, 7 February 2006 (UTC)
- Please do comment on this, or anything else regarding the design. We value all the suggestions and inputs from readers and editors. --Aude (talk | contribs) 02:50, 7 February 2006 (UTC)
- Heck we value them. I wish everyone was following this and giving their opinion. I agree with you on that specific case; Go for it!, there's your consensus (at least enough to prove that a lurker felt strongly enough about it to comment). This is certainly the right place, and go ahead and take the code—it has happened before (*cough* Mozilla website *cough*). Say, do you have an opinion on the header style (Portal links or search bar?) .--HereToHelp (talk • contribs) 02:57, 7 February 2006 (UTC)
- I do not have a particularly strong opinion about links vs. search, though I prefer Draft A's header to Draft B's header. --Isra1337 05:16, 7 February 2006 (UTC)
- I'm in two minds about them. I actually prefer the look of the fading blue bars, but the other version is more consistent with the standard look of Wikipedia articles (and there's not much point having the front page looking completely different from the rest of the site). Waggers 12:04, 7 February 2006 (UTC)
- I do not have a particularly strong opinion about links vs. search, though I prefer Draft A's header to Draft B's header. --Isra1337 05:16, 7 February 2006 (UTC)
- Heck we value them. I wish everyone was following this and giving their opinion. I agree with you on that specific case; Go for it!, there's your consensus (at least enough to prove that a lurker felt strongly enough about it to comment). This is certainly the right place, and go ahead and take the code—it has happened before (*cough* Mozilla website *cough*). Say, do you have an opinion on the header style (Portal links or search bar?) .--HereToHelp (talk • contribs) 02:57, 7 February 2006 (UTC)
- Please do comment on this, or anything else regarding the design. We value all the suggestions and inputs from readers and editors. --Aude (talk | contribs) 02:50, 7 February 2006 (UTC)
Top categories
I just like to say the current setup looks unprofessionnal.At least put the different portals in a menu setup and not spaced with pipes.It's like a trip back to the pre-visual browsers.If anything this is not good GUI design and definately not for the general public (I have experience in this field).Anway I wasn't able to vote due to a computer failure in the last few days,but I did now http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Usability/Main_Page/Draft/Header_poll
you can read my comments there.--Technosphere83 10:44, 7 February 2006 (UTC)
- "A trip back to the pre-visual browsers".. well put! what we need are colourful portal icons.. the pipes between links are so last century.. 131.111.8.98 13:40, 7 February 2006 (UTC)
-
- Portal icons (colourful or not) have been rejected by the community. We're striving for a clean, practical interface, and most respondents agree that portal icons are a needless resource drain and waste of space. —David Levy 14:25, 7 February 2006 (UTC)
- Thank you for your input. The current Main Page contains the same pipes, and I don't recall encountering any complaints. —David Levy 14:25, 7 February 2006 (UTC)
Featured picture
I'd prefer to see this taking up less space, and continuing the 2-column look of the top sections. The size of the picure is fine, but I think there's too much text there. Just the picture and a link to the article would be better, I think. Then the "Other areas" could go in a column alongside.
Just a thought. Waggers 12:09, 7 February 2006 (UTC)
- Your feedback is appreciated, but we've already covered this ground. The prevailing sentiment is that the static content should remain separate (both in location and style) from the dynamic content. —David Levy 14:25, 7 February 2006 (UTC)
-
-
-
- I support this change. —David Levy 15:52, 7 February 2006 (UTC)
- Indeed; the size is still kind of jarring, compared to the butterfly example in the earlier drafts.--ragesoss 16:42, 7 February 2006 (UTC)
- I support this change. —David Levy 15:52, 7 February 2006 (UTC)
-
-
OK, looks like the Main Page redesign is solidifying. As the current maintainer of WP:POTD, can I clarify; is the future intention to have the POTD on the MainPage every day? -- Solipsist 20:15, 7 February 2006 (UTC)
- Yes, that's what we're shooting for. The idea proved extremely popular in our straw poll. —David Levy 20:22, 7 February 2006 (UTC)
-
- As you might notice, the template used on this draft is formatted slightly differently than Wikipedia:Picture_of_the_day/February_7,_2006 and Wikipedia:POTD/February 7, 2006. We don't want you to have to prepare three different templates each day... I see there are three variables that go into each POTD (image, caption, photo credit), which perhaps could be separated from the POTD templates? But then, I know there's also the archive and not sure if/how the best way to manage it w/ templates? --Aude (talk | contribs) 20:39, 7 February 2006 (UTC)
-
-
- And Wikipedia:POTD/February 7, 2006 has a title (4th variable). --Aude (talk | contribs) 20:40, 7 February 2006 (UTC)
-
-
-
-
- I've developed a template (see below, source), which draws the variables from separate pages (User:Kmf164/POTD-image, User:Kmf164/POTD-title, User:Kmf164/POTD-caption, and User:Kmf164/POTD-credit), with "size" as the 5th variable. The same four variables could easily be plugged into the other two templates. To accommodate archiving, we might have to add the /{{CURRENTMONTHNAME}} {{CURRENTDAY}}, {{CURRENTYEAR}} to each variable. Do you think this solution would be helpful to you? or would it still be easier to setup three templates each day? --Aude (talk | contribs) 20:58, 7 February 2006 (UTC)
-
-
User:Kmf164/Pic of the day
Well currently we use about five variables.
- Image:xxx.jpg
- ImageMouseover:Message I see when the mouse rolls over the image
- Credit:photographer credit <caveat1>
- Title:1-4 word title of image, mostly the title of the primary article used as the link in the condensed Wikipedia:POTD version
- LongDescription:Body text - Several sentence description relevant to the image with primary article, linked in bold - used in the Wikipedia:Picture of the day and the MainPage version.
Image size would be a popular 6th parameter, especially to reduce the size of the condensed POTD. At the moment, I've got three generating templates that are used to subst the content on three different formats for PictureOfTheDay, POTD and MainPage:Today'sSecondFeature ({{Generate_POTD_T}}, {{Generate_POTD_C}}, {{Generate_POTD_M}}). It is relatively easy to generate each POTD format by copying the text and parameters for the first POTD template and pasting it into the others whilst changing one letter in the template name.
On Commons, the Picture of the Day is handled through double template transclusion, as used in User:Kmf164's example above. A little while back that didn't work, but it does now and it is probably the way to go for the redesign. The main drawback is that it will lead to a lot of protecting and unprotecting subpages each day.
The two primary caveats are:
- <caveat1>: the usual credit line is 'Photo credit:xxx'. However periodically we have maps, diagrams and other media, in which case I manually change the credit line to 'Illustration credit:xxx'. There has also been some discussion as to whether we should have a credit line at all. I'm fairly sure it helps motivate contributors, but others are concerned it is anti-wiki.
- <caveat2>: it is relatively easy to accomodate images with aspect ratios of 4:3. However, every now and again, we have exceptionally wide panorama images or narrow portrait images. This usually requires some rejigging of the image placement to avoid them being ridiculously large or laughably small.
Anyhow, I'm sure others will have some good ideas. -- Solipsist 21:39, 7 February 2006 (UTC) Anyhow
- Either way sounds workable. Thanks for the insight on the templates you use. --Aude (talk | contribs) 22:01, 7 February 2006 (UTC)
-
- I do not fully get how you will use all of these templates, but if you d , fine by me. The title (Today's feature picture) does not have to be templated; it is a constant. We do indded have maps or diagrams sometimes, would anyone oppose "Today's featured image"? And why do we need the title and the body text separate?--HereToHelp (talk • contribs) 22:23, 7 February 2006 (UTC)
-
-
- It's much better - cutting down on the volume of text has made a great improvement. Well done. Waggers 10:47, 9 February 2006 (UTC)
-
purple links
I don't know what the proper tag to use now that <font> is deprecated by W3, but could someone make the Wikipedia and anyone can edit links blue, even when they've been clicked in the past? Looks better for a logo not to have purple :)--Urthogie 13:50, 7 February 2006 (UTC)
<span style="color:#00F;">
. CSS declarations would also work. — Ambush Commander(Talk) 21:54, 7 February 2006 (UTC)
Outstanding issue: portal links vs. second search box
I'm not completely sure we have a consensus or decision on using the second search box. The alternative to the second search box is tweaking monobook.css to make the existing, left search box (subtly) more noticeable. Right now, with my monobook.css, I have:
- Turned the labels (navigation, search, and toolbox) into silver tabs. This is what the French Wikipedia does.
- Made just the "search" tab label bold.
- Colored the search div box a light gray, though earlier I had it a subtle yellow (as suggested above). Either way works okay.
Any thought on this alternative to the second search box? --Aude (talk | contribs) 22:11, 7 February 2006 (UTC)
- Actually, we've been waiting for you to find a way to integrate them into an aesthetically pleasing design. :-) --Go for it! 22:30, 7 February 2006 (UTC)
- Options such as changing the font, changing the background color, and bolding the text all seem a little too dramatic (although the latter might be accepted).
- I would suggest little more than a subtle yellow glow around the actual searchbox. As a bonus, it would allow us to refer to the searchbox as 'the yellow box, on the left hand side of the page', which shouldn't be hard for new users to find.
- We can use the same colour that is used above for the selected tab, for consistency. -- Ec5618 22:52, 7 February 2006 (UTC)
-
-
- In response to Go for it!'s idea of having both the second search box and portal links in the header. I don't think it's possible or a good idea, as it causes too much clutter (especially on smaller screens). Don't think I ever suggested it, but rather suggested tweaking the appearance of the existing search box on the left. We need to choose the portal links (possibly with the existing search bar, enhanced in some subtle way — this is my suggestion for a compromise) or the second search box.
- I personally like the second search box, but don't think it's that feasible. It sacrifices the portal links (prominence), which I thought was one of the usability goals of this project. And, it's my interpretation of the comments thusfar that it's inconclusive to choose the second search box, and many deemed it redundant (see Wikipedia_talk:WikiProject_Usability/Main_Page/Draft/Archive_6#Extra_Search_Bar).
- Another consideration is that many people use Google to search Wikipedia. The quality of the internal search engine isn't great in my opinion, it's somewhat clunky and not as intuitive as Google, or Yahoo!. So I'm not convinced that we should highlight Wikipedia's search feature so prominently. --Aude (talk | contribs) 17:46, 8 February 2006 (UTC)
-
My personal bias is to put in all the bells and whistles. But so far there hasn't been a design which integrates the two features in a way that both sides here likes. But that's because the code is extremely difficult to work with (while much of it is buried in the css), with attempts getting reverted rather than refined. If there is a volunteer who is fluent in Wikipedia/html/css page markup, we could sure use your help to create a header design with both the portal matrix and the search box in it. --Go for it! 18:03, 8 February 2006 (UTC)
This topic is now scattered across 3 sections, so i'll repeat: I'd advocate something more minimal, like this User:Quiddity/monobook.css. If we can make it MainPage only, that would be perfect. (I also agree with Kmf164 that google's search is vastly more efficient.) --Quiddity 22:13, 8 February 2006 (UTC)
- Thanks for your comments and monobook.css suggestion. The more minimal changes to monobook that you suggested look good. Though, in my monobook, I have tweaked the yellow, and tried searchBody { background-color:#F7F7DF; }. Also, without the bold text. --Aude (talk | contribs) 22:21, 8 February 2006 (UTC)
I am very strongly Against having a second search box. Not because it is redundant, but because it has negative reinforcement for the actual search box's location. The only reason 2 search boxes works on amazon, is they ALWAYS have 2: 1 at top 1 at bottom (never both visible at once). We're proposing only having a 2nd box at the top on only the main page. That seems highly counter-intuitive. --Quiddity 03:57, 9 February 2006 (UTC)
Reference box format
David - What was the formatting problem with IE? I tried it in IE and it was just fine. --Aude (talk | contribs) 22:16, 7 February 2006 (UTC)
- The section headings are messed up (for me, at least). —David Levy 22:35, 7 February 2006 (UTC)
-
- Maybe you could post a screenshot? What version of IE? I don't quite understand how the headings are messed up. Though, I'm also okay with the way it's formatted now. With the sister projects and "learn and interact" sections side-by-side, I was trying to center the sister project links/icons but couldn't figure out if/how to do it anyway. --Aude (talk | contribs) 22:51, 7 February 2006 (UTC)
-
-
- Here's a screen capture (taken in Internet Explorer 6.0 for Windows XP). As you can see, the lines are not below the text. —David Levy 23:29, 7 February 2006 (UTC)
-
-
-
-
-
- Neither am I. So I'm putting it back until we get corroboration from someone else. - Trevor MacInnis (Talk | Contribs) 02:14, 8 February 2006 (UTC)
-
-
-
-
-
-
-
-
- Do you doubt my sincerity?
-
-
-
-
-
-
-
-
-
- And please explain how these edits qualify as "minor," and why you didn't even bother to include an edit summary this time. —David Levy 02:23, 8 February 2006 (UTC)
-
-
-
-
I also have the problem, but lower down. Also there seems to be some padding issues between the end of POTD and the reference section. I've taken a screenshot and put in some red markings to show you (like how they draw stuff around football players on TV). You can find the file here.--HereToHelp (talk • contribs) 02:48, 8 February 2006 (UTC)
- I see that padding bit too, I don't know where but I assume little padding can be added into the code. About the other thing, is it really even a problem? By you screenshot it looks pretty cool. Perhaps something I would even like to see, it looks stylish. And David, don't take it personally, I just accidentally hit save instead of preview. - Trevor MacInnis (Talk | Contribs) 04:17, 8 February 2006 (UTC)
-
- Now it's been reverted by Chief Seattle with the summary "the last section was screwed up". Is it the same problem as the others. Does anyone have an idea how to fix it because I think it really helps shorten up the page. - Trevor MacInnis (Talk | Contribs) 18:44, 8 February 2006 (UTC)
Browse bar position
I've noticed the disagreement on the browsebar location. I think we can find a way to keep it above the header, yet accommodate non-graphical browsers. There has to be a hack for that. However, if we end up putting the portal links in the header, then it makes sense (visually) to leave the browsebar centered, below the header. --Aude (talk | contribs) 22:16, 7 February 2006 (UTC)
- (The following is not directed at you, Kmf164.) I'd like to remind everyone that this is WikiProject Usability. We mustn't make the main page less accessible to some users (including people with visual impairments). It's entirely unreasonable to include problematic design elements and dismiss these individuals as insignificant. "Tough luck for them! They can use a different page!" is an unkind, irresponsible attitude.
- Perhaps some sort of hack is possible, but the current setup is unacceptable. "Wide support" is not adequate justification for the disenfranchisement of blind people (among others), and I seriously doubt that this is what proponents had in mind. —David Levy 22:35, 7 February 2006 (UTC)
Draft H doesn't represent consensus
Not surprisingly, David Levy/HeretoHelp is pushing Draft H. I've seen no attempt on their part to implement the consensus from the last round. They stated expressly that they would implement the most popular elements from the various drafts, but they've gone against their word. It's obvious that Draft H did not represent consensus, yet that's what they have been endeavoring to rebuild on the project page. If you don't believe me, just look at their edits. I'm beginning to strongly believe that the voters should be allowed to decide directly, as "consensus building" as touted by David Levy/HereToHelp amounts to a strong-armed pair of editors vigorously pushing their own agenda. When it comes down to it their main MO is reversion tactics paired with discussion rhetoric. The phrase "It's the Consensus" in their postings has become the equivalent of the phrase "It's God's Will", which, being totally unverifiable has been used throughout history to promote every form of lunacy under the sun. I think Draft H sucks, and that it represents the least common denominator rather than the best we can produce. I believe we could come up with a second Main Page candidate that blows it away. --Go for it! 23:33, 7 February 2006 (UTC)
- Please be bold and do so. If you give a high priority to taking the opportunity to improve the readability of the page based on common professional design elements, including not letting the background overwhelm the text, you may well get my vote. Jonathunder 23:40, 7 February 2006 (UTC)
-
- Again, the background colors are lighter than those of the current main page. Why do you insist that the opposite is true? —David Levy 23:55, 7 February 2006 (UTC)
-
-
- At one point it was visibly lighter, but now it is not, and with more colors, the saturated background is even more distracting than the current page (which is no model of good design or readability). If in all this change, steps are not made in the direction of readability, it is an opportunity wasted. Jonathunder 00:21, 8 February 2006 (UTC)
-
-
-
-
- You're entitled to your opinion (which opposes an overwhelming consensus), but your claim that the main page's background colors "are lighter (hence more readable) than the proposal" is false. In fact, when you posted that statement, our draft's background colors were an average of 9% lighter than those of the current main page, and that figure now stands at 27%! —David Levy 00:38, 8 February 2006 (UTC)
-
-
-
-
-
-
- This is the second time you told me this draft has "overwhelming consensus" and must not be changed. I just don't buy that, so let's discuss actual design principles. The current main page is not very readable. Why repeat its mistakes? Why settle for something that has a mere 9% more contrast between text and background, or even 27% more? Why not strive to make it as readable as possible? Jonathunder 00:56, 8 February 2006 (UTC)
-
-
-
-
-
-
-
-
- The "overwhelming consensus" to which I referred pertains strictly to the use of background colors. You believe that the colors render the page more difficult to read (an opinion to which you're entitled), but you continually express this as though it's an indisputable fact. Do you see anyone else raising the issue? No, and that's because almost everyone likes the colors. They've been used for years by this Wikipedia and numerous others, and that isn't going to change because you say so. We've already reduced the saturation by 20%, purely in response to your complaint! If that isn't good enough, I'm sorry. —David Levy 01:08, 8 February 2006 (UTC)
-
-
-
-
- Firstly, much of the above is a personal attack. I suggest that you choose a less confrontational approach.
- Secondly, no, draft H didn't "win," because THERE WAS NO COMPETITION. No matter how many times you choose to ignore my replies and insist that consensus is determined by your grossly distorted vote counts, that simply isn't so.
- In case you've forgotten, draft D (which spawned draft H) was created as a compilation of the most popular elements of the various drafts. You praised it as such, added it to the lineup (with the understanding that its late listing would be taken into account), and voted for it. Now you're twisting the facts (as I've explained in great detail) to make this design appear unpopular. You're attempting to create a situation in which I should have simply waited until after the round was over to create my compilation. But because I didn't, all of the thoughtful compromise that went into it somehow is rendered null and void, because you performed a mental reset, thereby deeming the design a brand new "competitor" to the older drafts from which it evolved.
- Again, I've "pushed" for the inclusion of design elements that I don't prefer (purely as a means of honoring consensus), and HTH has been nothing other than a class act. I don't know how you can allege bad faith on our part.
- And for the record, no one has proclaimed "it's the consensus" more than you have. You even stated this in a hidden comment within the actual draft (immediately followed by an absurdly inaccurate raw vote count). Until you understand what "consensus" is, you have no business attempting to implement it. —David Levy 23:55, 7 February / 00:09, 8 February 2006 (UTC)
-
- Them's fighting words. Go for it!, please tone down your comments, this is not inductive to discussion. -- Ec5618 23:57, 7 February 2006 (UTC)
-
-
- Yes, please be civil. The color saturation I don't care about; I trust David's judgment because he knows more than I do (which is about nothing when it comes to color). As for consensus, we have to look beyond the vote count. We also have to consider things like how big the header can be without being ugly, how to economize the first screenful of info, and how to make everyone somewhat happy (over having some who love it and some who hate it). Those who disliked the extra search bar merely, well, disliked it, but those who voted for it (myself among them) loved the idea. We'll annoy more people by excluding it than including it. Besides, the Portals arranged in the browsebar style means that people will be familiar with that style when they encounter it elsewhere on the site.--HereToHelp (talk • contribs) 02:42, 8 February 2006 (UTC)
- Not like I want to violate the consensus, but do keep in mind that no decisions are binding.--HereToHelp (talk • contribs) 03:37, 8 February 2006 (UTC)
- Yes, please be civil. The color saturation I don't care about; I trust David's judgment because he knows more than I do (which is about nothing when it comes to color). As for consensus, we have to look beyond the vote count. We also have to consider things like how big the header can be without being ugly, how to economize the first screenful of info, and how to make everyone somewhat happy (over having some who love it and some who hate it). Those who disliked the extra search bar merely, well, disliked it, but those who voted for it (myself among them) loved the idea. We'll annoy more people by excluding it than including it. Besides, the Portals arranged in the browsebar style means that people will be familiar with that style when they encounter it elsewhere on the site.--HereToHelp (talk • contribs) 02:42, 8 February 2006 (UTC)
-
Wikispecies logo
This page appears to indicate that the 2D version is a legitimate variant of the officially selected logo. Did I misinterpret an unofficial summary? —David Levy 02:48, 8 February 2006 (UTC)
- I looked over that but I dodn't see anything definative either way. I'm arguing only on the premise that it's the 3D that's on the top left of all the pages. Frankly, I don't see any reason to lose any sleep over this. The only problem with the 3D one is that it makes the others look dull. But, IMHO, that doesn't constitute reason for using a logo that, is indeed official (I can't find any reason to disprove it), but is not the prefered logo of Wikispecies.--HereToHelp (talk • contribs) 03:33, 8 February 2006 (UTC)
- I switched to the PNG version of the logo (on the current main page too) because the JPEG version was noisy. To play it safe, I've replaced the two-dimensional variant with its three-dimensional counterpart. —David Levy 14:24, 8 February 2006 (UTC)
- I'm not one to knitpick. The file version doesn't matter to me, as long as it is (more or less) the one that they use officially.--HereToHelp (talk • contribs) 21:30, 8 February 2006 (UTC)
- I switched to the PNG version of the logo (on the current main page too) because the JPEG version was noisy. To play it safe, I've replaced the two-dimensional variant with its three-dimensional counterpart. —David Levy 14:24, 8 February 2006 (UTC)
Featured Picture position
The featured picture certainly needs to go below the other content as it falsely gives the impression that it is the most appropriate and relevant part of the front page, as if this site is about pictures above all. violet/riga (t) 08:44, 8 February 2006 (UTC)
- And since it takes noticable time to load, especially for people on dial-up, the loading time is made overly obvious. Users would have to wait as the 'main content' loads. -- Ec5618 09:09, 8 February 2006 (UTC)
Please be careful when reverting
If you are restoring or reverting part of the page to an earlier version, please be careful to review the changes made after the version you are returning to. Otherwise you will end up throwing out other changes along with the ones that you are removing. I've now added back one change that was lost, and there may be others as well. Carcharoth 10:53, 8 February 2006 (UTC)
New discussion on Main Page Alternates link
The Wikipedia:Main_Page_alternates link is a good idea, but I agree with David Levy that that project is not yet far enough along to be linked from the Main Page. It is essential, as part of a "Usability" project to have links to things like that, but a clear distinction needs to be drawn between different styles (colours, boxes) and different layout (for PDAs, text browsers, blind users etc). Also, too many of the alternate pages have radically different links. People are introduced to Wikipedia in a completely different way with some of these pages - and end up on different pages. A clear lack of a unified approach. This would need to be much more carefully thought through before being implemented.
The other thought is whether you would need to protect all these pages from editing? If a lot of people are using a version that suffers from vandalism, that could be a disaster. I know the templates are protected, but the bits around it could still be vandalised. Would you protect all the versions? Would you accept new versions periodically. It sounds like a good idea, but a bit too late at this stage. I would suggest after this Main Page redesign is over, take the final version and make clear, simple changes (colour, text, number features, etc). Only A FEW CHANGES per version, and start a range of alternates that are based on the final redesign. Any other approach will make these alternates feel TOO different and this will be confusing. Carcharoth 11:23, 8 February 2006 (UTC)
- Carcharoth and I are in agreement. This is a good idea, and it probably should be our next big project, but it's nowhere near ready to be linked from the Main Page. —David Levy 14:27, 8 February 2006 (UTC)
Reversions
1. See the above section for an explanation of why the "main page alternates link" should not be included at this juncture.
2. As previously noted, we mustn't introduce a design that makes Wikipedia less accessible for some of its readers. Demanding that visually-impaired people (among others) switch to a different page or tolerate confusing output is entirely unreasonable. As such, I've returned the browsebar to its sub-header position.
3. The gold coloring has consistently proven unpopular. This was true when I first added it to a draft, and the anti-gold sentiment remained prevalent throughout the straw poll. —David Levy 15:00, 8 February 2006 (UTC)
- With regards to point 3: I disagree. Apart from two or three of the more persistent editors to the draft, there have been no explicit objections to the colour, aside from one who compained it was too bourgeois. On the other hand, the green was explicitly opposed by several in the polls prior to this session.--cj | talk 17:36, 8 February 2006 (UTC)
I don't like the color. i think it could be better. so could the boxes. Kevin Baastalk 18:09, 8 February 2006 (UTC)
- Personally, I'm indifferent to the colors. Though, since most of the drafts used green/blue (and we've added purple), we should stick with that. As well, we have tweaked the saturation and hue of the colors, which I think addresses some of the objections to the green/blue colors.
- I also noticed the browse icons were reinserted. I personally like them too, as it's a way to accomodate both prominent browse links and the second search bar. But, there's been strong opposition to the icons and don't think they represent consensus. --Aude (talk | contribs) 18:14, 8 February 2006 (UTC)
-
- If you must have color, the tan background provides more contrast to the text than the green, hence is more readable, and both are more readable than the blue. Jonathunder 21:52, 8 February 2006 (UTC)
Edit summaries
Can editors please provide accurate edit summaries. It is very difficult to follow the changes if the summary only mentions one of the changes made. Either mention all the changes, or make the changes in incremental steps with separate edit summaries for each step. At the very least, put "and other minor changes". Otherwise changes can easily be missed. Carcharoth 17:13, 8 February 2006 (UTC)
Unco-ordinated editing
I've just spotted an example of poorly thought out and unco-ordinated editing. The order of the "other languages" and "sister projects" area was switched round, which is fair enough as several people expressed support for that. The trouble was that someone followed this up by stripping out "Wikipedia" from the headings, so now instead of "Wikipedia in other languages", you get the header "Other languages" immediately following the sister projects section. This means that it is no longer clear to the casual reader whether this "other languages" bit is referring to the sister projects, or just to Wikipedia. The links are to other language versions of Wikipedia, so I've restored "Wikipedia" to the header of the "other languages" section. There is often a reason for the way something is worded. It sometimes pays to stop and think before changing something. Carcharoth 17:33, 8 February 2006 (UTC)
- This carries on into the insertion and removal of the search box, portal icons, middots, etc. I'm not saying there isn't room for change, but once a decision has been made we should adhere to it. Half the recent edits seem to be making changes which were already removed once before. -- Ec5618 18:48, 8 February 2006 (UTC)
- Rather then keep reverting the search box/portal links, let's discuss here the rationale for each option and work out a consensus decision. I personally like both options, but think there are pros and cons to each that need consideration. See discussion above (#Outstanding_issue:_portal_links_vs._second_search_box for some explanations of my concerns. --Aude (talk | contribs) 20:06, 8 February 2006 (UTC)
Pros and cons (extra search box vs. portal links)
The vote in the last round was not decisive either way. Let's rationally consider the pros and cons of both options, taking into consideration all the feedback we had in the last "voting" round.
Pros: Extra search box
- Redundant, but sometimes that's good. (HereToHelp)
- Portals can easily be added browsebar style just below the header. (HereToHelp)
- Search function is the best way to find stuff. (HereToHelp)
- Consensus favors this option. (David)
- Search box version is more scalable; we can add or remove a portal link without throwing off the balance of the columns. (David)
- The appearance and location of the site-wide search box vary depending upon the skin. (David)
Cons: Extra search box
- Redundant (Kmf164, Raul654, Go for it!, many)
- The German Wikipedia usability report and in discussion with them, they said that new users did find the search box on the left side of the page. (Kmf164)
- Portal links not prominent (Kmf164)
- In small screens, portal links may word wrap (especially as more portals are added) - see Image:Drafth.jpg (Kmf164)
- There was no consensus, either way. (Kmf164 and HereToHelp)
Pros: Portal links in header
- Possibly ideal compromise would be to Highlight the main location of the search bar. (Quiddity, Kmf164, JustinWick, Go for it!)
- Portals prominent, can't miss them. (Kmf164)
- Would allow the browsebar items (about wikipedia, questions, ...) to fit nicely centered under the header, eliminate the need to find a hack to put these links above the search box but still accomodate screen readers. (Kmf164)
Cons: Portal links in header
- Adding or removing a portal link may throw off the balance of the columns. (David)
- So far, all drafts that include the Portals sacrifice the search bar. (HereToHelp)
Header compromise attempt
No offense, but perhaps you should describe what it is you're trying to accomplish. Did you intend to move the searchbox to underneath the header? It really breaks up the layout, and moves the actual content rather far down. -- Ec5618 00:43, 9 February 2006 (UTC)
- This is a method of including both the prominent portal links and the search box. It also significantly reduces the likelihood of text wrap. I'm aware of the padding issue, which I alluded to in the edit summary. Presumably, this can be adjusted (but I don't know how). —David Levy 00:53, 9 February 2006 (UTC)
-
-
- I don't know how this looks on your end, but here's what I'm seeing on mine:
- —David Levy 02:08, 9 February 2006 (UTC)
-
-
-
-
- I really don't like it either, for above reasons. Also, I'd like to contribute a Safari screenshot of the header.--HereToHelp (talk • contribs) 02:32, 9 February 2006 (UTC)
-
-
-
-
-
-
- Here's an Opera screen capture. Shall we revert? —David Levy 02:39, 9 February 2006 (UTC)
-
-
-
-
-
-
-
- Yeah, that seals it. I'm not against the Portals so much as I'm for the search bar. If anyone comes up with a good compromise, I'll take it (or find another reason why not to).--HereToHelp (talk • contribs) 02:43, 9 February 2006 (UTC)
-
-
-
-
-
-
-
-
-
- Not really fixed enough to go on the final main page: It's not clear that the search box is a search box (unmarked box with a "Go" button? Go where?) and it's not going all the way across the page (at least at my resolution). See Media:WikipediaHeaderDraftFlawed.png. --CannotResolveSymbol talk 03:11, 9 February 2006 (UTC)
-
-
-
-
-
-
-
-
-
-
- Never mind about the issue above: fixed by closing a <div> tag. Still not clear that it's a search box, though. --CannotResolveSymbol talk 03:16, 9 February 2006 (UTC)
-
-
-
-
Maybe the issue of the extra search bar is far from being decided, but it seems in the above discussion that it would be acceptable to somehow highlight the one on the left and not have a second one? this seems like a good idea.. as it is, the user sees two search boxes and is faced with the somewhat confusing options of "Find", "Go", or "Search".. which do i choose? are they different? the difference between "Go" and "Search" is confusing enough as it is.. thankfully "Go" is in bold so i know which one's 'right'. 131.111.8.104 12:41, 9 February 2006 (UTC)
Centered text
For some reason, everything below the header seems to be center (rather than aligned left). Can someone fix this please?--HereToHelp (talk • contribs) 02:58, 9 February 2006 (UTC)
- Fixed in the same change noted above. --CannotResolveSymbol talk 03:16, 9 February 2006 (UTC)
New header design
Hey, I like this new design! :-) (The one with the search bar and browse bar combined and placed below the header containing the taglines and the portal links). Only one minor point: the colour of the bit below the header seems to fade somewhat, but that is just a personal stylistic thing. Also, has anyone checked this header at different screen resolutions to see what happens? Carcharoth 09:08, 9 February 2006 (UTC)
Two minor comments
Only two very minor comments about stuff I'm not quite sure how to implement, so if someone else could do the editing that would be great:
1) Add borders to either side of the combined browse bar/search box bit below the header. This is the "fade-out" things I was referring to above. I realised it isn't a colour issue, but is a borders issue.
2) In the "Wikipedia languages" section would it be best for the "over x articles" bits to be aligned left as on the current main page?
Hope someone can try out these suggestions. Carcharoth 11:27, 9 February 2006 (UTC)
- I don't know, i kinda think it looks better with the "over x articles" centered.. it fits better with the "Complete list . Multilingual" etc at the bottom of that box.. plus the Sister Projects box is nice and symmetrical, so why can't the following box be as well? Mlm42 18:23, 9 February 2006 (UTC)
New Header compromise idea
Hey, I got an idea (I just can't program): Have the search box with the button on the same line aligned right above the Portals in the header, and it's little ine above it as the top thing on the page. Have the about stuff in italics aligned left, also above the header. Keep the Portals in the header, and cut out that blue stuff. You can reverse the alignings if you like.--HereToHelp (talk • contribs) 12:07, 9 February 2006 (UTC)
- So, just reverse top and bottom? I'm not sure what 'blue stuff' you're referring to, but this is what a reversal would look like:
Categories – Portals – Index – How to edit – Questions – Help |
|
Welcome to Wikipediathe free encyclopedia that anyone can edit
|
- I believe there was some opposition to having any text above the header, for screen readers and the like. -- Ec5618 12:14, 9 February 2006 (UTC)
- The "blue stuff" got removed, it was there in an earlier version. New idea: how about keping them on the bottom but removing that grey colored area and and moving the "find" button up a line to be level with the box. We can also put back "Search xxx,xxx articles" above it. All that stuff between the header and the start of the FA/ITN seems too big. We need to trim it vertically (make it more vertically compact) so more stuff is on that first screenful of info.--HereToHelp (talk • contribs) 12:44, 9 February 2006 (UTC)
- The searchbox is level with the button. -- Ec5618 12:59, 9 February 2006 (UTC)
- The searchbox is level with the button for me too. The whole area doesn't take up too much vertical space for me either. Maybe you need to post a screenshot, HereToHelp? Carcharoth 14:00, 9 February 2006 (UTC)
- The searchbox is level with the button. -- Ec5618 12:59, 9 February 2006 (UTC)
Odd. It's fine in Safari but not level in Firefox. Here's a sreenshot of both. If we can get this owrked out I really like it. Still, I like an area of whitespace similar to this draft over the gray. HereToHelp (talk • contribs)
I've attempted to fix this problem, with the search box and button wrapping onto another line. Is your problem fixed? --Aude (talk | contribs) 22:21, 9 February 2006 (UTC)
- Nope. It's a firefox problem, not a programing one. But if we can find a compatible way to program it...--HereToHelp (talk • contribs) 23:11, 9 February 2006 (UTC)
This actually looks very nice... I really like the latest version of the main page. Keep up the good work everyone! - JustinWick 23:12, 9 February 2006 (UTC)
From one problem to the next...here's what I have now.--HereToHelp (talk • contribs) 00:06, 10 February 2006 (UTC)
- These problems must be specific to the OS X version of Firefox. On Windows, the page looked terrific before, and the only problem now is that the search box and button are too far to the right (but not cut off). —David Levy 00:21, 10 February 2006 (UTC)
-
- I'm at a loss, then. However, the search bar in this draft looks fine.--HereToHelp (talk • contribs) 00:29, 10 February 2006 (UTC)
-
-
- I wish that one of us knew more about webpage coding. If we can eliminate this issue, we'll be in an excellent position with the draft. —David Levy 00:36, 10 February 2006 (UTC)
-
It helped. It's not cut off anymore but it is right next to the edge. What about another </div>?--HereToHelp (talk • contribs) 02:38, 10 February 2006 (UTC)
- Still...if we go back to the search bar in the header, the Portals will be of no smaller size than before. Plus, we don't have to worry about wierd formatting like this. But if we can get this idea to work well, I'm not opposed.--HereToHelp (talk • contribs) 02:42, 10 February 2006 (UTC)
-
- The stuff that's aligned left doesn't start until further in, so I've changed it from 1em to 3. It looks great now. My only gripe is that between the white search box and the white background, you can't tell the border apart on the right and bottom sides! Can we try that with a gray background?
Anyway, the padding's fixed; make sure it looks okay in other browsers.--HereToHelp (talk • contribs) 02:54, 10 February 2006 (UTC)- It looks okay in Safari.--HereToHelp (talk • contribs) 02:56, 10 February 2006 (UTC)
- The stuff that's aligned left doesn't start until further in, so I've changed it from 1em to 3. It looks great now. My only gripe is that between the white search box and the white background, you can't tell the border apart on the right and bottom sides! Can we try that with a gray background?
-
-
- I hate to tell you this, but the extra padding pushes the search box too far to the left on my end. It looks unbalanced, and at the 800x600 resolution and default text size, the "Help" link wraps to a second line. :(
-
-
-
- There must be a solution that works for everyone, and we just need to find it. —David Levy 03:10, 10 February 2006 (UTC)
-
Welcome to Wikipediathe free encyclopedia that anyone can edit
|
|
- Your code helped, but it didn't solve the problem entirely. At the 800x600 resolution and default text size, the text no longer wraps in Firefox, but it does in IE. And the balance remains off. (The search box is too far to the left.) —David Levy 03:35, 10 February 2006 (UTC)
Until this page gets refactored, i'll repeat my comments from a section above:
- I am very strongly Against having a second search box. Not because it is redundant, but because it has negative reinforcement for the actual search box's location. The only reason 2 search boxes works on amazon, is they ALWAYS have 2: 1 at top 1 at bottom (and never both visible at once). We're proposing only having a 2nd box at the top on only the main page. That seems highly counter-intuitive. --Quiddity 05:21, 10 February 2006 (UTC)
- (If it does end up remaining, I'm especially strongly against having it labeled "Find" for obvious reasons.) --Quiddity 05:23, 10 February 2006 (UTC)
Bug fixing session
starting Feb 19th
Too late?
The navigation section has:
- Arts
- Biography
- Geography
- History
- Mathematics
- Science
- Society
- Technology
- All portals
Perhaps this has been discussed before, but I find it very strange and unequal. It suggests that mathematics, history and geography are not regarded as science. TeunSpaans 17:58, 24 March 2006 (UTC)