Wikipedia:Requests for comment/May 2010 skin change

On 13 May 2010 the Wikimedia Foundation changed the default Wikipedia skin to Vector (from Monobook), and added a couple of previously-tested Usability Labs features to the default settings. These changes resulted in discussion all over Wikipedia. This RFC is an attempt to centralise the discussion. Rd232 ^talk 15:46, 15 May 2010 (UTC)[reply]

Other related discussions:

Rather than dumping all previous comments on one page, each is retained on a subpage for reference, and further discussion can take place now taking these concerns into account in a more focussed and summarising way.

Even more discussions, elsewhere:

Dissent about this RFC

This RFC was rushed through by 1 editor who ignored:

The need to summarise the problems of vector in 1 or more groups. Some of the problems were reverted by the editor who rushed this RFC.
The need to structure the RFC so that we can all easily what's happening - "supports" and "opposes" are numbered lists, brief comments as bullet list, longer ones as sub-section of "Statements".

I suggest this RFC be canceled and a new one started in a few days, after the drafting is done. --Philcha (talk) 07:59, 16 May 2010 (UTC)[reply]

Not to mention that he destroyed the archiving of VPT and VPP threads. —TheDJ (talk • contribs) 13:34, 16 May 2010 (UTC)[reply]

Further discussion[edit]

Note: there is a Wikipedia:User experience feedback page for giving individual comments back to the Usability team. This RFC is an attempt to organise editors' responses in a helpful way.

Some themes:

search box position (See also: identified issues at User experience feedback.)
search box functionality - the Go and Search buttons were removed and their functionality was supposed to be replaced by a new autocomplete interface, but the new interface wasn't actually enabled, so now it's impossible to run a full-text search of Wikipedia. Reported at bug 23558.
new logo
tabs being shrunk
visual appearance of Vector skin
the hiding by default of interlanguage links. Reported at bug 23558.
transition issues (eg loss of custom Javascript functionality, some of which can be addressed by following instructions Here)
Loss of right-click function on new tabs. (Workarounds discussed here and there). Reported at bugzilla:23490.
Various broken usability with different browsers (PS3, MacOS 9, Mobiledevices) up to unusable.
Please make bug reports on the centralized bug report page

Beta features[edit]

Why are the Beta features included as part of the default? If they are Beta then they are still being tested... QED. --Jubilee ♫clipman 22:06, 15 May 2010 (UTC)[reply]

There was a beta program which lasted more than 6 months. I read that more than 100,000 people took part in it - a huge number compared to most Wikipedia processes. Improvements were made, especially early on. I've used the skin happily for all that time. At some point, there had to be a consensus that the product was ready and was "shipped". dramatic (talk) 00:27, 16 May 2010 (UTC)[reply]

I wonder if those who tried the beta version and then went back to the old are included in that statistic. Equazcion ^(talk) 00:44, 16 May 2010 (UTC)[reply]

i wonder if those who tried the beta version and wanted to go back to the old and didnt bother to create an account and leave instead are included in that statistic. bye all, 'tis been so nice. -- .~. —Preceding unsigned comment added by 79.198.106.17 (talk) 20:11, 16 May 2010 (UTC)[reply]

If I remember correctly the retention rate was on the order of 87% or so. ^demon^{[omg plz]} 13:02, 17 May 2010 (UTC)[reply]

Special characters[edit]

In the new Vector skin, the special characters and wiki markup listed under the edit box can be inserted into the edit box by simply left-clicking on them in Firefox 3.6.3. However, this procedure will not work using IE8 in Vector. But a much more laborious procedure using the clipboard will work in IE8/Vector. Move the cursor to a position immediately to the right of the special character where the "hand" changes to a vertical bar, left-click and hold while dragging the cursor over the special character to highlight it, then use ctrl-C and ctrl-V to transfer it to and from the clipboard to the position of the cursor in the edit box. Clicking worked fine in both browsers under Monobook. Also, the warning message that you may lose unsaved edits appears even while left-clicking on a special character in both browsers, which seems counter-intuitive because this is part of the editing process. — Joe Kress (talk) 00:39, 16 May 2010 (UTC)[reply]

