Wikipedia:Village pump (technical)/Archive 104#Coordinates are now dropping behind text

I have switched on {{code|1=My preferences | Gadgets | Appearances, Add a "Purge" tab to the top of the page, which purges the page's cache when followed.}} It produced an extra tab with drop down menu "Purge" (all right). A day later I unmarked that option. Purged. Now the Purge button has disappeared OK, but the tab is still there with no menu item (it does not open). Any ideas? -DePiep (talk) 20:17, 14 October 2012 (UTC)

:Try a skin reset: change to another skin and save, then change back to your desired skin and save. Let us know if that works. ---— Gadget850 (Ed) ^talk 04:09, 15 October 2012 (UTC)

::Did so (twice): from Vectro to Classic and back, from Vector to Cologne and back. In between aso did clean the cache. No effect: it is still there (a downward arrow). Two other such tabs are present and fine (page etc.). I'm using FF on WinXP. -DePiep (talk) 11:33, 15 October 2012 (UTC)

::FWIW: the idle tab is not present on pages with permanent protection. -DePiep (talk) 10:30, 16 October 2012 (UTC)

Is there any way to modify my .js or .css so that when I watch a page in the File: or File talk: namespace here on Wikipedia, it also watches it on Commons or vice versa? --Philosopher ^{Let us reason together.} 15:06, 15 October 2012 (UTC)

:I think User:Yair rand/interwikiwatchlist.js will do the job. Bgwhite (talk) 06:46, 16 October 2012 (UTC)

::No, that's not quite it. Basically, when I watch the "same file" on both en.wikipedia and commons. So that if I want to watch :File:Iowa.jpg, it will add the en.wikipeida file with that name to my en.wikipedia watchlist and the commons file with that name to my commons watchlist. --Philosopher ^{Let us reason together.} 07:30, 16 October 2012 (UTC)

A few days ago, all article titles (at the top of the page) disappeared from Wikipedia - at least on the Monobook I am using and the server. Is there a way to get them back? I see that they're still there on other servers. All Hallow's Wraith (talk) 07:53, 16 October 2012 (UTC)

:It works for me. What do you mean by "the server"? Are you examining the bottom of the html source to see which of Wikimedia's servers are serving a page? It usually varies between each page view. Or are you just guessing that you hit different Wikimedia servers when the page looks different to you? Or are you referring to your own normal computer compared to other computers? Try to clear your entire cache. What is your browser? Does it have extensions you can try to disable? PrimeHunter (talk) 11:56, 16 October 2012 (UTC)

::By server I mean Internet explorer vs. Mozilla firefox. Explorer is what I use. All Hallow's Wraith (talk) 22:04, 16 October 2012 (UTC)

:::It's called a browser. Monobook and Internet Explorer 9.0 works for me. I haven't seen other reports of this so it's probably an issue at your end. Did you try to clear your entire cache in Internet Explorer? Did you examine extensions? See [http://windows.microsoft.com/en-US/windows-vista/Internet-Explorer-add-ons-frequently-asked-questions]. PrimeHunter (talk) 22:57, 16 October 2012 (UTC)

Hi,

I get a math parsing error on the page Dense subgraph, but only when viewing the article directly, not when using 'preview' after editing it. Any idea what is going wrong here? 62.245.183.130 (talk) 13:49, 16 October 2012 (UTC)

: Fixed by saving again without changing anything. Maybe some caching issue? Thanks anyway. 62.245.183.130 (talk) 13:51, 16 October 2012 (UTC)

I was browsing a wiki page (North Highlands, California) and noticed it mentioned a Mr Pidcock as being a notable person from there. I grew up in that town and have never heard of him. On the talk page another resident mentioned they also had never heard of him. A web search comes up with nothing on Mr. Pidcock.

I'm wondering if there is a template to mark that reference as being of questionable notability. I found {{notable}}, but it is designed for a list, not a single inline reference.

Any ideas? Donpayette (talk) 14:38, 16 October 2012 (UTC)

:Try adding {{t|rs}}. It adds an inline note like this^{[Unreliable source?]} Ryan Vesey 14:53, 16 October 2012 (UTC)

:Thanks, that's close, but this one is un-sourced. So you gave me the idea of using {{t|citation needed}}, which is a bit closer. But I would still kinda like a {{t|notnotable}}. I'll keep looking. Donpayette (talk) 15:48, 16 October 2012 (UTC)

::I removed the material. If someone is listed as a notable citizen of a town or member of the group, and they don't have an article, they should almost always be removed. Wikipedia assumes that if you haven't received the notability threshold for an article you should not be mentioned as a notable member. There's obvious exceptions like listing the mayor of a town or superintendent of a school board etc. The material was probably introduced by someone as a joke. Ryan Vesey 16:10, 16 October 2012 (UTC)

::FWIW, it was added by an anonymous user with [http://en.wikipedia.org/w/index.php?title=North_Highlands,_California&diff=next&oldid=500065910 this edit]. Ryan Vesey 16:14, 16 October 2012 (UTC)

:::Yes agreed, just remove rubbish like that, don't mess about with templates. We get this all the time, people writing themselves or their friends into the encyclopedia. But to answer your original question {{tl|dubious}} is more appropriate than {{tl|cn}} as it implies the tagger does not believe the information whereas {{tl|cn}} is an agf request for sourcing. SpinningSpark 16:21, 16 October 2012 (UTC)

::::There is also {{tl|disputed-inline}}. SpinningSpark 16:24, 16 October 2012 (UTC)

:::::Thanks all. I learns something new every time I ask a question. Thanks, again. Donpayette (talk) 18:17, 16 October 2012 (UTC)

::::::{{tlx|notability-inline}} --Redrose64 (talk) 18:38, 16 October 2012 (UTC)

When clicking on a link to go to the section in my watchlist for VPT, I am being delivered to the wrong section. What's going on? It isn't doing nothing, like what happens when there is a template in the section heading, I end up a couple sections above where I want to be. Ryan Vesey 19:01, 16 October 2012 (UTC)

:Such things are browser dependent. The watchlist and the TOC has the same url. Your browser tries to place you at the anchor given in the url but may miscalculate the size of elements which change during page load, for example collapsed boxes. Some browsers may reposition you after the initial guess. If you click in the TOC then the page is already fully loaded so the browser knows exactly where to place you. Watchlists, page histories, user contribtuions, and anyhting else coming from another page has the same challenge. You can usually be repositioned accurately by clicking in the browser address bar and pressing Enter (I have to do that twice in Firefox because it reloads the first time). I don't know exactly why but in Firefox I currently get positioned correctly up to http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Top_10.2C000_articles, but below correct for the following sections starting with http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Vector_script_stops_responding_in_Firefox_15-16. To test this you probably have to open the links in a new tab. Otherwise it would be like clicking in the TOC. PrimeHunter (talk) 00:46, 17 October 2012 (UTC)

Can anybody please assist with the alleged problem at Template talk:Country data South Korea#Display (Template talk:FlagIOCathlete#Edit request on 16 October 2012 may be related). I don't see any problems, but apparently others do. --Redrose64 (talk) 20:52, 16 October 2012 (UTC)

Hey all,

Below is a copy of the regular (every fortnight) update on the VisualEditor project and its cousin the Parsoid so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement).

; VisualEditor

; Parsoid

Hope this is helpful! As always, feedback gratefully received, either here or on the centralised feedback page.

Jdforrester (WMF) (talk) 21:00, 16 October 2012 (UTC)

Hey all :).

File:EditMode PreCopyCleanup.png

So, the new Micro Design Improvements team has been looking at various things to tweak to try and make Wikipedia's interface less clogged with stuff. One of these is improvements to the "edit" window, which I want to give you all a bunch of advance notice of - obviously, everyone uses it, and so I don't want to just drop it on enwiki without letting anyone know :). A couple of important disclaimers - first, if you're on anything other than vector, you won't get the collapsible lists for categories/templates. If you are on vector, but don't have the enhanced editing toolbar switched on, you'll see some changes, but one of them (removing the edit tools at the bottom) won't take effect. You'll only get the full package with both vector and the enhanced toolbar. With that in mind, here's a TL;DR bit on the changes that are part of this:

