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.
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)
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)
Jamesday about 144% (120% squared) instead of the 123% of x.small or 9px seems like a good test - that should be user interface medium for many people - then maybe people will ask for smaller.
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)
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)
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.
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)
Color of links
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".
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)
You can override it in your user CSS. The rest of us like our underlines. -- Cyrius|✎
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)
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.)
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 they did have a different color:
Color everything that is not an article yellowish, again
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)
Different pale background colors for each type of non-article page
Jamesday 14:35, 4 Jun 2004 (UTC) (but pale yellow if not this)
Other
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)
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
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)
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)
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)
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
Section editing should only be available for users
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/past 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)
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)