Works fine for me in IE8. But I do get the warning, interestingly, I don't get the warning in Google Chrome (I'm not sure if it has a navigating away warning?), nor do I in Firefox, but I might have some setting turned off. - Kingpin¹³ (talk) 16:17, 17 May 2010 (UTC)[reply]

No proper testing[edit]

I have been trying to figure out what testing was done before this sea change was made. What I keep hearing is those for the change saying "give it time," and "you'll get used to it" and "we'll work out bugs" but this should only have been done if there was a good reason to think the change was a good idea overall, which leads inevitably to the question: what made them think it was a good idea? I have looked at the usability initiative and inquired in various places such as here and it does not appear that the skin was properly tested at all. Rather, a very gross methodology of retention rate after switching was the chief gauge used. If true, this means that those implementing the change only knew that the sum total was preferred by those tested, but nothing about which features, among many, tipped the balance for retention. For all we know, the editing tools, which were bundled and presented as part of the beta, were the predominant reason for retention during testing, when now, of course, they have been added to all the skins. Maybe the editing features and search changes tipped the balance but everyone preferred the Monobook look. Maybe some other combination of the good with the bad. If the testing was really as crude and indiscriminate as this, with no assessment of the pros and cons of each features making up the total, implementing this was at best vastly premature.--Fuhghettaboutit (talk) 13:41, 16 May 2010 (UTC)[reply]

"During our initial beta testing phases, 81% of Spanish and Portuguese Wikipedia beta participants kept using the new editing interface". [1]. They measured the success rate of the beta from those who wanted to participate in it. Um, no. MER-C 06:28, 17 May 2010 (UTC)[reply]

How about they measure how many people know about the ability to go back? Most of the people did not know how to go back. Even if there was a "take me back" button or if it was explained on the page, most didn't read it and just accepted the change with grief. Feedback ^☎ 01:24, 21 May 2010 (UTC)[reply]

I have to admit that I'm curious about the "81% acceptance rate" number as well. It doesn't necessarily mean that 81% of the testers formally signed off and said that they liked the new version. Instead, another way of looking at the numbers could be that 2 out of 10 users who tried the new skin disliked it and turned it off immediately, and many of the rest couldn't figure out how to turn it off (or didn't care). Are there actual numbers or comments from users who actively liked the new skin, or how is this 81% number being determined? --El on ka 01:44, 21 May 2010 (UTC)[reply]

The "initial beta testing" was the opt-in phase - the beta was turned off the same way it was turned on, so I doubt there were very many people who couldn't figure out how to turn it off. In any case, saying that they "turned it off immediately" is reading more into the data than is there. The data does not say how long they used it before disabling it. It could have been 30 seconds, it could have been 30 days. More than 220,000 users on the English Wikipedia tested the beta in the earlier stages, so "those who wanted to participate in it" was not an insignificant number of users. The reasons people disabled it were recorded here. Mr.Z-man 03:29, 3 June 2010 (UTC)[reply]

Search box[edit]

Actually, is there ANYONE who wants it on the right side? Put it back please! -- Georg Scholz -- —Preceding unsigned comment added by 86.59.86.242 (talk) 15:13, 13 June 2010 (UTC)[reply]