File:EditMode CopyCleanup v6.png

1. Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.
2. :Rationale: This line is primarily composed of guidance as to what sort of content is appropriate for Wikipedia. (Several projects moved such guidance here from MediaWiki:Edittools when this message was introduced after the license switch.) Having it below the edit window almost ensures that people will only read it after they have tried to make changes - it is of little use. On the other hand, if we move it above the edit window, we have an opportunity to educate people about what is or is not appropriate before they start writing.
3. Removing the reference to a help page.
4. :Rationale: At first glance, this might appear counterintuitive. The logic is that the advanced editing toolbar (which all new users are presented with by default) already includes a link to a "cheat sheet" of markup. The help page linked in the text, on the English Wikipedia, is a similar cheat sheet, creating duplication and taking up unnecessary space.
5. Removing half of the "if you do not want your writing..." line (MediaWiki:wikimedia-editpage-tos-summary) – that bit concerned with the Terms of Use – and moving the other half above the edit window.
6. :Rationale: Again, the message (even the legal text) has been customised by the English Wikipedia and several projects added here information/warnings previous shown in the edittools; the advice will be of most use if it is shown to a user before they have contributed. At the moment, this text is not only after the edit window but also after the "save page" button – people may not even see it before submitting their changes. The text relating to the Terms of Use is a duplication of the existing disclaimer, and one that Legal concludes serves no purpose.
7. Moving the "by clicking Save Page..." text to below the edit summary window.
8. :Rationale: The action is related most closely to "save page". Under the current workflow, someone is presented with it, then presented with unrelated options (edit summaries), and only then given the "save page" button. Moving it more closely ties the advice to the action it relates to.
9. Putting the lists of templates and hidden categories under small drop-down menus.
10. :Rationale: both elements have some use cases (for example, identifying subtle template vandalism), so we certainly don't want to remove them, but they're not much use for most editors: they just take up space and present users with a lot of text and links that serve (to them) no clear purpose. A nice middle ground is to stick them under dropdown menus: if they're wanted, they can easily be found – if not, they don't take up as much space.
11. Removing the "edit tools" toolbar after "save page" (MediaWiki:Edittools).
12. :Rationale: A lot of the functionality here is duplicated in the enhanced editing toolbar, which has been enabled by default for new accounts for quite a while for a long time. In addition, its current placement makes it of little use: people are only presented with it after they've made their changes. This change won't appear if you don't have the enhanced toolbar on.

