I have found the tabs to be extremely confusing. It has taken me 2 days to finally figure out that the leftmost tab is more or less randomly labeled (ok, ok, I know there's logic behind it, but it took me 2 days to figure it out--sort of--). Some of the labels used are not consistent with standard conventions. And the behavior isn't always consistent with standard conventions.
The "edit" tab should be changed to be the "edit this page" tab. Please. -- The Anome 18:11, 5 Jun 2004 (UTC)
Consistency of text in left-most tab. Right at the moment (for me) it says "message". I don't want to send or leave a message, so I'm never going to click on that tab. I'm not even sure what it does, although I *suspect* that it displays the current version of this page. I don't know why it doesn't say "current". Sometimes it says "about", sometimes "article", sometimes "special", sometimes all kinds of things, none of which mean anything in particular to me. I suggest that, if you're in editing mode, it should always say "current" or "article" to display the current version of the page. Do I or anyone else care whether the article is a special article or some other odd-case kind of article? No. I just want the current version.
Word choice for left-most tab. "About" should always display the name of the software and the current version. That's by standard convention under Mac and Windows and I think X interfaces, too. "Message" should always allow you to type an instant message or email message. There's no reason for either of these text choices to be used except with those meanings.
Behavior of tabs: Tabs in standard interfaces switch back and forth among different displays. So, at the moment, the Discussion tab is current for me. If I click one of the other tabs and then click Discussion again, I should return to where I am. But I don't; I am given an *empty* Editing page. I have to use my browser's back button to get back to this edit. This is not standard behavior for tabs and it's more confusing than NOT having the tabs. Secondly, clicking the Watch tab when it appears should bring up a different display (standard tab behavior). It doesn't; it actually *performs a function* and changes the status of something (adds it to my watchlist), which is actually a little scary. It wasn't scary when it was a link that said "Add to my watchlist", but I do not expect tabs to perform functions.
I'm not even sure what all of the tabs do (e.g., the "+") because I have been thoroughly intimidated by the fact that the ones I *have* clicked do not do what I expect them to, and I don't want to be mucking things up by clicking something I don't understand. And I'm a bold, experienced computer user!
Consistency of labels for same function. Argh, let's see, when I'm displaying the article, there's a tab called View Source but not a tab called Edit. Or--wait--is it only in MediaWiki that it's called view source and everywhere else it's called edit? Huh, hang on, if I go to the discussion page, there's an Edit tab. What the heck is view source, then? I'm confused all over again.
Pop-up help messages for tabs are inconsistent. At the moment, they are:
Article/Message/Special/etc.: "View the content page". Very nice! Very consisent! Tab shld be this consistent and clear.
Discussion: "Discussion about the content page." First pop-up was a verb form (view...); this is a noun ("discussion"); make consistent. E.g., "View discussions about the content page".
Edit: "You can edit this page." Now it's chatty rather than a verb or a noun. How about "Edit this text" (so that it applies either to content page or discussio page)?
Move: "Move this page"; good simple verb form.
History: "Past versions of this page". Noun again. And not the most helpful interpretation; I think that for newcomers (and for me) the most important thing is that we can "View edit history of this text".
Angela, I think you missed the point on #3. To any user familiar with standard interfaces, it looks like a tab, and the expectation is that it will behave like a tab. Elf's observations are on-target. If they are not really tabs, then they should not look like tabs, or else confusion will result. I like the idea of using tabs to get to the various pages associated with the content page, but this implementation needs some work.
There is a somewhat complex relationship between the content page, the talk page for the content, the edit page for the content, the history of the content, the edit page for the talk page of the content, and the history of the talk page of the content. The current tabbed presentation only obscures or confuses that relationship.
The Watch option should be an option box -- as it is under the standard skin. I can't think of any way to present Move other than either as a command button (like "Save page" is now), or as a tool in the toolbox box.
There is, perhaps, a better place to put each of these individual points, but I think we're using this page right now to discuss what the English Wikipedia-specific style sheet should be like. For now, let's keep these all together here. -Rholton 19:22, 3 Jun 2004 (UTC)
Point #1 is very valid. Some more consistency would be nice, why not use 'article' for articles and 'content page' for everything else? (and 'user page' for userpages) ✏ Sverdrup 19:57, 3 Jun 2004 (UTC)
F sourceforge request] would be better. I disagree everything should be done on this page. Changing the interface text is not the same as changing the stylesheet. It will be a lot easier to do if separate discussions are kept on the correct talk pages. Angela. 20:01, 3 Jun 2004 (UTC)
I rather agree with Rholton on #3: since those things are buttons, not tabs, they should look like buttons, not like tabs. Jorge Stolfi 14:26, 5 Jun 2004 (UTC)
I agree on #3 as well, and would like to suggest something else. I believe that the "watch" and "move" tabs at the top - which are, as has already been said, not rightfully tabs - belong in the toolbox on the left. (It should also be noted that, consistency aside, they are not used very often, at least not by yours truly.) On the other hand, "What links here" and "Related changes" belong alongside the tabs of the top - it would also be nice to be able to use tabs to get back to the article, rather than "< MediaWiki talk:Monobook.css". Other than that, the new skin is truly amazing. -- Itai 13:27, 6 Jun 2004 (UTC)
The look like tabs, but they do not behave like tabs on, say Amazon, or most good sites using them. The most important thing however is that they will not in any near future behave as tabs should because of the relative slowness of the Wikipedia compared to, say Amazon. In other words, though tabs are in theory a great interface facilitator (I agree completely with Steven Krug on this and I think everybody involved with the usability issues should read his slim book Don't make me think, by the way) they should be completely scrapped for Wikipedia. There are a lot of other usability issues, and the Wikipedia should really go through some usability testing with a few think-alouds, but all this is secondary to the tab problem. AlainV 03:58, 8 Jun 2004 (UTC)
I have also been confused by tabs, and still is sometimes. I can't tell exactly why, but the previous comments certainly give good indications. There is room for improvements, but this is probably a very difficult user interface design work. Marc Mongenet 05:57, 10 Jun 2004 (UTC)
It does not have to be so in our case, since we are not a commercial site, depending absolutely on originality and perfect branding to drive all the customers to us and keep them. All we have to do is copy navigation practices on the average of good plain web sites (the average implies getting knowledge but also avoiding lawsuits that occur when you copy a single good site or two), adapt the general things to our variations and test it. Then after testing, do changes and tests again. And that's it. Web navigation design and Usability testing of Web interfaces are not rocket science. AlainV 02:07, 11 Jun 2004 (UTC)
Well, designing something that works well enough, like the current interface, is maybe not rocket science. But designing a really good interface for a site like Wikipedia is rocket science. For instance, while editing this comment, I could select an "edit" link, what does it edit? There is a "search" box with a "Go" and "Search" buttons, what does it mean? What is a "mediawiki"? Marc Mongenet 03:12, 2004 Jun 12 (UTC)
Font
Issues related to default fonts.
Font size
Kudos for using relative font sizes. Default is a small font size, however; too small for comfort. So I can change my browser settings for this site but when I then click on an external link, the fonts there are overwhelmingly large. Sure, an experienced Wiki user can change his/her skin, but most readers will be hit and run, looking for info, not to settle in and customize their interfaces. I *like* the sizes of headings; relative sizes are now much clearer between the different levels of headings and much different from body text, esp. with the hairline for the top-level headers. Elf | Talk 17:41, 3 Jun 2004 (UTC)
Mikez 09:53, 4 Jun 2004 (UTC) (what is a small font in MonoBook, is completely unreadable in Standard skin, and what is small in Standard, is ordinary in Mono... I think that's no good)
blankfaze | •• 02:31, 4 Jun 2004 (UTC) - mine is perfect
Chopchopwhitey 03:45, 4 Jun 2004 (UTC) Default size is good on Linux Firefox 0.8.
Ezhiki 20:51, Jun 4, 2004 (UTC) - looks great to me.
DO'Neil 10:05, Jun 5, 2004 (UTC) Looks excellent to me.
Jamesday 20:51, 5 Jun 2004 (UTC) It's OK for me on Windows/ IE6/ 15"/ 1600x1200 notebook, Windows/ IE4/ 21" monitor/ 1600x1200 desktop and Windows/ IE5/ 1024x768/ 15" monitor.
Gabriel Wicke 13:09, 8 Jun 2004 (UTC) - otherwise too big for the unlucky 90% or so that use IE and can't adjust font sizes really
MrWeeble 23:15, 8 Jun 2004 (UTC) - works for me (Firefox 0.8, Windows 2000, 17" monitor @ 1024×768)
Do not interfere with my prefered font size duly set in my browser settings
I think the diff font size could use some increasing as well. Dori | Talk 13:09, Jun 5, 2004 (UTC)
I withdrew my larger vote. On reflection, it's more the greater line spacing than the text size which is the issue for me. Jamesday 20:51, 5 Jun 2004 (UTC)
It's not the size that's the problem, it's the readability of the font. Restoring default browser size AND font would make pages fine for ordinary folks (since that's why browser defaults are set the way they are -- duh!) and still allow the folks so anxious to customize Wikipedia the opportunity to edit their own stylesheets. How does that saying go? "If you want to change the world, first change yourself." ☺ -- Jeff Q 05:02, 9 Jun 2004 (UTC)
The separation of votes between font-size and font-family is arbitrary and confusing. Verdana and Times Roman look like very different sizes using the same font-size setting. -- Jeff Q 06:29, 9 Jun 2004 (UTC)
To get to the bottom of font sizes, I reviewed the current Monobook main.css file and some of the references quoted in it. I found two misleading size-related statements. First, it's asserted that "browsers won't go below 9px". I don't know what this is supposed to mean, but I have no problem displaying a 7px (not 7pt!) serif font in Opera 7.23. If this is an assumption that all browsers will provide a minimum height, regardless of setting, it's apparently wrong.
Second, the referenced "www.w3.org/2003/07/30-font-size" and its reference to the CSS2 spec recommend using a font with a high "aspect value", or ratio of font-size to x-height ("lowercase glyph height", to quote yet another reference). As far as I can tell (without becoming a typography expert), the case these references make for Verdana (sans-serif) over Times New Roman (serif), which I infer were used to select Verdana as the base Monobook (and subsequently default Wiki) font, completely ignore the legibility advantage that serif fonts have (as mentioned by quota in "Font typeface" vote #12 below). The relevant passage from the CSS2 spec says:
Verdana will therefore tend to remain legible at smaller sizes than Times New Roman. Conversely, Verdana will often look 'too big' if substituted for Times New Roman at a chosen size.
The second sentence is true, but the first one is inaccurate. Verdana will tend to look bigger at smaller sizes (and, indeed, at any size) than Times New Roman, but its legibility is subject to more than just its perceived vertical height. The thinner strokes of Verdana, combined with its lack of serifs, actually make that font harder to read at the same perceived vertical height, so it's actually good and even necessary that Verdana looks bigger (i.e., has a higher aspect value). It just isn't enough. As I mention in the "Comments on Font Typeface" section, there are good reasons that all major (and most, if not all, minor) browsers use a serif font, not a sans-serif font, as their body text default. -- Jeff Q 06:41, 9 Jun 2004 (UTC)
I think changing the font size of the body of a whole page is always a bad idea. I did not notice the problem immediately because a long time ago I switched to a browser that let me override this kind of web design error... But most visitors use other browsers and visit Wikipedia only for a few minutes: this renders all argument about wikipedia user preferences, user style sheets (!) and so on, null and void. The only way to present Wikipedia in the visitor preferred font size is by not changing it. The current CSS is by construction presenting Wikipedia in a font about 20% too small. Marc Mongenet 04:48, 10 Jun 2004 (UTC)
quota Anything so long as it is a standard serif font. Serif fonts have been shown to be more readable; it’s as simple as that (check out any professional manual, or any major reference work and see what they use)
PLEASE put it back to the old font. I really really really hate this new font. And please don't tell me "change your settings" because it is much more complicated than that. Kingturtle 10:13, 5 Jun 2004 (UTC)
I may be old and conservative, but I feel stylesheets do more harm than good for users who aren't logged in. If they for some reason are to be used, then their use should be strictly limited to what is considered necessary. --Ruhrjung 17:12, 5 Jun 2004 (UTC)
Back in the days when HTML was first written, the concept was to let the user determine how she/he wanted to interpret the markup. Of course, things have changed since then, but I believe this ideal is still worth embracing -- & it would avoid the inevitable arguments over wether serif or san-serif fonts were best. llywrch 02:13, 11 Jun 2004 (UTC)
Please use the default font (and serif, if that is the default) for text. sans-serif is fine for menus and headers, on the other hand, to add contrast. —Steven G. Johnson 19:18, Jun 5, 2004 (UTC)
Serif for text (or leave as default), but sans-serif is okay for headers and menus. --Delirium 00:11, Jun 9, 2004 (UTC)
Marc Mongenet 04:52, 10 Jun 2004 (UTC) (do not change the user preference for body, but OK for isolated elements)
Arial Unicode MS for characters that are buggy in Verdana, else back to Verdana
Gabriel Wicke 13:09, 8 Jun 2004 (UTC) - best readability (designed for the web), looks better than Arial (IE and Safari users can't adjust their sans typeface). Consistent size-wise at 123%.
Rrjanbiah 06:32, 9 Jun 2004 (UTC) - Verdana is cute and best for any webpages. Or leave it to the user so that he can set it in a cookie
Comments on Font Typeface
I think I agree with Angela, though I'm not entirely sure what she means by "browser default". In IE6, if you specify sans-serif, you are forced to use Arial. That, to me, is not any better than forcing me to use any other font. IE does have a font preference, but it makes no distinction between Serif or Sans-serif. If no font (or font style?) is specified, then the user's choice is used. That's how the standard skin works. That allows me to use Arial Unicode MS, which eliminates all those little boxes, and which I now use as my "default" font for all browsing. -Rholton 18:40, 3 Jun 2004 (UTC)
My proposal is to use Verdana/Bitstream Vera for the bulk and substitute it with Arial Unicode MS (if installed) for special characters like the Combining diacritical mark range. Mozilla does this transparently already, ie would need a span in the source with a special 'troubleunicode' class. Could be done with a small regex that's searching for those byte ranges. -- Gabriel Wicke 16:53, 5 Jun 2004 (UTC)
I think I mean just don't specify anything. Angela. 20:01, 3 Jun 2004 (UTC)
Yes. Wikipedia should not be forcing any common font or any common font size on users who employ different browsers on different sizes of terminals and set their screen at various different resolutions. Some users may have visual problems and need larger fonts. The user should come first. jallan 02:21, 4 Jun 2004 (UTC)
Note that the user font size is taken into account already, somebody who increased the IE default size gets a larger wikipedia. The question is if the IE default (equals 16px) is better than our own default (122% of 9pt minimum currently). -- Gabriel Wicke 11:52, 4 Jun 2004 (UTC)
The problem is, in order to see Wikipedia clearly, I need to set the text size larger than I normally have it. When I then go to almost any other website, the letters are HUGE and I have to switch back. In other words, I have to make a specific exception for viewing Wikipedia (yes, and for a handful of other sites that I don't visit very often). Do we really want to force this behavior on ourselves, let alone on people who are just using Wikipedia as a reference? OK. Maybe IE is messed up in their font size. But IE is what IE is. You can't fix it. LOTS of people still use it, and will probably continue to use it for a long time. Many people at work, or in libraries have no choice at all.
Unfortunately there's no such thing as a font size pref in IE apart from the 'larger'/'smaller' thing in 'view' which has massive steps. IE users can't really set meaningful font preferences, so good defaults are important to them. I agree that the current size is too small after the change from Verdana to 'sans-serif' (Arial), i'm about to increase the scale factor to 127% to compensate this a bit. -- Gabriel Wicke 16:53, 5 Jun 2004 (UTC)
Verdana and Arial are about the same size for me - but to get Times to comparable character but still worse overall legibility I need to apply a 120% scaling factor. Jamesday 23:10, 5 Jun 2004 (UTC)
Isn't the MSIE default taken from the system default? IMHO a general setting for all applications is the sane way to define a prefered font size. Marc Mongenet 05:24, 10 Jun 2004 (UTC)
Maybe there are good reasons for Monobook to use fonts the way it does. I'm not a web developer. But if that's true, then we need to use some other skin as the default. -Rholton 05:47, 5 Jun 2004 (UTC)
For background on the font issues, please see [1] and [2]. The short version is that browsers do not behave consistently today and gwicke is using one possible workaround. But it's not a perfect workaround because it depends on how well the assumptions of the workaround match the specific display you're using. It's to be expected that different people will see different sizes - it's partly a browser/platform/dispaly difference. that is, it's not only people liking different sizes - people may be seeing different sizes for the same settings. Jamesday 07:24, 5 Jun 2004 (UTC)
That’s true—but it does not excuse overwriting the users’ settings... quota
The HTML math looks much worse in the new font. ✏ Sverdrup 11:00, 5 Jun 2004 (UTC)
Everything looks much worse in the new font. quota
I just verified on my suite of untweaked browsers that Opera 7, Netscape 7, MSIE 6, Mozilla 1.5, and Firefox 0.8 all use serif fonts as default body text. Forcing sans-serif on everyone as a default is not only less readable (see quota's vote above), but also overrides all popular browser defaults. I respectfully suggest that those who are so keen to make everything look they way they want it and not how it is in untweaked browsers should be the ones who have to override defaults with stylesheet settings, especially since they are vastly more likely to know how to than people who haven't customized their browsers.
Let me back off a little from my boldface apoplexy in the above comment. ☺ I can see from the references that Jamesday quotes a few paragraphs up (which are also referenced in Monobook's main.css) that the proponents of all these font changes are trying to address some valid general issues, not just making Wiki conform to their views. But the question remains, are these issues that a consensus of Wiki users (or even just contributors) have considered large enough to make these changes, and have they decided to put up with the problems such changes cause? The first rule is, "if it ain't broke, don't fix it". The less-known second rule is, "if it's broke, don't break it even more while trying to fix it". -- Jeff Q 07:06, 9 Jun 2004 (UTC)
None of them specifies no font-family, none of them serif fonts. Looks like a trend to me. -- Gabriel Wicke 20:36, 9 Jun 2004 (UTC)
Regarding the so-called better readability or serif fonts over sans serif, this is by no means clear cut. Many factors can affect readability, including print vs. online, as well as cultural familiarity with various fonts. It's been a while, so I don't have references handy, but I recall studies suggesting that in some countries where sans serif fonts were more commonly used in print, sans serif fonts scored higher in readability. In the U.S., where serif is more common in print, readability shows a bias towards serif fonts. Point is, there is evidence that familiarity with the fonts may be a more significant factor that any physiological factor related to the presence or absence of serifs aiding readability. And I seem to recall studies where serif fonts scored lower than sans serif in online readability, which was attributed to monitors not being able to display the fine lines of the serif cleanly (although that may have been before high-res monitors). older≠wiser 21:46, 9 Jun 2004 (UTC)
Note that home pages are basically made of headers, what should be considered is large blocks of content text. In the case of Amazon, it uses serif for user reviews. Yahoo uses serif for "Terms of Service" (but maybe it is to give a "legal" appearance). Marc Mongenet 05:19, 10 Jun 2004 (UTC)
Concerning Gabriel Wicke's list… So the "most popular" sites should tell us what font to use here? Well, let's see…
Yahoo: As I recall, Yahoo! News changed from serif to sans-serif sometime in the past year. When they did, they had clearly spent considerable time testing their style settings to ensure that their very well-defined, common formats for all news articles continued to look very much like news articles. I remember seeing the switch from one day to the next, and though it was a surprise, it was not nearly as disruptive as the Wiki switch was. Wikipedia (and other Wikis) have neither the single well-defined format nor the central control of format that Yahoo! has.
MSN, Microsoft, Passport: These sites have popularity mainly because they're force-fed to the vast majority of people using Windows computers. I almost never use MSIE, but every friggin' time I open it up, I find something has reset its start page to www.microsoft.com, despite my explicit changes to use no start page ("about:blank"). (I've only had this problem since 6.0.) Passport is a security site, not a content-browsing site.
Google: Google has an even more limited variety and substantial control of page content than Yahoo!.
eBay: If you want to buy or sell through online auctions, you go there, whether you like its format or not. Just read all the hollering about the recent switch to "my eBay 2.0" (which, incidentally, they did a much better job promoting and testing than Wiki). To paraphrase Ernestine the Phone Operator (Lily Tomlin), "We're eBay. We don't have to care." And again, their content is much more controlled, even encouraging sellers to use a much more limited set of formatting options than Wiki provides.
Amazon: Amazon is the eBay of media sales. 'Nuff said.
DoubleClick: Do you seriously propose that people browse this site? It's "popular" because of their $%#@*($#! ads buried in other pages. A clear case of irrelevant statistics.
Go.com: Never had any use for this. Can't comment.
OfferOptimizer: Never heard of it, but based on its main page, it sounds like another DoubleClick.
I'm sure you're not arguing that, if Wiki uses sans-serif, it will be massively popular. The fact is, sites become popular because of their content (or their viral infection rate), not because of their fonts. Common users (the ones who wouldn't know CSS from CBS) are completely helpless to affect how a site looks, and are at the mercy of the Powers That Be. If they want the content, they must put up with the format. The most popular sites will almost always be the ones who content is so critical (or so wired-in to basic computer use) that users have little choice about using it; e.g., the Microsoft Strategy that is so amply illustrated by this list.
If you're interested in Wikipedia user opinions, the vote above suggests so far an overwhelming majority want the browser default font, which is serif for anyone who hasn't customized their browser settings. Of course, one should keep in mind that this survey is heavily biased toward users who are Wiki-comfortable enough to…
… find this page. As vocal as I've been on this topic elsewhere since the switch, I only found it myself a couple of days ago.
… edit this page. Not every Wiki user is comfortable editing pages, let alone jumping into such heated discussions.
… vote on this page. I have yet to see how Wikipedians are supposed to vote. One gets impression from reading about Votes for Deletion that there is some kind of formality. I decided to be bold and just add my vote line here, without instructions or any awareness of Wiki voting etiquette. If I'm worried about it after 9 months of Wiki use, just how many casual users are likely to make their opinions known here?
If these informal Wiki votes were being done in a social sciences course, we'd flunk on our inability to recognize massive systemic biases. And I'd bet good money (if I had it) that the vast majority of non-bold and new users would prefer to keep the interface simple until they get more comfortable with the content and the practices of participating in Wikidom.
Concerning older≠wiser's point, if familiarity breeds readability preference, then serif (which all the browsers use as a default body text font) would be the logical choice unless and until Wiki spends considerably more effort testing article appearances and locks down formats and layouts like the commercial sites do. Since the latter is absurd and the former ain't gonna happen soon, I again recommend we make the old Standard skin (with its serif fonts) the Wiki default skin. This prevents no one from selecting a fancier skin or changing any skin's font or other CSS attributes, but it puts the onus of extra work on the people who are prepared for and knowledgeable about it, not those who have enough trouble just learning to use Wiki. -- Jeff Q 05:13, 10 Jun 2004 (UTC)
Details and screenshots
What we're doing currently:
we use font size keywords (x-small) on the body to establish a minimum font size of 9px (see [3]). This keeps the font size constant if the user configured it much smaller than 16px (the IE/win default that >85% of all users are forced to use).
Then we scale those 9px up to a sane base font size
Result: about 11px font size if browser setting < 14px
full scaling if font size is >= 16px
Initial setup
Keyword basesize, 123% Verdana/Bitstream Vera Sans/sans-serif
Only sans-serif specified (defaults to Arial in IE), else the same. Arial is harder to read for a given nominal size, appears at least 10% smaller. Certainly needs compensation if kept, but those using Verdana would have too big fonts then.
The main problem I've seen here is that visited edit links are the same colour as visited articles. Which means if you have clicked on an edit link it is no longer possible to tell whether the article exists or not. -- sannse(talk) 17:49, 3 Jun 2004 (UTC)
That doesn't change the problem with visited edit links I'm afraid (I have it on User:Sannse/monobook.css and still see the same problem). -- sannse(talk) 20:39, 3 Jun 2004 (UTC)
Yeah, it looked like it did, but it must have been a temporary thing (if you hit Back, it does seem to stay red on the page you return to, but if you reload, it goes to the visited link colour). Can the CSS be that finely tuned? -- MichaelWarren 20:44, 3 Jun 2004 (UTC)
The active link colour is set the same as the edit link - that's why it looks OK when you hit Back (I intend to change this on mine, and think it shouldn't be done this way on the default) -- sannse(talk) 21:21, 3 Jun 2004 (UTC)
Even worse, links to stubs below the user-defined threshold and to unwritten articles have the same red color. At least that one needs to be changed. andy 07:48, 4 Jun 2004 (UTC)
This now seems to have been fixed. Warofdreams 18:10, 4 Jun 2004 (UTC)
I'm not sure about stubs, but the other default colours were: a { color: #0000FF; } a:active, a:visited { color: #800080; } a.new { color: #CC2200; } a.interwiki, a.external { color: #3366BB; } - which is slightly different from the example mentioned above. This doesn't solve the visited edit link problem though -- sannse(talk) 16:49, 4 Jun 2004 (UTC)
Jamesday 14:35, 4 Jun 2004 (UTC) though some change for stub color is probably worth voting on later - just not the same as "completely missing article".
Tero 11:32, 11 Jun 2004 (UTC) ("Standard" skin should be the default)
That's not what the vote is about (it's just about the link colors). I don't think there is a chance that we'll be going back to that skin as a default. Dori | Talk 14:49, Jun 11, 2004 (UTC)
Don't return to MediaWiki 1.2 defaults
blankfaze | •• 02:34, 4 Jun 2004 (UTC) - I just got things how I like them!
External link icon
No icons by default
Dori | Talk 23:19, Jun 3, 2004 (UTC) (only if color changes between ext and int lks obviously)
Zigger 05:43, 2004 Jun 6 (UTC) (except for [4]-style links where I prefer a default of having it absent or inside the braces or the character ↗ inside)
Other
Angela 17:53, 3 Jun 2004 (UTC) (It depends whether the external link colour is changed.)
Elf | Talk 02:24, 4 Jun 2004 (UTC) (I like the idea of distinguishing external links. I think icon is OK. But it's confusing when everything not in the article namespace has this icon--e.g., "Edit summary" and "public domain" text on each edit page display this link, and to most people these are not external links, they're maybe help pages, so using the same icon is confusing. )
Phil | Talk 11:02, Jun 4, 2004 (UTC) (I have already suggested—to User:Gwicke who originated the idea—the possibility of having a different icon for an Interwiki link as opposed to a link which is truly external to the wikipedia project. I wonder if it would be possible to present us with a selection that we can choose in our CSS file?)
Changed the default to no styling for interwiki now apart from the 1.2 colour (that's the same for external). That should eliminate most of those icons on meta. -- Gabriel Wicke 12:09, 4 Jun 2004 (UTC)
Underlining links
I was among those who voted for underlined by default (I have since changed my mind), but now there is a bug and removing the check from the "Underline links" option does not change the behavior. Should we force it on users this way (this also seems to negate browser settings)? Dori | Talk 03:48, Jun 4, 2004 (UTC)
Yes this awful. If I want underlines on links I can set my browser to put them there. Why on earth does Wiki force the ungly things on users? Shall we change italic emphasis to all-capitals, next? And, as a next step, monospace fonts everywhere (green, on a black background, of course). quota
I wish I had known of a vote. This is disastrous! Little horizontal lines everywhere cutting through the text! AHHHHHHHH! My browser's no-underlining of links is even superceded by this! Ackbar! --AquaRichy 07:04, 4 Jun 2004 (UTC)
Me too. This also removes the hover indicator. The link colour is changed already, so the main reason (links look too similar to text) should be mostly gone since yesterday. -- Gabriel Wicke 12:18, 4 Jun 2004 (UTC)
I find hover underlining even more annoying than not having underlines at all. The skin should either respect browser defaults or the checkbox in user preferences. I think that's the only way to make people happy. -- Cyrius|✎ 19:27, 4 Jun 2004 (UTC)
Then why not just a { text-decoration: inherit } ? -- Gabriel Wicke 10:45, 5 Jun 2004 (UTC)
I tried that on meta and it went right back to the default Monobook style. Used two browsers with different rendering engines. -- Cyrius|✎ 18:29, 5 Jun 2004 (UTC)
You can override it in your user CSS. The rest of us like our underlines. -- Cyrius|✎
I doubt a site will ever cause me to change a browser preference just for it. Marc Mongenet 05:33, 10 Jun 2004 (UTC)
I don't know the css - syntax and don't really have time nor interest to learn it.
And why why why is there a preference, if it is neglected??? I don't demand you to see links whithout underbars, but since I don't like them, please let me use the possibility to get rid of them, OK?
well, regardless of the bug in the userprefs, you can fix it without learning css coz I'll tell you how. Just insert the code below at this page: User:Mikez/monobook.css.
/* remove the ugly, recently-reinstated link underlines */
a { text-decoration: none; }
a:hover { text-decoration: underline; }
My vote is that link underlining in the default skin should respect the user's
browser settings. Ditto for link colors (except of course for the external and missing-article link colors, which are not defined by the browser and so must be chosen Wikipedia.) Jorge Stolfi 13:16, 4 Jun 2004 (UTC)
I did not know of a vote either, and can find no way to get rid of the awful things. Noone in their right mind would want them, still fewer would want not to be able to turn them off... Help! Mark Richards 21:10, 4 Jun 2004 (UTC)
I'm doing something wrong, I'm sure, can you help me out? Thanks! Mark Richards 21:35, 4 Jun 2004 (UTC)
Link colour changes
Its good that the underlining has gone out of the monobook format. However, the blue has gone back again to being light blue. It was/ is very tough to read the light blue becuase of the lack of contrast, the darker blue was much more readable. Also the continuity between words in a page will be better if the colours are closer in value ( meaning dark/light). Now the continuity is not there. For all these reasons can we have a dareker colour please?
Is it under discussion? Can we have a page in which all the changes are recorded for the four major schemes when a change is made by the developer/ user who makes the change so that we can give our comments? The reactions are very scattered and no one seems to counterreact for any reaction. KRS 11:17, 10 Jun 2004 (UTC)
P.S. the top tabs are of a darker blue with a good contrast. Either the same shade can be used(it looks like cobalt blue/slightly like ultramarine blue)in the place of all the lighter blues or if a different one is required then Prussian Blue can be used. Or the top tab can be the lighter blue( there is very little of it, only a few words) or Prussian blue and the rest can be the colour which is now the top tab colours.
Ideal design - Background Vs. words should have the most contrast, non linked words vs linked words should have a contrast that does not affect too much the continuity of the reading process and is lesser than the background vs. words contrast.
What exists now- background vs. link contrast- too less, link word vs. ordinary word contrast too much. KRS 11:31, 10 Jun 2004 (UTC)
Color of non-main namespace pages
Should non-article pages have a different background color than articles?
(Non-article = talk:, as well as user:, wikipedia:, special:, MediaWiki:, template:, category:, and their talk pages)
yes
mav 00:58, 4 Jun 2004 (UTC) (this is needed to establish more differentiation between content and metadata and help ensure our article count is not inflated/polluted by pseudo-namespace pages like Sandbox:maveric149).
Elf | Talk 02:21, 4 Jun 2004 (UTC) (I don't know that I care what color--except that gray with current scheme for rest of page would be wayyyy tedious.)
This might be a reasonable use of css for users who are not logged in, and generally uninformed on Wikipedia, if it de-emphasizes links to non-encyclopedic destinations. --Ruhrjung 17:20, 5 Jun 2004 (UTC)
Yellow color is ugly. If you have any color, please make it something more tasteful. Latitudinarian 02:22, 4 Jun 2004 (UTC)
This vote is not a vote for any particular color (see below for that) - it is a vote to have non-articles be different color than white. --mav 04:05, 4 Jun 2004 (UTC)
I much prefer the new style. MUCH! If a colour change is made, users should have the option to keep it how it is now. blankfaze | •• 05:40, 5 Jun 2004 (UTC)
If the implementation stays the same, you would be able to set all background colors to what you like most in your user.css. So users wo really don't want to see a difference between articles and others things ;-) would be able to set them all to white. -- till we ☼☽ | Talk 09:21, 5 Jun 2004 (UTC)
If they did have a different color:
Color everything that is not an article yellowish, again
mav 21:53, 5 Jun 2004 (UTC) (I think light blue would work better for the MonoBook skin - plus lots of people did not like yellow. See Lupo's great example: at meta:Image:Wp-lupo-talk-screenshot.png)
A question only: will blue make links hard to see?--TreyHarris 03:24, 12 Jun 2004 (UTC)
Color everything that is not an article light gray
Comment only: if light gray is chosen, the color for the autogenerated edit summaries on RC will have to be changed (it's a light gray currently, and thus won't be readable anymore.) Lupo 10:03, 4 Jun 2004 (UTC)
In 1.2 I never saw a difference in color between the namespaces. It may be my monitor settings. Maximus Rex 02:15, 4 Jun 2004 (UTC)
I eventually did, but didn't realize it had a meaning until somebody explained it to me. -- Gabriel Wicke 12:25, 4 Jun 2004 (UTC)
Me too. Never really noticed it, and even after I knew it was there it was too subtle for me to take advantage of. I guess that means I don't really care. What I would like (though it not a big thing) is for the Edit page preview to be somehow very clearly marked as a preview 'throughout the page'. Too many times I've forgotten to save when I follow a link in the preview page somewhere. -Rholton 05:57, 5 Jun 2004 (UTC)
Category page color
Should be the same color as other non-article pages
Should be the same color as article pages
TreyHarris 02:00, 4 Jun 2004 (UTC) Categories are part of the content, not an ancillary. I'd also be okay with a third color.
blankfaze | •• 05:38, 5 Jun 2004 (UTC) same colour.
Yet a third color (suggest one if you like; not part of poll)
Ellywa 05:23, 9 Jun 2004 (UTC) seems usefull, in order to discourage inexperienced users to add lots of text.
Images
Get rid of user.gif
I don't know why but the little person icon bugs me. It ought to go. When I see something like it on a web page, I brace myself to see some links titled "Solutions", "Partners", etc. --Yath 10:06, 5 Jun 2004 (UTC)
Please have the server insert HEIGHT and WIDTH tags for images so the page doesn't jump around when it is loading. --Juuitchan
Note: copied from Village Pump by anon user.
The fact that MediaWiki:Monobook.css only does a difference for logged in users
Try it yourself. Log in, and links are underlined, log out, and they are not. This is useless, I think we should give up changing the default skin if we are not changing it for everybody, it's just silly to log in and discover 20 small tweaks that make the overall UI much better. ✏ Sverdrup 07:54, 4 Jun 2004 (UTC)
Hey, I didn't know that! If that's what it takes to get rid of the underlines, I will not log in on en: ! Mikez 09:53, 4 Jun 2004 (UTC)
Rather, there is another option for me, I'll keep the standard skin from now on. \Mikez
It can be turned off too. For instance, if you want to turn it off in just the toolbar, try
.pBody a { text-decoration: none; }
Similarly, if you want to turn it on only in the body (assuming they remove the stupid global forced underline), you can put in this:
#bodyContent a { text-decoration: underline; }
I hope variations of this are obvious. --ssd 04:58, 8 Jun 2004 (UTC)
I expect that this will eventually change to reflect the decision here, since we are trying to decide what that default look should be. Jamesday 20:30, 5 Jun 2004 (UTC)
I thought the underline stuff was suppose to be in a user preference? Is there any chance this could actually be implemented? Maybe turning the preference on/off just drops a line in user/monobook.css ? Anything would be better than forcing this on everyone globally. --ssd 14:30, 6 Jun 2004 (UTC)
Reduce the white space in tables and the side bar
Monobook's line heights are just too big in tables and in the side bar. Reducing them to 1em or 1.2em gives a much better layout. Lupo 09:08, 4 Jun 2004 (UTC)
Agreed that the line spacing is too great. Jamesday 20:39, 5 Jun 2004 (UTC)
They look OK to me. But there is a spacing problem in thumbnail captions; here's an example (a screen capture so you can see what I see). Huge space between 1st and 2nd line but there is no break in the actual text, it's wrapping.
[[Image:MiniDachshund1 wb.jpg|thumb|right|Black and
tan Miniature smooth-haired dachshund]]
Also--how did we end up with those rectangle thingies as magnifying icons? I thought that the vote a month or so back preferred the magnifying glass? Elf | Talk 17:54, 4 Jun 2004 (UTC)
Amen, I didn't even work out what the rectangle thingies DID for a week or so! Magnifying glass much more intuitive for new users
Would much prefer a magnifying glass as well, for reasons stated above - siroxo 03:27, Jun 5, 2004 (UTC)
I think the new icon look SO MUCH BETTER. the magnifying glass was SO ugly. blankfaze | •• 05:32, 5 Jun 2004 (UTC)
I like the new icon too. It's obviously a maximise icon... --Frankie Roberto 13:35, 5 Jun 2004 (UTC)
The new icon is clearly a flowchart diagram with a single action that loops unconditionally. (that is to say, I liked the magnifying glass better). -- Wapcaplet 19:54, 5 Jun 2004 (UTC)
The votes on the images can be found at Meta:Thumbnailed images archive for the overall appearance and Meta:Thumbnailed images/Feature Poll. Preferences for white (same as page) or pastel (different from page) border color were 50-50 split; the icon for the link to image description page is the one being used, a magnifiying glass for a "bigger version" of the image was favored but "bigger version" isn't implemented. Jamesday 20:39, 5 Jun 2004 (UTC)
Interlanguage links back at the top
I find having the interlanguage links at the bottom of the sidebar a nuisance. Part of Wikipedia's strengths is the fact that many articles exist in several languages, and we should emphasize on that, not hide it! (I usually have to scroll—and I have a big screen!— to see them.) It would be relatively easy to have them back at the top of the article, either above the top "tabs" or just below them, but above the first header. Lupo 09:08, 4 Jun 2004 (UTC)
Also: how many different language wikis do we have? 100? 150? We need a system for langlinks that scales well. I don't think the current sidebar solution works well at all with more than 10 langlinks ✏ Sverdrup 10:06, 4 Jun 2004 (UTC)
At the bottom, below any categories or other article content and metadata, would be good. The left column spot is too prominent. Jamesday 14:35, 4 Jun 2004 (UTC)
I like them vertical, when they're horizontal they're a mess. Dori | Talk 18:06, Jun 4, 2004 (UTC)
Agreed, but perhaps the developers should develop a way for users to select which method they like better. blankfaze | •• 05:32, 5 Jun 2004 (UTC)
I like them in the sidebar and would hate to have them back at top. Some articles have dozens of languages linked, meaning users with low resolution monitor settings would have half their first screen being a list of links to different language versions of the article. --mav 04:35, 12 Jun 2004 (UTC)
No printable pages
It appears to me that the option of printable pages has disappeared. They also appeared to be the most saveable pages (if I wanted to save the article). Not popular enough? - Nilmerg 11:59, 4 Jun 2004 (UTC)
WHen printing it switches to print automatically. What do you think of the option of offering "simple layout" and "high contrast/accessible" versions? Jamesday 14:35, 4 Jun 2004 (UTC)
Better now
Now that the blue is darker, it is much better. However, the contrast between unvisited and visited links is almost nonexistent, the violet has to be made darker or a different hue altogether can be tried.
By the way, what's with the underlines for links suddenly appearing and as suddenly disappearing? KRS 13:20, 4 Jun 2004 (UTC)
You can change the colour of all links with User css, which I think is the right idea. I think that rather than make a bunch of unilateral changes to the code, we should stay with what we have now, and develop tutorials on User css customisation. blankfaze | •• 05:30, 5 Jun 2004 (UTC)
Yes, using User css to change colors is the right idea. But that is inconsistent with leaving things as they are, which changes colors, underlines, etc. without using User css. The default skin -- the one that non-logged-in users and new users will have -- should override as few as possible of the user's pre-existing settings. Why mess with underlines at all in the default skin? Let the user's settings prevail. Maybe we shouldn't even mess with link colors by default, or at least keep normal links (visited and unvisited) in their browser-setting colors
User css customization should never never never be used as an excuse. What is important is the default behavior for occasional visitors that don't know what wiki, CSS or even Wikipedia is. Marc Mongenet 05:48, 10 Jun 2004 (UTC)
Section editing
While section editing is really convenient for serious contributors, they are distracting for people trying to read the encyclopedia. Not only do these people have keep reading "edit," attempts to copy/paste the text will also copy in the edit link. A serious contributor is most likely a user and and serious reader is most likely not logged in. Please do not make section editing available for anons. --Jiang 21:44, 4 Jun 2004 (UTC)
A valid point, but I'd worry then that casual users would be less likely to add to a section or make a small correction. The section edit feature makes it more likely that they'll contribute knowledge to the encyclopedia, since its so convenient to click on when reading a section. Maybe there is a better way to implement this while still allowing copy/pasting of multiple sections without retaining the "edit", but I think its a good feature. siroxo 03:25, Jun 5, 2004 (UTC)
What would really be cool is if the default behavior for double-clicking on the article would open the clicked-on section for editing. Editing the entire article could only be done by using the Edit button/tab. -Rholton 06:22, 5 Jun 2004 (UTC)
I strongly agree with Jiang on this one. Dori | Talk 12:15, Jun 5, 2004 (UTC)
Me too. Those EDIT links all over the place are dreadful. Tannin 16:23, 5 Jun 2004 (UTC)
Does anyone else feel that the edit link is in the wrong place. I expected the edit link to be at the bottom of the section, rather than at the top. Whilst the link is next to the header for that section, the header is underlined, creating the feeling that the link is for the section above it. It's also a lot more natural to read a section, spot a typo/mistake, and then click edit, rather than having to scroll back up to the top of that section. --Frankie Roberto 13:40, 5 Jun 2004 (UTC)
Yes, I've been bitten by that too. Though I'd prefer it to be at the bottom, I think it'd be an improvement to at least have the link an em further down:
*.editsection { position: relative; top: 1em; }
I know this goes beyond CSS, but I would like a div element containing the whole editable section. (Actually, most of this section would need changes in the HTML too.)
Edit/history/watch etc. on bottom
I am REALLY, REALLY happy with the new Monobook skin and MediaWiki 1.3, especially after instituting several User css changes. I like the skin, I like the font changes, and like the new features.
However, there is one nagging problem that I have.
In the old software, there was edit/history/watch/whatlinkshere links at the bottom and side of the page. Now they're at the top only. I would really like to see these links at the top, bottom, and side, or AT LEAST at the top and bottom.
I've found often that when reading an article, especially long ones, I find myself looking intuitively for the link at the bottom. This is a small problem, but a nag nonetheless.
Anyone else have feeling on this? blankfaze | •• 05:37, 5 Jun 2004 (UTC)
One of the most common things I've seen pop up in user CSS and JS is the bottom tabs available on meta. -- Cyrius|✎ 06:27, 5 Jun 2004 (UTC)
Oh, duh, I'm aware of that, but it's ugly. It looks weird. I dunno why. I'm ALL ABOUT stuff looking good. blankfaze | •• 23:30, 5 Jun 2004 (UTC)
One important consideration in the new skin system is cacheability: multiple skins should be based on the same (cached) xhtml, the markup should be as slim, semantically meaningful and flexible as possible. Duplicate ui elements would mess up the no-css/handheld/mobile version, increase page size and would need to be hidden in many skins. You can style the links as you like and place them wherever you like (just change the element the script drops the tabs to). -- Gabriel Wicke 13:09, 8 Jun 2004 (UTC)
I really do miss the bottom links ( side I could do without, either way). Since I'm not a large CSS user at all... would have trouble putting them in myself. I at least, miss the links. Lyellin 09:59, Jun 9, 2004 (UTC)
Put the background color in the main namespace back to the non-white color it was before
Yes
The white background hurts my eyes. Kingturtle 10:23, 5 Jun 2004 (UTC)
Pure white is bothersome to a lot of people. Toning it down could be an option - preferably using a small fake paper/parchment background. -Stevertigo 23:18, 5 Jun 2004 (UTC)
I'm not getting the new look!
I was looking for a place to ask about this - finally I've found one! I have seen a new style page, when I logged in to Wikipedia from work or from the local library - but it is inconsistent. Sometimes you get it, sometimes you don't.... What's going on? I assume this is to do with a new stylesheet that you're trialing - is there any info posted anywhere?
For the record, I'm logged in at home using Safari 1.2 on Mac OSX 10.3.2. At work inevitably they use Internet Explorer on Windows ('98, I think).
If it is a Mac OSX compatibility issue, perhaps Mac users ought to have the opportunity to comment about the so-called "new look" - at some point!
It's not a Mac compatibility issue. The issue is probably that you have a skin set in your preferences that isn't Monobook, and you're seeing Monobook when you're logged out. -- Cyrius|✎ 18:19, 5 Jun 2004 (UTC)
"Obvious"
I notice the liberal use of the word "obvious" in this debate on styles. I feel compelled to suggest that the word "obvious" almost never applies in a discussion among a diverse population. When someone calls something "obvious", it nearly always says more about their own background and biases than about any universal truth. -- Jeff Q 05:29, 9 Jun 2004 (UTC)
Line spacing for lists and indents
The larger space between lines not only disturbs some text all by itself, but it has secondary effects as well. The 1.3 software apparently changes how ends-of-line and blank lines are handled. Under 1.2, a newline (in the generic sense) would break a paragraph, indented line, or list item without adding extra whitespace between lines. One or more blank lines would do the same, but add a blank line between. Thousands of pages count on this formatting.
Under 1.3, the single line-break gets absorbed into the previous paragraph, for ordinary text. (I think this is bad, based on existing use, but I can see the argument for it.) However, because of the new style, indented lines and list items are properly broken but get a virtually-undetectable difference in separating space based on whether they have single break or one or more blank lines. This causes major problems for some text, like the following two dialog segments from Wikiquote:Buffy the Vampire Slayer:
Xander: I laugh in the face of danger! Then I… hide until it goes away.
Giles: Why should someone want to harm Cordelia?
Willow: Maybe because they met her?
Under 1.2, it was clear these were two separate quotes. Under 1.3, you can't really tell where the division is without looking closely or considering the context. (The confusion is even more apparent when looking at a long list of these quotes.) I used this Wikiquote example because it's compact, but List of self referential songs is a great Wikipedia example of a page whose size seemingly tripled and became horribly mal-formatted using the new software and styles. Any page that uses indented lines for song excerpts and/or HTML "pre" style formatting, and any page that counts on the difference between single line-breaks and blank line spacing is going to suffer from these problems.
This is all because someone thought that extra space looked nice using the new font that is also such a hot point of contention. Please keep the customizations and whimsical style choices out of the default style! -- Jeff Q 05:36, 9 Jun 2004 (UTC)
To me, this just highlights the fact that we really need a better structural element to use for indentation. The colon is interpreted as a dd element (definition data) which was intended for defining a term; when the colon is used without a semicolon, you essentially have a definition with no term, used purely for the purpose of achieving some indentation. Unfortunately, the only other sort-of appropriate HTML tag we have is blockquote, which is block-level and cannot be nested (which makes it useless for nested indentations like we use on talk pages). It'd work for quotations like the Buffy one above, though. (Do we have wikicode for blockquote, or does it have to be in HTML?) There's a little discussion of this on meta. I agree with you, Jeff, that whatever style attributes are screwing up the spacing should be eliminated, until we use definition lists only for things that are actually definition lists; it plays havoc with the other things we're using it for at the moment. -- Wapcaplet 17:53, 12 Jun 2004 (UTC)
Looks vs. Readability
A meta-comment: note that the graphical beauty of a document matters only when a new user opens it for the first time, and then only before he or she starts reading the text or using the buttons. After that fleeting moment, only three things matter: readability, readability, and readability.
That is why any book that is meant to be read (and not just looked at) is printed with serif fonts, black on white, with little or no decoration. Even a simple rule at the top of each page will begin to bother the reader, subliminarly, after a few dozen pages. That is why good books have "clean" page layouts, and no frames around illustrations and figure captions.
Graphical decoration is ok when it conveys useful information such as section boundaries, list items, links, etc.. However, the most efficient clues for that task are spacing and indentation, then font size and weight. (One serious problem with the current Wikipedia layouts -- both "monobook" and "standard" -- is that the spacing below sub-section headers is just as big as that below section headers.) Marking off sections with rules or color bars may already be in the negative payoff zone, more distracting than helpful.
Sans serif fonts look better than serif ones, which is why they are used in advertisements, brochures, flyers -- and their WWW equivalents. The neat looks of a sans-serif text are good at catching the attention of passers-by, which is THE main goal of avertising. However, compared to serif fonts of the same height, they are noticeably harder to read. That is not a problem in advertising, where the text has to be short and eye-catching -- but is a major problem for texts longer than a couple of paragraphs.
As I see it, the negative reactions to the monobook skin (above) are due not to locally fixable bugs, but rather to a single global problem: the skin was not designed for readability, but only to look nice. For example, the increased font size and line spacings give it a neat and "airy" look, but they also mean that less text fits in the page, which is bad. (BTW, the standard skin too wastes screen estate with all that whitespace between paragraphs.) Ditto for the subtly colored links without underlines: they make the page look cool, but make it hard for the reader to notice the link.
Whikipedia pages need not grab the reader's attention, but must be easy to read; thus they should be optimized for readability. The standard skin was already close to optimum in that regard; the only improvements I can think of are: (1) reduce the inter-paragraph space (2) reduce the space after subsection headers, (3) reduce the Wikipedia logo image to half its current size or smaller (except on the main page). Changes in other items, like like font and link colors, are more likely be for the worse than for the better.
All the best, Jorge Stolfi 00:37, 10 Jun 2004 (UTC)
I completely agree with this comment (except for "Whikipedia":-). Marc Mongenet 05:41, 10 Jun 2004 (UTC)
Oops! that was just a typo, sorry. (Unless it was a Freudian slip... 8-) Jorge Stolfi 05:56, 10 Jun 2004 (UTC)
Non-Monobook.css Comments
I'll admit that I don't care much for the new default look, so I excercised my freedom of choice & stayed with the old standard look. However, doing so has led to some issues:
I just noticed tonight that one feature in the Standard skin appears to be broken: when I look at the history of a page, changed words are no longer in red type. Where do I report it, & is anyone looking at bugs in non-Monobook skins? (If need be, I will figure out what is broken, try to fix it, & if successful, send the fix to the proper mailbox.)
Is there an explanation of how to roll my own skin for Wikipedia? A look at the article "Skins" on meta.wikipedia.org is nothing more than a discussion of various proposed skins for Wikipedia.
I love the new skin, but I've also grown to love having the quickbar
on the right side. Is fixing this feature planned? Or is it not being implemented for some specific reason? --Danny Rathjens 09:00, Jun 12, 2004 (UTC)
Usability
Sannse and I were talking or IRC about the effect that the ability to have one's own settings might mask some site-wide problems. What is meant by this is that people find a problem, they are told to fix it in their own monobook.css, they do and they forget about it. New users are left out as they don't know about the many fixes that crop up. Ideally, the worst problems should be fixed in the site-wide file. Unfortunately, the only way for this to work out would be for people to keep having votes on changes. Also, at which point do we implement the changes that are supported? Have some of these changes been rendered moot because things have been fixed on the project-wide (main.css) file? Comments, opinions? Dori | Talk 13:50, Jun 12, 2004 (UTC)
Yes, that's a good summary of my concerns. I've seen people told to solve problems by using their own css page that really need to be done site wide. The personal pages are going to be great for changes that are a matter of preference, but we need to be careful about using them to solve other problems. It would be awful if the site looks wonderful to those in the know, and has big faults for everyone else. I think we need to look at some method of getting site-wide changes implemented quickly, perhaps by a time-limited poll to assess views and browser issues. Perhaps each poll for change could also include an option to leave the change to personal choice - so if it's considered a preference issue then it can be left to individuals to change their css page. That might help restrict the changes to ones that need to be set up and not leave us chopping and changing all the time -- sannse(talk) 14:12, 12 Jun 2004 (UTC)
This doesn't sound like a generic Usability topic, unless one's view is so narrow that "usability" is defined as a problem with Monobook.css that affects only people savvy enough:
to find this particular page ("MediaWiki talk:Monobook.css" doesn't exactly jump out at a relative newbie as the place to go when your Wikipedia pages suddenly change their appearance);
to post a complaint about a style feature; and
to edit their own Monobook.css files in response to a dismissive "fix it yourself" reply from people who talk about CSS as if it were their native tongue. (Accomodating variations in English usage and other writing style issues is a central tenet of en:wikipedia, but such sensitivity toward ordinary readers' programming skills seems to be lacking of late.)
Anyone who's gotten this far (and by now, we've probably lost 95%+ of the Wikipedia readership) might very well contribute to this very specific usability problem, but I'd be a bit more descriptive in a topic title, like "Incorporating fixes into main.css", to avoid confusing it with the more general problem.
In fact, this topic is only one aspect of a general style Balkanization, causing the mass of savvy Wikipedians to branch out into so many custom styles that no seasoned Wikipedian really notices anymore what a page looks like to the vast majority of readers. (See my recent MetaWiki posting for more.) The one saving grace is that the problem described here is limited to experienced users, but that provides its own dilemma: Since only experienced users know how to fix problems like this, are we going to expend all our experienced talent making things prettier primarily for people who already know how to adjust styles, leaving the unwashed masses behind? I would argue that that has already happened. -- Jeff Q 15:34, 12 Jun 2004 (UTC)