Put it back on the left! >:( —Preceding unsigned comment added by 70.67.235.79 (talk) 17:31, 20 May 2010 (UTC)[reply]

Given that "most wikis" (including WP in other languages) seem to have it in the left hand column, why be different? Jackiespeel (talk) 18:00, 17 May 2010 (UTC)[reply]

Most wikis are that way because they're for all intents and purposes based on this wiki. Equazcion ^(talk) 18:06, 17 May 2010 (UTC)[reply]

The current position is horrible. It's practically hidden in the upper right away from the more commonly used links. I'm not some reactionary either; I don't mind most of the new changes and even like some (like the improved editing toolbar). I just think the wikipedia overlords "fixed" something that didn't need fixing. Dude2288 (talk) 19:38, 17 May 2010 (UTC)[reply]

And because they figure the best place to put the most used navigational feature is next to the navigational links. Also because because it's a very convenient location. Also because that's where people are used to having it. In short PUT IT BACK. —Preceding unsigned comment added by 76.76.204.2 (talk) 19:28, 17 May 2010 (UTC)[reply]

I agree, I would really like to see it moved back to the left. --Kurr 21:33, 17 May 2010 (UTC)[reply]

It's just obvious, isn't it. Global navigation is all in the left column. Account navigation is along the very top, and page-related actions sit atop the page. By logic, the search box where it is now should search the current page only. This makes no sense. — Pretzels^Hii! 23:42, 17 May 2010 (UTC)[reply]
I keep hitting my Qui icon almost every time I go to press the search button... Minor issue, I guess, in the bigger picture, but another annoyance nonetheless --Jubilee ♫clipman 23:58, 17 May 2010 (UTC)[reply]

Also, I don't know if this is resolution-related, but search suggestions get cut off at the right. Type "list of prime ministers" or "piano concerto" to see what I mean. If you want to click on the correct suggestion now, you first have to scroll sideways. --Steerpike (talk) 15:25, 18 May 2010 (UTC)[reply]

I noticed that and I have a very wide screen: 16:10 @ 1680 x 1050. Tried 1024 x 768 and several others it still cuts all the suggestions off. Often very unhelpful when you end up with such as "List of Twenty20 International [...]" e.g. after searching for "list of twenty20", say. --Jubilee ♫clipman 21:04, 18 May 2010 (UTC)[reply]

I agree that the search box should be moved back to the left side of the page. Directly under the Wikipedia logo or under the links in the left sidebar are both great locations. Alphabet55 (talk) 19:56, 18 May 2010 (UTC)[reply]

The location is imbecilic. Something like 99% of the time, users come to the main page with a definite query in mind and the rest of the page is irrelevant, if not distracting. The search box should be big and right under the logo. Get a clue from Google. Would their first page be as successful with a teeny cramped search box in a random corner of the page? —Preceding unsigned comment added by 209.209.211.233 (talk) 00:15, 19 May 2010 (UTC)[reply]

I'll support a return to left bar. ... (talk) 05:34, 19 May 2010 (UTC)[reply]

The left bar system "works" (even for Conservapedia).

Why should English WP different to "all other languages" (including the hiding of other languages options): as it is it does not even say "search."

Suggestion/compromise - Yahoo email exists in two versions - classic and updated which can be alternated between according to taste. Could something similar be adopted here? Jackiespeel (talk) 15:59, 19 May 2010 (UTC)[reply]

I agree that the search box is in the wrong place. It also gets moved around if you open WP in a windowed (firefox or IE) session. Try squeezing the width right down & the tabs at the top & the search bar get moved into all sorts of strange places around & behind the logo. Is it supposed to do that ? —Preceding unsigned comment added by Leamphil (talk • contribs) 12:48, 20 May 2010 (UTC)[reply]

The search box had been in the left frame for years -- as long as I can remember. Why was it moved at all??69.76.216.0 (talk) 20:18, 22 May 2010 (UTC)[reply]

The shifted search box seems to be the principle/only cause of annoyance - and as for the other changes the only other one noticeable are the little triangles to expand menus on the left hand column.

The search box position is another example of the QWERTY keyboard issue - it has become established and thus becomes difficult to change. Jackiespeel (talk) 15:23, 20 May 2010 (UTC)[reply]

How has it "become established"? The old position was equally established, it seems. And what's QWERTY got to do with it? --Jubilee ♫clipman 17:59, 20 May 2010 (UTC)[reply]

QWERTY is actually an interesting analogy. The original design of keyboards was for manual typewriters, and commonly used letters (such as T and E) were deliberately placed further away from the home finger position, to slow typists down, and keep keys from sticking together if the typists went too fast. With the advent of electric typewriters and keyboards, this "slow them down" tactic was no longer needed, but everyone was so used to typing on a QWERTY keyboard (named because those are the letters in the top row), that it became near impossible to switch to something more efficient, such as a Dvorak keyboard. In the case of the MediaWiki search box though, I don't think it's the case that people want things on the left just because "they're used to it". I've also seen many thoughtful reasons for why the lefthand search box is better: It's next to the other menu items, it's closer to the logo, people's eyes naturally track from left to right, etc. I have yet to personally see data which proves that the top right position is so much better, that it's worth all the angst to force people to switch. My own opinion is to use two search boxes: One at the left, one at top, and maybe even add a search box to the bottom of the page too. There's nothing wrong with providing people multiple ways to search the project. But just saying "Top is better, so we're deleting the lefthand search box", does not appear to have been the correct decision. It's dismissive of established practice, and is causing frustration to many users who prefer their search box on the left. I honestly don't understand why a decision was made to try and force everyone to switch to a topright search box. Like, "Vitamins are good for you, so we're going to force you to take them, like it or not!" --El on ka 01:53, 21 May 2010 (UTC)[reply]

The top right location for a search bar is pretty a de facto standard on websites and software (I've just done an informal survey, so I'd like to examples if this is denied). When I first started using Wikipedia, the left side location of the search box was extremely annoying to get used to; it's new position is coincident with all the other search boxes I use, and is much preferable. As far as I can see, the resistance to it's new position is merely resistance to change, and not anything else. 217.28.13.31 (talk) 04:22, 21 May 2010 (UTC)[reply]

I guess your informal survey didn't include Google (check also Google Books, Google News), Britannica, or nytimes.com ... --El on ka 04:44, 21 May 2010 (UTC)[reply]

Not to mention Amazon, AltaVista, Yahoo!, eBay, Bing, Cambridge Dictionaries Online HMRC... And my Chrome browser put its "search history" box at the left. Hardly conclusive proof that top right is the "norm" then --Jubilee ♫clipman 09:20, 21 May 2010 (UTC)[reply]

Er, so I note first that all those sites have the search bar at the top. Secondly, I note that the majority of those sites have search as their primary purpose, so they inevitably have it in the centre as the primary focus. Either way, none of the sites have the search bar mid-left. (And to be honest, I would regard HMRC as top right.) 217.28.13.31 (talk) 15:31, 21 May 2010 (UTC)[reply]

The QWERTY explanation described above is what I was referring to.

Perhaps a rephrasing of the search-box placement discussion is 'For many wikis (including WP in languages other than standard English, including Simple English), it is on the left-hand side under the logo. For many non-wikis the searchbox is top right - but a significant proportion adopt left column 'or a variety of other places.'

The rest of the changes seem to generate few comments (more getting used to the new system).

Why is there no global/all languages changeover of the placement? Jackiespeel (talk) 15:59, 21 May 2010 (UTC)[reply]

Because the new software is being deployed in a staged approach. Other wiki's will be switched over in the near future. —TheDJ (talk • contribs) 17:08, 21 May 2010 (UTC)[reply]

Who exactly is the decisionmaker on the placement of the search box? It would be nice if they would engage in the discussion, otherwise there's a perception that they're just making arbitrary decisions, and aren't much interested in feedback. --El on ka 17:39, 21 May 2010 (UTC)[reply]

Oh no... that means Wiktionary's searchbox is going to end up in the same crazy place.... unless they have an even crazier place like along the right hand side pointing top to bottom so you have to write words vertically...? --Jubilee ♫clipman 18:51, 21 May 2010 (UTC)[reply]

You'll get used to it. —TheDJ (talk • contribs) 19:00, 21 May 2010 (UTC)[reply]

Probably. They just need to deal with the fact that searches get cut off when the article name is particularly long. At least Chrome now gives me the search at the bottom of the list (must have taken them a while to catch up with the lesser used browsers, either that or the Google team forgot to press a button till recently) --Jubilee ♫clipman 19:36, 21 May 2010 (UTC)[reply]

It's not Google. It was fixed by MediaWiki developers. --Amir E. Aharoni (talk) 09:45, 22 May 2010 (UTC)[reply]

move back to leftside and give back ability to search I used to be able to choose 'goto' or 'search', now it's only goto. I usually do not want to go directly to an article. Thanks. --Shuki (talk) 22:04, 22 May 2010 (UTC
- Yes, There are times that I want to search a phrase - not go directly to an article of that name - and this is not possible with the vector configuration. LadyofShalott 23:09, 24 May 2010 (UTC)[reply]
  - Actually, they fixed that issue a few days ago. (I think it was on May 20th or 21st.) Choosing "containing..." from the bottom of the dropdown box will do the same thing as the Search button in the old layout. They also made the dropdown box expand to the left so that the suggestions no longer run off the edge of the screen. Brian the Editor (talk) 15:25, 25 May 2010 (UTC)[reply]

soooooo annoying on the top right... (anon.) —Preceding unsigned comment added by 122.107.247.154 (talk) 11:22, 25 May 2010 (UTC)[reply]

Yes. Please please change the search box to the left. Thanks. Raffael —Preceding unsigned comment added by 212.41.200.97 (talk) 08:55, 14 June 2010 (UTC)[reply]

Fog[edit]

Currently, at the top of the pages the lines now seem to disappear in some kind of fog. Is this now the compulsory style, or can I select a different 'skin' to avoid seeing this foggy phenomenon? Bob.v.R (talk) 00:18, 18 May 2010 (UTC)[reply]

Agree. I like the new skin for the most part, but the fog at the top needs to go. It makes me think my glasses are dirty. Lovelac 7 12:04, 20 May 2010 (UTC)[reply]

Two skins[edit]

By now most editors should be well aware how to switch their environment back to normal. But the readers will still see it in vector, right? (it's wrong, but I suspect that resistance is futile). So the editors need a simple tool to preview articles as they look in vector without logging out or running two accounts or other cumbersome workarounds. Slap me if it's already been done. East of Borschov (talk) 10:06, 18 May 2010 (UTC)[reply]

It is called "useskin=" Monobook & Vector. P.S. We have 9 skins of course, not 2. —TheDJ (talk • contribs) 11:03, 18 May 2010 (UTC)[reply]

It took me a full 30 seconds to figure out what had happened after pressing the first link! Now I have figured it out: Thanks DJ, that's really useful! --Jubilee ♫clipman 20:25, 18 May 2010 (UTC)[reply]

Aha! give me a couple more years, I'll memorize the full path :)). But articles, indeed, appear different - it's like switching from a 1600x1200 screen back to 1280x1024. East of Borschov (talk) 05:54, 19 May 2010 (UTC)[reply]

The thing is, the old monoskin looks different now also. So that has been changed as well. It has a new color, for example, that is much like the new vector skin. Xtzou (Talk) 22:08, 19 May 2010 (UTC)[reply]

I'm not aware of any color changes to monobook. —TheDJ (talk • contribs) 23:12, 19 May 2010 (UTC)[reply]

Shift button behaving strangely (bug?)[edit]

Resolved

Another thing I have noticed (might be a bug my end, of course) is that when I try to write anything in the edit summary but press Shift I get knocked out of the box. E.g. this time tried to write "I noticed that" and it took several goes before I could actually get a capital "I". It doesn't happen every time for some strange reason and other boxes are affected also e.g. the searchbox --Jubilee ♫clipman 21:09, 18 May 2010 (UTC)[reply]

Please state which browser + version you use. —TheDJ (talk • contribs) 23:13, 19 May 2010 (UTC)[reply]

Google Chrome 4.1.249.1064 (45376) I keep meaning to check it out in IE8 and FF3 but haven't got around to it. Probably a bug, TBO. Also: Windows Vista Home Premium SP2 (yeah... I know...) --Jubilee ♫clipman 00:26, 20 May 2010 (UTC)[reply]

Wait a minute... I think it's GoogleTrans. They use Shift to generate the translation for some peculiar reason. I'll turn off see what happens --Jubilee ♫clipman 00:30, 20 May 2010 (UTC)[reply]

All better! I turned off the Shift key down to bring up Popup? option. I'll chat with the developers when I get a chance. This section can be closed up now. Thanks DJ (again) --Jubilee ♫clipman 00:35, 20 May 2010 (UTC)[reply]

end tag for "ul" which is not finished[edit]

The past few days, the W3C validation service has been reporting two instances of "end tag for "ul" which is not finished" on every page. I am using Monobook and could not find the offending markup until I realized that the service will always validate the default Vector. Looks like the <ul>...</ul> tags have only tabs in between. For a simple pages, see the W3C markup validation for User:Gadget850/blank. ---— Gadget850 (Ed) ^talk 11:55, 19 May 2010 (UTC)[reply]

bugzilla:23015 —TheDJ (talk • contribs) 23:08, 19 May 2010 (UTC)[reply]

Thanks— I had searched but didn't see that one. ---— Gadget850 (Ed) ^talk 02:59, 20 May 2010 (UTC)[reply]

Remove "del/undel selected revisions" from page histories?[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

moved to WT:REVDEL#Removing revdel from page histories and contribs lists? rʨanaɢ (talk) 15:28, 20 May 2010 (UTC)[reply]

Is it possible (through a gadget or some such) to remove the checkboxes and "del/undel selected revisions" button that appear in page histories for admins? Deleting individual revisions is not something I for one do on a daily basis (and if I need to do it, I know how to do it the old-fashioned way), and all the boxes feel cluttersome for me. rʨanaɢ (talk) 21:42, 19 May 2010 (UTC)[reply]

I agree. Also, deletion of individual revisions requires a great deal of caution so as not to break the attribution history, so the practice is not something that we should encourage too much (making it this easy to perform has that effect). -- Black Falcon ^(talk) 05:36, 20 May 2010 (UTC)[reply]

This is not directly related to the new skin—the same thing appears in other skins and on wikis that have not rolled out the Usability Initiative's changes. That said, I would not object to moving the RevisionDelete feature a click away, as it is a lot of clutter on high-use pages for a relatively low-use activity. ~ Ningauble (talk) 12:39, 20 May 2010 (UTC)[reply]

Hm...does anyone know where the right place to raise that suggestion would be? Bugzilla, or contacting the developers directly? rʨanaɢ (talk) 15:13, 20 May 2010 (UTC)[reply]

Never mind, I just found WP:REVDEL; will copy this over to there. rʨanaɢ (talk) 15:25, 20 May 2010 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Collapsing sections on leftside[edit]

I think this is annoying. On user pages, I use 'user contributions' a lot and no forced to look for it in 'toolbox'. What's that? On article pages, I like to see the interwiki links that show how international a subject really is. --Shuki (talk) 22:08, 22 May 2010 (UTC)[reply]

Is it possible to set what section we want to be always collapsed/expanded? (some user js/css?) Helder (talk) 20:06, 24 May 2010 (UTC)[reply]

You can turn it off at Special:Preferences → Appearance → "[ ] Enable collapsible left navigation menu". Amalthea 13:00, 26 May 2010 (UTC)[reply]

Previewing the content of subcategories[edit]

Before the skin change, it was possible to preview the content (category pages only) of subcategories. For example, someone who arrived at Category:Contents could click on the "[+]" link next to Category:Featured content and check its contents. Would it be possible to return this functionality? Thanks, -- Black Falcon ^(talk) 19:55, 27 May 2010 (UTC)[reply]

That's an unrelated issue, see WP:VPT#What's happened to "categorytree"?. Amalthea 19:56, 27 May 2010 (UTC)[reply]

Disabled, huh? That's unfortunate... Thanks for clarifying, though. -- Black Falcon ^(talk) 20:11, 27 May 2010 (UTC)[reply]

"Read"ing an image page[edit]

Hi all. With the new "Read" tab, it is apparently now possible to read an image (e.g. see File:Sri Aravan.jpg). That doesn't really make sense. I would suggest changing it to "View", but then that wouldn't work with audio files, so I'm not sure what would be the best word to use here - but "Read" isn't the correct one. (This was pointed out to me by a user/non-editor of Wikipedia when I showed him the new theme.) Thanks. Mike Peel (talk) 21:20, 28 May 2010 (UTC)[reply]

Wikipedia fails W3 CSS validation[edit]

The current version of the Main Page now has 83 validation errors, and 94 warnings, due to the Vector skin [2]. That isn't good! It's primarily due to the use of CSS like "-webkit-border-radius" and "moz-border-radius", which don't exist within the CSS standard (I believe that they are add-ons by individual browsers) and hence shouldn't really be used on Wikipedia. Thanks. Mike Peel (talk) 21:48, 29 May 2010 (UTC)[reply]

Well first of all, there were errors and warnings before. Second, almost all of this CSS is from the jquery UI libraries. Third, most problems are indeed browser specific properties, but most of those properties are actually from the CSS3 standard, and are widely used in many interfaces around the web. They are all properties that degrade very well in userinterfaces, making their usage less of a problem. Similarly, the HTML that is output atm isn't XHTML 1.1 compatible, but it is HTML5 compatible once we make that switch (last time that switch was attempted a few errors popped up, but it is imminent). We are in an active transitional state towards html5 and css3 you could say. —TheDJ (talk • contribs) 10:59, 3 June 2010 (UTC)[reply]

Extra spacing in editing window[edit]

In the new skin, there is extra spacing in the editing window that wasn't present before. Is there any way to remove this spacing so there is less spacing? Thanks. —MC10 (T•C•GB•L) 17:39, 31 May 2010 (UTC)[reply]

Spacing where ? Between elements, between glyphs ? —TheDJ (talk • contribs) 19:45, 31 May 2010 (UTC)[reply]

Mouseover Highlighting[edit]

I would like to have the controls on the top of the page to be highlighted as the pointer hovers over it, like it had been previously.Winjay (talk) 11:27, 1 June 2010 (UTC)[reply]

The only highlighting these tabs had, was the appearing/disappearing of the bottom line of the tab. —TheDJ (talk • contribs) 11:04, 3 June 2010 (UTC)[reply]

Constant switching![edit]

When I log in to my account and I try to view most of the Wikipedia articles using their links, they began continually alternating between the new Vector skin and the old Monobook one, so that one article is in Monobook while another is in Vector, despite my use of the "Take me back" function? Is there any way to disable this permanently? :| TelCo NaSp Ve :| 00:53, 7 June 2010 (UTC)[reply]

Go to Preferences then Appearance and change the Skin to Monobook. Go to the bottom of the page and hit save. That's what I did. Derild 49 2 1 18:43, 7 June 2010 (UTC)[reply]

Thx. :| TelCo NaSp Ve :| 10:29, 11 June 2010 (UTC)[reply]

Error[edit]

I constantly get an error like this under Mozilla and Opera. http://img203.imageshack.us/img203/708/errormv.png —Preceding unsigned comment added by 92.100.57.216 (talk) 14:32, 10 June 2010 (UTC)[reply]

Interwiki languages-list doesn't stay collapsed[edit]

Nope, it doesn't. The Interaction, Toolbox, and Print/export collapsible lists retain their state, but the Languages reverts to expanded every time--even on the same page. That's annoying! I don't want to see them in general, and I definitely don't want to see them if I affirmatively collapse a collapsible list. DMacks (talk) 21:49, 10 June 2010 (UTC)[reply]

Yes very annoying. I have already reported this earlier in the week, but have now made a ticket to make sure that it is repaired. —TheDJ (talk • contribs) 17:43, 27 June 2010 (UTC)[reply]