The screenshots to the right may provide a more useful comparison of "before" and "after"; again, most of you won't notice a change :). We also have it deployed on a [http://micro-design.wmflabs.org/wiki/Main_Page prototype server] here, which you may want to create an account on so you can see how it works in practice. If you've got any feedback, I'd love to hear it, be it positive or negative, and if you've got any more ideas for improvements we could make you can drop them here, on the Micro Design Improvements talkpage, or on my talkpage. We're probably not going to be deploying until the week of the 17th of September, to allow both community discussion and feedback and some time for browser testing, which is a good time to note (nice segue, Oliver!) that if you find any issues you should let me know, and I'll do my best to get them fixed. Thanks! Okeyes (WMF) (talk) 20:23, 5 September 2012 (UTC)

::Looks good. No major issues that I can see. IRWolfie- (talk) 20:45, 5 September 2012 (UTC)

::*Thanks! :). A quick note that I want to let as many people know about this as possible - if people can think of venues I should post notifications at that I haven't, let me know. Okeyes (WMF) (talk) 20:53, 5 September 2012 (UTC)

:::Looks good to me too. Bring on the Naysayers and doom and gloomers! :-) Kumioko (talk) 20:54, 5 September 2012 (UTC)

{{Collapse top|title=Discussion of impact on other wikis Okeyes (WMF) (talk) 20:06, 20 September 2012 (UTC)}}

• Is this only for English wikipedia, or why is this linked to a mediawiki page? Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:57, 5 September 2012 (UTC)
• :At the moment, this is only going to be deployed on enwiki; we don't want to fling the change out everywhere because it's a pretty big thing to be altering for every project. We'll hopefully ramp it out over time - first to other projects that request it, then to a wider userbase, then stick it as the default, so on, so forth. The location of the team page (MediaWiki.org) is because the team's projects overall are hopefully going to be for a much wider range of our wikis, and so it's not that appropriate to host it on an individual "in use" wiki. I appreciate this makes it slightly harded to follow the conversations - I'm looking for ways around this :S. Okeyes (WMF) (talk) 21:01, 5 September 2012 (UTC)

:::(OK. Once you get to other wikipedias, please keep in mind removing the edit-toolbar is in many cases a bad idea. Going through the list of all possible letters just to find the one you need each and every time is tedious, and typing Cherokee and Inuit is impossible without it. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:06, 5 September 2012 (UTC))

:::Heh; noted :). Does the enhanced toolbar not include that functionality? I can imagine it wouldn't for the particularly obscure characters (or those in non-westernised languages) but, generally-speaking, what is the "special characters" tab missing? Okeyes (WMF) (talk) 21:08, 5 September 2012 (UTC)

:::I'd note that Siebrand's team is working on mw:Universal Language Selector, which may help somewhat. Okeyes (WMF) (talk) 21:17, 5 September 2012 (UTC)

::::What you'd call obscure :P American letters, for example >> Ꭰ Ꭱ Ꭲ Ꭳ Ꭴ Ꭵ Ꭶ Ꭷ Ꭸ Ꭹ Ꭺ Ꭻ Ꭼ Ꭽ Ꭾ Ꭿ Ꮀ Ꮁ Ꮂ Ꮃ Ꮄ Ꮅ Ꮆ Ꮇ Ꮈ Ꮉ Ꮊ Ꮋ Ꮌ Ꮍ Ꮎ Ꮏ Ꮐ Ꮑ Ꮒ Ꮓ Ꮔ Ꮕ Ꮖ Ꮗ Ꮘ Ꮙ Ꮚ Ꮛ Ꮝ Ꮜ Ꮞ Ꮟ Ꮠ Ꮡ Ꮢ Ꮣ Ꮤ ᐊ ᐃ ᐅ ᐋ ᐄ ᐆ ᐸ ᐱ ᐳ ᐹ ᐲ ᐴ ᑉ ᑕ ᑎ ᑐ ᑖ ᑏ ᑑ ᑦ ᑲ ᑭ ᑯ ᑳ ᑮ ᑰ ᒃ ᒐ ᒋ ᒍ ᒑ ᒌ ᒎ ᒡ ᒪ ᒥ ᒧ ᒫ ᒦ ... etc. (can you even see those?) Instead of flooding the special characters-thing, just keep the edit toolbar. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:18, 5 September 2012 (UTC)

:::::I can, yep :). Would the language selector not help? Okeyes (WMF) (talk) 21:22, 5 September 2012 (UTC)

::::::I doubt it. It just wouldn't be worth it to this for the <200 people who'd actually use it. Just don't switch it off all of the sudden, that's all I was worried about. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:26, 5 September 2012 (UTC)

:::::::We'll try not to :). Like I said, we're not planning on scaling it out immediately - and when we do scale it out more widely I'm sure we can try to work together a CSS hack or opt-out for wikis that are going to struggle. Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)

{{collapse bottom}}

:What are you using to generate the dropdown menus and what does it look like rendered in FF, Chrome, IE, etc? Protonk (talk) 21:12, 5 September 2012 (UTC)

::This is a question for Rob Moen; I'll get him in here :). It renders very nicely in Firefox - I invite any and all to test the [http://micro-design.wmflabs.org/wiki/Main_Page prototype] and see!

:::Rob reports he wrote a jQuery module for it; it's at /trunk/extensions/Vector/modules/jquery.footerCollapsibleList.js :). Okeyes (WMF) (talk) 00:29, 6 September 2012 (UTC)

::::Do we really need to create yet one more script for collapsing things? Why not to use (improving if needed) the jQuery.makeCollapsible which is already available on MW? Helder 21:30, 6 September 2012 (UTC)

:::::Aye, there are too many already. It's kind of scary, and makes getting fixes for any one only that much harder. -— Isarra ༆ 08:07, 7 September 2012 (UTC)

{{Collapse top|title=Accessibility concerns (now patched) and suggestions for future expansion. Okeyes (WMF) (talk) 20:06, 20 September 2012 (UTC)}}

• I'm all for it. But with the following notes.
• # Should nicely deprecate my User:TheDJ/usagecollapse.js script. But did you take into account file usage and global file usage lists on edit pages ? See :File:Name.jpg for an example of that horribleness.
• #:Does global file/account file useage appear in the edit window? I've never seen it, but I don't spend that much time around images. Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)
• #::Unfortunately not, they are the same problem though. —TheDJ (talk • contribs) 21:37, 5 September 2012 (UTC)
• #:::Sounds like an excellent target for our next improvement, then! :). Okeyes (WMF) (talk) 21:44, 5 September 2012 (UTC)
• # I would suggest finding an alternative for the pipe chars in the warnings however, and that whole bit should probably be an .hlist (en.wp specific css, which we really should add upstream btw).
• #:Agreed; the pipes are something we're looking into (when I showed it to my boss, he thought it was a capital I. Not a good sign!). Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)
• #: Agree that the pipes in italics look strange. How about if just use periods or Bullets. Vibhabamba (talk) 23:32, 5 September 2012 (UTC)
• #::Bullets sound good to me. TheDJ/anyone else? Okeyes (WMF) (talk) 00:01, 6 September 2012 (UTC)
• #::I myself am fond of bullets: • --Jorm (WMF) (talk) 22:24, 5 September 2012 (UTC)
• #:::Bullets are read out by screenreaders. The reason we don't use them in hlists anymore. —TheDJ (talk • contribs) 07:00, 6 September 2012 (UTC)
• #:::+1 for hlist. BTW: I've requested its inclusion on MediaWiki at bugzilla:40062. Helder 20:53, 6 September 2012 (UTC)
• #::::Going to simply employ a period after each sentence here. That is just enough for the job and works from an accessibility perspective. — Preceding unsigned comment added by Vibhabamba (talk • contribs) 22:37, 7 September 2012 (UTC)
• # I'm also not sure if it's a good idea to change the appearance of categories on the edit page. Inconsistent representation of the same data set might not be a good idea.
• #:What do you mean, sorry? Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)
• #::Strike that, i'm confused with livePreview of the edit window, which copies categories as the view page has them.—TheDJ (talk • contribs) 21:37, 5 September 2012 (UTC)
• # I see light gray... Please think about contrast, our users with accessibility issues will appreciate that. —TheDJ (talk • contribs) 21:26, 5 September 2012 (UTC)
• #:An excellent point :). Okeyes (WMF) (talk) 21:30, 5 September 2012 (UTC)
• #::Thanks for bringing this up DJ. The grey was the most amount of contrast we could afford without making it compete with other elements on the page.

Dark Grey Text on light grey backgrounds or fills is considered accessible and easy to read.

If we go any darker the color will compete with the left navigation bar and the text will be hard to read. So that was a bit of a constraint.

See: http://uxmovement.com/content/when-to-use-white-text-on-a-dark-background/ Also here is the color pallete that is being used by the foundation: http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Color_Usage. We are are looking at testing this a little bit.Vibhabamba (talk) 00:13, 6 September 2012 (UTC)

:The darkness already competes with the rest of the screen in the vector skin. -— Isarra ༆ 17:23, 6 September 2012 (UTC)

{{collapse bottom}}

{{Collapse top|title=Wider discussion about future changes Okeyes (WMF) (talk) 20:07, 20 September 2012 (UTC)}}

Some thoughts:

• Overall this is much simpler and a nice improvement in terms of usability. Yay!
• 'Cancel |' between two buttons looks weird.
• That grey is annoyingly dark.
• While I like the collapsing of the templates and hidden categories lists (and indeed have been using a version for awhile already, though it doesn't work nearly as well as I'd like either), I have some nitpicks with the particular implementation here.
• The collapsing/uncollapsing animation is probably slower than it needs to be, but why does it need to be animated at all? This is technical stuff, which if we want to see it at all, probably want to see it immediately.
• Remembering the collapsed/uncollapsed state with a cookie may not be the best approach, given how very many templates a lot of things have and that even if on some pages or in some cases the list merits uncollapsing, on most it really doesn't and just gets in the way. As such I would put forward that by default they should always start collapsed, regardless of how it was left on the last one. A UPO to have them start out open or maybe disable the collapsing entirely would be useful for some people, though.
• There are times when it would be useful to have the list headers say how many things there are, so instead of 'View templates in this Page', it might say 'View 59 templates used on this page' or some such.
• When there are only one or two templates on a page (or any random number <5), is it really worth collapsing them by default?
• Geese.
• I'm not sure moving the warning line to the top will make it less likely to be ignored; since the buttons are at the bottom it seems like people may pay more attention there, especially when there is less clutter there.

-— Isarra ༆ 21:33, 5 September 2012 (UTC)

::I really like the remember of collapsed state. And given past experience with the sidebar and collapsibility, I think most other users would prefer remembering this as well. —TheDJ (talk • contribs) 21:42, 5 September 2012 (UTC)

:::I agree about remembering with the sidebar, but that is also effectively the same sidebar on every page; the same cannot be said for specific content. Different pages can have very different templates/hidden categories, and the remembering is not page specific - having uncollapsed the list on someone's talkpage does not mean one wants to see the list of every component template included in a content page's infobox. -— Isarra ༆ 22:59, 5 September 2012 (UTC)

::::Excellent point :). I'm going to add "remembering with the sidebar" to our to-do list as part of a greater "sticky settings" project for non-context-specific menus. Okeyes (WMF) (talk) 23:18, 5 September 2012 (UTC)

:::::Cookies are really not helpful for me, as my browser clears them regularly. There needs to be an account setting or gadget to make the template info fully visible to troubleshoot template issues before this goes live, or dealing with them will be pain. Troubleshooting templates can often involved checking templates on multiple pages, and constantly unhiding them would be a pain. Monty₈₄₅ 23:26, 5 September 2012 (UTC)

::::::Totally agreed :). So, we've now actually got two ways of remembering a setting; 1, cookies, which have a lot of problems, or 2, "sticky settings". These are basically hidden preferences options. So, for example, we could implement sticky settings here and it would remember it as a 'preference' - not one that appears in "my preferences", but something ever-present that doesn't go away when you clear your cookies. Okeyes (WMF) (talk) 23:57, 5 September 2012 (UTC)

::The suggestion with the count on the collapsed header seems wonderful, we should probably implement that in core however. The animation should be removed in my opinion yes. —TheDJ (talk • contribs) 21:42, 5 September 2012 (UTC)

: Your suggestion seems to be one more use case for the request to allow disabling interface animations.

: I also like the idea of displaying the number of templates in the page when the list is collapsed. Helder 21:30, 6 September 2012 (UTC)

: Hi Issara Thanks for your feedback. I helped Oliver out with this feature. Could you explain a bit more why the Cancel is feeling weird? Is it just visual or is it a workflow issue? We wanted to clearly separate the Save + Cancel from the Preview + Show changes. From some data analysis we have seen that quite a few users (both new and advanced) are using the preview feature. Eventually we hope to improve the workflow by moving the Preview to a more contextually appropriate position in the workflow. Also is the grey fill (bottom of the edit field) distracting? The reason we introduced a fill is that it lends finality to the edit workflow. Would be helpful to understand why its annoying. Thanks Vibhabamba (talk) 23:32, 5 September 2012 (UTC)

::The cancel button just looks really weird like that, randomly between two buttons and with a sinlge | for no apparent reason. Don't know if it would affect workflow aside from maybe causing people to accidentally hit that instead of the preview button since that's where the preview button normally is, but on the other hand, what is contextually inappropriate about where the preview button is normally?

::And when there is that much of it, the 'fill' is just too dark for the page. The colour itself ain't inherently bad, but that much of it results in a domination of the space of the page when the object in question should be no more dominating than the edit box itself. Look at a screenshot and zoom out; it becomes more immediately apparent when the details aren't present. -— Isarra ༆ 08:07, 7 September 2012 (UTC)

::: I agree that the Cancel Button looks a little strange. From instrumenting this page we have learned that both new and advanced users extensively use the Preview Button. Currently it comes after the Save action and falls below the page fold. If we create a clean grouping for save and cancel, eventually we can move Preview closer to the edit field, so a user can access preview without wandering away from the edit window. Do you have feedback/ suggestions around this..? Thanks Vibhabamba (talk) 22:35, 7 September 2012 (UTC)

::: We also want to upgrade to a simpler keyboard shortcut for it. Can you think of better (one? Vibhabamba (talk))

file:Enwp_edit_page_mockup.png ༆ 03:40, 9 September 2012 (UTC)]]

:::: The cancel button should really be just that - an actual button button, probably at the end of the others, since that way it would be (and is currently, for that matter) opposite in position from the edit button, the one from which it is technically the opposite. And I don't see why the buttons should be split up at all - they are all actions that can be taken with the open page, so reasonably they should be together so people can see what all their options are in one place, though that should be closer to the editbox itself, indeed. Something to consider might also be to repeat them at the top of the editbox - such that the page, from top down, might go something like this:

::::*(preview or diff)

::::*(any relevant editnotices)

::::*short copyright etc disclaimer thing if needed

::::*save cancel buttons

::::*editbox

::::*(charinsert edittools)

::::*short further disclaimer/notes thing if needed

::::*edit summary field and description, all on one line

::::*(minor edit and watchlist checkboxes)

::::*save preview diff cancel buttons

::::*(transclusions list)

::::*(hiddencats list)

::::Where parentheses indicate things that may show up depending on action taken, user preferences, who is editing, and the page in question. Aside from the extra disclaimer at the top (do we really need that anyway?), this is basically what you get with a default MediaWiki install (and even more so when the side-by-side preview and publishing labs features are enabled, which are pretty cool and also something we might want to consider here) when not cluttered up with an overabundance of warnings and disclaimers and 'Please note's. Frankly our main problem here is simply that we have so much stuff everywhere, which is unfortunately a problem with the entire project, manifesting not just in the interface, but in policies, templates, processes, even in the way people communicate. Nevermind everything else; one thing we really need to do is look into getting rid of all that extra clutter that has been added over the years, because nearly all of that is redundant and/or not actually helpful. -— Isarra ༆ 00:46, 9 September 2012 (UTC)

:::::The side-by-side concept is a very nice I would definitely support although some might accidentally click on "Cancel" (because the Preview button was there previously). --intforce (talk) 21:48, 19 September 2012 (UTC)

{{collapse bottom}}

• I understand the rationale behind removing the editing help button; however, I'd like to see a study performed to see if the button is being used before doing that. We could do the rest of the changeover and leave that in if we need time. I think it could work to do a 30 or 60 day study and (unless there's a better way to do it) turn that link into a new redirect to the intended page. Then count the visits to the redirect. In addition, removing the editing tools would be a mistake. The enhanced editing toolbar is enabled on my account and there are things that are not duplicated. I use the editing tools toolbar for a few things. Em dashes, nonbreaking spaces, and {{#tag:ref||group="nb"|name=""}}. I would support adding a new dropdown for wiki markup to the toolbar as an alternative. Ryan Vesey 21:43, 5 September 2012 (UTC)
• :Expanding on the special characters is probably a good idea :). I disagree on the "if the button is being used" point, though. So, it's possible that some people are clicking it. That doesn't show it's a good thing - it just shows that we're presenting them with the option and they're taking advantage of it. When they click it, they're sent to a page that doesn't include anything that the "help" tab doesn't, doesn't include a few things the "help" tab does, and is in a much longer format (and requires to to go away from the edit window). I do like the idea of maybe turning it into a redirect to the help function in the toolbar, if we can do that and if there's a use case. Okeyes (WMF) (talk) 21:50, 5 September 2012 (UTC)
• ::I'm really not convinced that removing the help link is a good idea. It strikes me as rationalisation for the sake of it. I think the link should be kept for the time being - the space involved is negligible, really - and some effort should be made to think through what such a link should run to. In this kind of area (and face-to-face training shows this) it is very easy to overestimate the savvy of new users, and I'm concerned that the reasoning given just slides past the actual difficulties. In any case I see this as a serious design point, worthy of a discussion in its own right. Charles Matthews (talk) 12:50, 26 September 2012 (UTC)
• ::: I'd echo Charles' reasoning above. When training, it's often useful to let trainees open the Cheatsheet for continual checking throughout the session. The dropdown for help on the toolbar is compact and is probably the first choice for editors who have some experience, but I'd prefer to have an obvious link to a separate help page for absolute beginners. As a small point, referencing is the single most difficult topic for new editors and the Cheatsheet has links to Cheatsheet for citing a website or publication and Referencing for beginners that are not available from the dropdown help. --RexxS (talk) 15:50, 26 September 2012 (UTC)
• ::See Wikipedia:Village_pump_(proposals)#Message_on_search_results_page for something that is clicked often, yet not really helping along users. A way to measure this is a good idea, but we need a different metric in that case I think. —TheDJ (talk • contribs) 22:05, 5 September 2012 (UTC)
• :It is already possible to customise the WikiEditor's edit toolbar to add the buttons you need. And I think this is a better approach than not providing a way for users who do not use it to be able to remove that content (bug 11130, open since 2007). Helder 21:30, 6 September 2012 (UTC)
• I do not object, which is surprising. Evanh2008 ^{(talk|contribs)} 23:13, 5 September 2012 (UTC)
• Question about preference gadgets - There are at least a handful which interact with the html you are changing. Have you gone through and tested this will all the gadgets offered in Preferences? Also, how are you changing this just on Vector? Is there a way to override these interface messages just on one skin without changing them on the others? —Cupco 00:28, 6 September 2012 (UTC)
• :The changes should only impact on Vector, yep. What preferences are you referring to? Okeyes (WMF) (talk) 00:30, 6 September 2012 (UTC)
• ::"Add two new dropdown boxes below the edit summary box with some useful default summaries" seems the most likely to be affected. —Cupco 10:43, 6 September 2012 (UTC)
• :::That, I haven't checked; I will :). But I think we're going to be horribly restrained in the future if we can only act when there's no conflict with any gadget anyone has created and got consensus on. Okeyes (WMF) (talk) 10:55, 6 September 2012 (UTC)
• Very Good Nice clean layout and well organized. It gives priority to the text that needs it. It also fixes the wall-o-text that confuses less experienced users. Thanks to all involved. Good job. 64.40.54.83 (talk) 03:41, 6 September 2012 (UTC)
• Support I am in complete agreement. This will look much more professional and easy to read than the current design. Jsayre64 (talk) 23:35, 20 September 2012 (UTC)
• Not a huge fan, but... I never like the prospect of changes. There's a good chance in 4 months I'll think it was a terrrific idea, so take my opinion with a grain of salt. Go Phightins! (talk) 20:17, 23 September 2012 (UTC)

Everything looks really great except Moving what is currently the first line of text under the edit window "content that violates any copyrights..." (MediaWiki:wikimedia-copyrightwarning) above it.. Disagree with rationale. I believe most people's attention will skip anything above the edit box (especially anything using the same font as the "redirect" messages), since the edit box is extremely large and is the primary focus of the page and of the user's intended action, then after editing, attention will be shifted further down the page to the action buttons. If this notice is to be placed above the edit box, perhaps it should be in a noticeable font, e.g. red (but it should *not* be in a notice box, since I think many people are also trained to skim over those from normal wikipedia articles). --JAC4 (talk) 13:22, 24 September 2012 (UTC)

:It is going to be visually distinctive compared to other text - I have to say I think red is likely to induce "agggh! warning!" reactions in newbs. Interestingly the reaction I've got from a lot of editors is the other way around; they completely gloss over stuff below the edit box. Okeyes (WMF) (talk) 15:01, 25 September 2012 (UTC)

• Comment: I like that the Save / Show preview / Show changes buttons are moved up. With the current design I'm always scrolling down to them which means moving the mouse out of the edit window and then scrolling with the mouse wheel. What I'd really like is for all of the edit controls, the submit buttons, edit summary, etc to be fixed all in one place (preferably at the top of the screen) so they never move while the rest of the page can be scrolled.

:Missing is the box with the dashes and other common symbols and wiki markup links currently below the edit window. I rather use that a lot. The symbols that I use most commonly are the –, —, ×, and §. Don't make me hunt through the Special characters toolbar for them. I never use the Signature and timestamp button in the main toolbar (in fact, I don't use any of the options there.)

:Because this is an edit page, the normal Wiki advert at the top of the page should be disabled (right now it's Participate in the world's largest photo competition and help improve Wikipedia! I'm editing, I don't need to see that and even with fast internet it slows page load; I'm not going to risk losing my work to go look at the advert. (I usually ignore it anyway even when I'm not editing). Yeah, I know this is probably outside the scope of this proposal.

:—Trappist the monk (talk) 16:19, 25 September 2012 (UTC)

::It's strange that you've lost the symbols etc. - I assume that you mean these. For me, they've moved to a more obvious position - directly below the edit box, and just above the edit summary. Try a WP:BYPASS; if not, which skin are you using? For me, it's present in both MonoBook and Vector. --Redrose64 (talk) 17:00, 25 September 2012 (UTC)

:::Yes, Edittools. Google Chrome 22.0.1229.79 m. Default skin. No change when I WP:BYPASS. As the page is loading I can see the character sets for a brief moment and then they're gone. I can also see the Edittools when I view the page source. My screen looks very much like the mockup image which also is missing the Edittools.

:::—Trappist the monk (talk) 18:42, 25 September 2012 (UTC)

::::Here's an idea. It's not been tried before for this specific feature (AFAIK) but something similar has worked for other problems connected to visibility of other features. Go to {{myprefs|Gadgets}}, and under the "Editing" heading, locate "{{MediaWiki:Gadget-charinsert}}", which should be switched on but might be off. If it's already switched on, switch it off and save. Then, whether or not it was previously switched on, switch it on and save. This should persuade the settings to update themselves. --Redrose64 (talk) 13:36, 26 September 2012 (UTC)

:::::No change. I know that unchecking Charinsert made the toolbar go away on "this" editing page – I checked that before I went to the new editor. Rechecked the check box and now I have the tool bar here but not there. Bypassed the cache when I reloaded just to be sure. Since that toolbar is visible and usable here, and presumably is the same toolbar that is used there, then the problem can't be me but must be in the new editor's page right?

:::::Also, the minor edit and watch check boxes aren't present. Does that offer a clue?

:::::—Trappist the monk (talk) 03:23, 27 September 2012 (UTC)

:::::Just for Curiosity's sake, I looked into the source for this editor and the new editor. I haven't made a careful inspection to compare the code of one to the other but I did notice this in what I suspect is the first line of the Charinsert part:

::::::{{code|}} (from this editor)

::::::{{code|}} (from the new editor)

:::::—Trappist the monk (talk) 03:33, 27 September 2012 (UTC)

:::::: That wpEditToken of "+\" indicates that you're not logged in there, which also explains why the minor edit and watch checkboxes are missing there. Anomie⚔ 10:47, 27 September 2012 (UTC)

:::::::Ok, thanks. But shouldn't a non-logged-in editor still be able to mark an edit as minor? If not, then why is that function reserved for logged in editors?

:::::::–Trappist the monk (talk) 13:22, 27 September 2012 (UTC)

:::::::: According to Help:Minor edit, "Users who are not logged in to Wikipedia are not permitted to mark changes as minor because of the potential for vandalism." Anomie⚔ 14:29, 27 September 2012 (UTC)

:::::::So the real reason that I can't see the Edittools is because I'm not logged in? In the source for this editor there are three instances of the term Charinsert.

::::::::{{code|}} // settings from my preferences

::::::::{{code|