Requests for comment/Core user preferences

An evaluation of user preferences (Special:Preferences) in MediaWiki core.

New dataset
See announcement and raw data. en.wp for now, others to follow. Please read the caveats before jumping to conclusions. Some initial thoughts:


 * I'd suggest using 1% as an aggressive cut-off for initial culling and then deciding whether we want to go beyond that. If a pref/feature is used by fewer than 1% of active users, and doesn't have accessibility implications, it's really hard to justify its continued existence.


 * Here are examples of features that could be ditched immediately:
 * The External Editor/Diff pref/feature. While the External Editor capability is also surfaced on file description pages, I think based on the tiny usage it's safe to remove it entirely. It was always a hackish approach (by yours truly no less), doesn't rely on the API, and should just die. Perhaps a better approach can be found in the long term, perhaps not.
 * Some of the watchlist filters. "Hide logged in users" (used by 33 users), "Hide anonymous editors" (used by 44 users), perhaps "Add pages I delete" (used by 151 users).
 * The ability to disable the Table of Contents feature (used by 86 users).
 * The ability to disable section editing (used by 86 users).
 * The ability to disable the collapsing of sidebar navigation menus in the Vector skin (used by 261 users).
 * The ability to disable AJAX search suggestions (used by 112 users).
 * The ability to render preview below the edit box (used by 372 users).
 * The ability to show diffs without rendering the corresponding page content (used by 402 users). (This one I'd like to see more cross-language stats for.)

--Eloquence (talk) 21:57, 12 October 2012 (UTC)
 * I'm not sure if this is the right place to post replies, but with regard to "Add pages I delete": 151 users out of 1,458 admin on en.wiki is over 10%. Also, please wait for some results from non-English Wikipedias and non-Wikipedias before jumping to conclusions about usage; not every one has the same workflows and user cases. Matma Rex (talk) 22:31, 12 October 2012 (UTC)
 * Yeah, that's why I qualified that one with "perhaps", as it seems more specialized towards admins.--Eloquence (talk) 23:07, 12 October 2012 (UTC)
 * What is 1 % in absolute terms anyway? And shouldn't it be computed only on the total of users who ever set a preference, to avoid counting the "silent majority"?
 * Also, why are we considering only active users? It's useless data for several of those preferences, which can be used by read-only users who registered precisely to be set preferences (as many help pages suggest). --Nemo 06:26, 13 October 2012 (UTC)

Thank you very much for getting some stats. I think as long as we make a commitment to provide a snippet to replace functionality for any removed user preference (most of these should be trivial to re-implement in JS or CSS snippets), it's fine to kill most of the preferences you've listed with fire. --MZMcBride (talk) 03:28, 13 October 2012 (UTC)
 * How many users out of the 40 thousands who used "mark as minor by default" took advantage of the provided snippet? Workarounds can silence the most vocal opposers but don't cancel the feature loss (just a reminder). Indeed before jumping to conclusions we need to clarify how we can measure the net positive/loss of a removal...
 * As for the mentioned options:
 * cherry-picking watchlist options to remove would increase confusion about what is where (31882), better to fix 31881;
 * TOC, collapsing, search and diffonly might affect readers, see above;
 * AJAX search: does it degrade gracefully on browser where it doesn't work?;
 * diffonly does have accessibility implications, because even when you're interested in a couple bytes only (the diff) you can be forced to render kB of HTML (the page), it can be a show-stopper for people low on CPU (or bandwidth?); rollbackers (including sysops) and RC patrollers in general are probably a more correct population to consider (alongside the others?); finally, does it make sense to remove this and not its twin "Omit diff after performing a rollback"? --Nemo 06:26, 13 October 2012 (UTC)
 * I'm using the diffonly preference since I'm a sysop on an active wiki and I have to review *lots* of diffs everyday, using a relatively modest computer with no much RAM and CPU clock frequency. I developed a script which adds the diffonly=0/diffonly=1 to diffs links when I need them, but I almost never enable the display content after diff. Also, I think that this particular preference is targetted to specific roles of users: sysops and patrollers, which are a very minimal part of the average users, since normal editors or readers doesn't review diffs and recent changes at all. This should also be considered when removing such preferences. --Ciencia Al Poder (talk) 11:16, 14 October 2012 (UTC)
 * It's also useful for people who often view diffs from their watchlist like myself. I've used it since it was introduced in January 2007 and I'm rather surprised it isn't used more widely. I use a screen reader and therefore can't really use navigation popups. Graham87 (talk) 11:38, 17 October 2012 (UTC)
 * Low usage isn't an argument for getting rid of a preference if there is little cost to maintaining it. It is an argument for getting rid of a preference which is expensive to maintain, makes implementing other more desired features very difficult etc. Kerry Raymond (talk) 01:40, 15 October 2012 (UTC)


 * Low usage of a preference is exactly a reason to get rid of it. Almost all preferences could be considered low-cost (eg: it's just one if statement), but every preference increases the complexity of the software and number of possible outcomes. It's why we're very wary to add new preferences these days (and many existing preferences wouldn't be added now, if they were being newly proposed). ^demon (talk) 16:52, 15 October 2012 (UTC)


 * FYI, I am one of the people who set 'The ability to render preview below the edit box (used by 372 users).' and am surprised by the stat. If the edit box is at the top of the page, after checking your preview you can just hit HOME to get to the top of the page, where the whole edit box is visible.  If it is at the end of the page, hitting END takes you to the bottom of the page which leaves half the edit box cut off, due to the amount of cruft that sits underneath it.  Therefore having it at the end is a lot more fiddly than having it at the start if you're not on a large desktop monitor.  I wonder what the stat for this setting would be if the default value had been the opposite - I wouldn't be surprised if it was pretty similar (i.e. the inverse) and that most people haven't really considered changing it from the default, and wouldn't have done so no matter what the default was. --HappyDog (talk) 15:25, 15 October 2012 (UTC)


 * ^demon, I agree that low usage is a reason to remove, but there are also other reasons to keep some of them. For example, there are probably A LOT of people that never changed their preferences, or did it only once to set the language or timestamp, and simply didn't care about the other preferences, because I agree there are lots of them and people probably don't know what effect have some of them. Wikipedia has millions of readers, but only a very small percentage edited. Should it be a reason to remove the editing interface because it's "low usage"? It may seem a bit extreme, isn't it? The key is "low usage" in comparison to what? I'd be glad if you could weight (and discuss here) the real usefulness of every option before trying to remove them with the generic "low usage" reason. Thanks. --Ciencia Al Poder (talk) 19:37, 17 October 2012 (UTC)


 * I personally have used two of the above, and would like to see them kept.


 * When manually doing repetitive tasks, especially on a slower connection, I find "The ability to show diffs without rendering the corresponding page content" very useful. It's not something that I need all the time, though, so I can understand why it would have a lower apparent usage.


 * "Enable section editing via [edit] links" - I always have this box unchecked. I never use the section editing feature. I understand how it can be useful to some, but, especially on talk pages (and let's not talk about edit conflicts) I've found it confusingly problematic. And this preference removes extra links from needing to be loaded on the page.


 * I think out of all the things eloquence notes above, the filter by IP definitely should go. It's contrary to "anyone can edit" and "We're all Wikipedians". I can almost see a potential usage for when someone is vandal patrolling, but I think the ability to filter out/in both IPs AND non-autoconfirmed together would be more helpful, I would think? - Jc37 (talk) 00:46, 18 October 2012 (UTC)
 * I've sometimes used the watchlist filter. "Hide logged in users" but I'm not counted as one of those who does so because it isn't how my filters are currently set. It is a useful way to target possible vandalism, and it doesn't breach the "anyone an edit" ethos because it doesn't stop IPs editing, just makes it easier to identify and revert vandalism. WereSpielChequers (talk) 11:45, 17 February 2014 (UTC)
 * WereSpielChequers, you sit there and assume that unregistered users are (mostly) vandals. This is often true; however, such attitude is harmful to such users themselves — specifically those who tried to do something, messed up the formatting or simply didn't convey their idea, and got it reverted instead of your attention to detail. —Gryllida 20:34, 17 February 2014 (UTC)
 * Jc37, “vandal patrolling” is a barbarous concept. When not focused on a topic, you end up engaging in routine work with little interaction with the affected contributors and article content, with issues like this and that. (I'm ok with disabling 'hide logged in users' in the watchlist.) —Gryllida 20:40, 17 February 2014 (UTC)
 * Those filters can be switched on/off in the watchlist itself, no need to have a preference for them. That selection could be remembered, though --Ciencia Al Poder (talk) 10:20, 18 February 2014 (UTC)

I'm only ok with disabling “render preview below the edit box”. That's something I tend to use, personally, although AJAX preview makes it useable regardless. —Gryllida 20:40, 17 February 2014 (UTC)

I would perhaps agree with the suggestions to keep the ability to show diffs without rendering the corresponding page content. Some pages are quite large with me only needing a specific diff. —Gryllida 20:41, 17 February 2014 (UTC)

Generally
Tabs on top still a good idea? Kind of stack weirdly. Maybe need vertical tabs in a sidebar thing?
 * Putting the tabs in a sidebar would be problematic on narrower screens (which are the ones having the stacking problem in the first place), since that way the preferences themselves could get pretty squished. Dealing with squished stuff is no fun. None at all. And either way there should really just be LESS TABS. We could totally kill about seven of them with no great loss... merge relevant stuff, get rid of pointless stuff, and profit. -— Isarra ༆ 19:49, 23 September 2012 (UTC)
 * I think we should switch from tabs to collapsible sections making use of native collapsing code. As a bonus the could include some text describing what kind of preferences are inside the section. Daniel Friesen (Dantman) (talk) 20:21, 23 September 2012 (UTC)
 * Tabs, whether at the top or side, are a much more intuitive structure for navigation; collapsing things is more like to just keep people from seeing them entirely. Might be worth looking into for extended descriptions or the like, however, for anything that may need one. -— Isarra ༆ 20:29, 23 September 2012 (UTC)
 * It actually looks pretty good using even without any nice vector styling added to it: http://i.imgur.com/Mb4L9.png
 * And if you wanted it wouldn't be hard to use JS to implement a sort of accordion like collapse functionality that would have most of the pros that tabs have. Daniel Friesen (Dantman) (talk) 21:58, 23 September 2012 (UTC)

Stats about usage of these preferences is desperately needed.
 * See w:Wikipedia:Database_reports/User_preferences, but it would be better to have an aggregate of the usage over all wikis. Helder 21:09, 23 September 2012 (UTC)


 * This doesn't include metrics for most of the prefs discussed below, is anyone working on a complete report? Rather than just going by gut feel, we should rank-order prefs and start with removing the least frequently used one that have minimal justification to exist.--Eloquence (talk) 23:44, 8 October 2012 (UTC)


 * Replied to you here. Say, you have shell access, don't you... &gt;:-) --MZMcBride (talk) 00:52, 9 October 2012 (UTC)

User profile

 * Username &mdash; no (change) link
 * Number of edits (link to Special:Contributions?)


 * Language option &mdash; move up to top?


 * E-mail preferences are weirdly situated... combine into a generic "Communications" section?

Skin

 * Skins should surely be using a dropdown menu?
 * No, no, no, no, no, no, no, hell no... that would eliminate the preview link, the other links there to help the user, and it would preclude us from trying to make the interface more usable in the future by using things like screenshots.
 * What? You could load additional content (such as a screenshot or links to power-user features [custom JS or CSS pages]) when the drop-down selection changes, as relevant and appropriate. --MZMcBride (talk) 21:41, 23 September 2012 (UTC)
 * Doing a dropdown like that would still kill the usability. Screenshots should be scannable visually. If a user has to individually each skin from a dropdown just to see if it's the skin they want then it's a usability failure. Additionally a user should not be required to take an action that implies changing of preferences (changing a dropdown) just to preview a theme. WordPress, Drupal, and Joomla ALL show a screen listing themes with a name, screenshot, and a short description. That is the standard most user-friendly way to do skin preferences. A dropdown is a complete step backwards away from user-friendly preferences (which is supposed to be what we're trying to aim for here in the first place). Daniel Friesen (Dantman) (talk) 21:54, 23 September 2012 (UTC)
 * Eliminate some skins?
 * Fix skinning system generally...

YES. -— Isarra ༆ 19:50, 23 September 2012 (UTC)

Maybe look for a way to combine some skins? - Jc37 (talk) 01:17, 18 October 2012 (UTC)

Files
Weird section.

Again, useful, depending my connection and/or computer. - Jc37 (talk) 01:17, 18 October 2012 (UTC)

Advanced options

 * 27201 Link underlining &mdash; gadgetize?
 * Would make sense. -— Isarra ༆ 19:57, 23 September 2012 (UTC)
 * Actually, as I said on the bug, "gadgetize" means nothing as long as such gadgets are not able to be shipped with core/tarball. --Nemo 07:18, 29 September 2012 (UTC)


 * Threshold for stub formatting &mdash; gadgetize?
 * Does anyone even use this? Since most folks aren't even going to have the slightest idea what that even means (I sure didn't), it probably would be better in a gadget for the subset of folks who do. -— Isarra ༆ 19:57, 23 September 2012 (UTC)
 * It's a preference that adds a stub class to internal links pointing to pages below a certain size. Basically it makes internal links pointing to pages that exist look almost like redlinks if the page doesn't have much content (ie: it's a stub an editor would want to edit). This works at the parser level (it has to fragment the cache to work) and it depends on information locked away inside the database. You can't turn it into a client-side gadget. Trying to find a way to make it work without fragmenting the cache is more important than deciding what we're going to do with the user preference. Daniel Friesen (Dantman) (talk) 21:06, 23 September 2012 (UTC)
 * Appropriate api calls should be more than sufficient for a js gadget to determine that information, and without fragmenting the cache. -— Isarra ༆ 21:28, 23 September 2012 (UTC)
 * Note: stub formatting (last I checked) does not fragment the cache. It disables it totally! As far as js - That's quite a lot of api calls to do on the client side... 129.173.208.184 17:20, 24 September 2012 (UTC)
 * That is (number_of_unique_pages_linked)/500 calls. Which is 1 call for most pages. There's a gadget on pl.wikipedia that does this for disambig links: . Matma Rex (talk) 16:37, 29 September 2012 (UTC)
 * Another option is to output on each link an HTML5 -data- attribute with the page size (would it require $wgHtml5 = true?). That would make it compatible with gadgets and don't interfere with cache. Note: I'm using this preference option on some wikis, with a value of "2000" and it's very useful for me. --Ciencia Al Poder (talk) 16:39, 29 September 2012 (UTC)


 * 27202 Disable browser page caching &mdash; why does this option exist?
 * Some browsers are dumb. Might work well as a gadget for those, though, but there really won't be very many people who have this problem and know what it is. -— Isarra ༆ 19:57, 23 September 2012 (UTC)
 * This preference controls HTTP level caching headers. The preference exists because of users who need their cache cleared regularly (editing site/user scripts/styles?). You can debate the idealistic topic of this pref vs. everyone using proper dev tools. But you can't gadgetize something like this. Daniel Friesen (Dantman) (talk) 21:06, 23 September 2012 (UTC)
 * Sure you can; just change the links the people click on. It could also be done by instead toggling an invisible user preference to do the same thing, of course, if you don't like the whole silly workaround thing. -— Isarra ༆ 21:28, 23 September 2012 (UTC)
 * I think this preference is misleading. Most people assume it refers to parser cache. People who actually understand what this does should know enough about their computers to make their browsers not send caching headers. 129.173.208.184 17:20, 24 September 2012 (UTC)


 * Show hidden categories &mdash; always show for logged in users; kill user pref?
 * +1. Matma Rex (talk) 17:58, 23 September 2012 (UTC)
 * Aye, that's sensible. -— Isarra ༆ 19:57, 23 September 2012 (UTC)
 * I disagree. pref defaults should be the same for logged in users as logged out. If we want to show for all logged in users, we need to re-evaluate why we are hiding from anons. 129.173.208.184 17:20, 24 September 2012 (UTC)
 * This is an extremely useful preference, but showing all hidden categories is crazy. --Nemo 07:18, 29 September 2012 (UTC)
 * On en.wp hidden cats are usually used for project side tracking categories and the like. And it makes sense to allow readers to be oblivious to these things, unless/until needed when they become editors : ) - Jc37 (talk) 01:30, 18 October 2012 (UTC)
 * FYI: on Italian Wikipedia, there is a small script on w:it:MediaWiki:Common.js which allows users to show/hide the hidden categories (search for "toggleHiddenCats"). Helder 22:47, 29 October 2012 (UTC)
 * That was copied from fr.wiki some years ago, byh the way. --Nemo 12:00, 30 October 2012 (UTC)
 * 27206 Justify paragraphs &mdash; gadgetize?
 * Yup. -— Isarra ༆
 * This also tends to not work very well and break things. I vote kill with fire! 129.173.208.184 17:20, 24 September 2012 (UTC)
 * I agree. Just kill it. Matma Rex (talk) 16:37, 29 September 2012 (UTC)
 * Not sure how useful this is anyway. - Jc37 (talk) 01:30, 18 October 2012 (UTC)


 * Auto-number headings &mdash; gadgetize?
 * Be better if it had a css way to do it, but it's not something terribly likely to screw anything up if it is done in js. -— Isarra ༆ 19:57, 23 September 2012 (UTC)
 * Actually, I forgot we can now use preference flags without it actually showing up in the user preferences. Having this as an invisible option in core but using a gadget to toggle it might be a good way to make it work, especially if we're shipping gadgets with core... -— Isarra ༆ 20:07, 23 September 2012 (UTC)
 * In that case I don't understand the difference between it being a preference and it being a gadget. 129.173.208.184 17:20, 24 September 2012 (UTC)
 * There is actually a potential way do do this via CSS, since 9980. We would need to change mediawiki defaults by setting the preference as enabled wiki-wide through  in LocalSettings.php (or alternatively, getting rid of that option altogether, and making the code always produce the auto-numbering), and adding   to the default skin css files. Then, the numbering will be present by default, but hidden; users could enable it by setting   to their user style. This is sort of documented at Manual:Table of contents. --Waldir (talk) 17:11, 9 January 2013 (UTC)


 * Enable collapsing of items in the sidebar in Vector skin &mdash; wtf
 * I actually use this, the collapsed items look ugly to me. But I agree it should be killed or gadgetized. Matma Rex (talk) 17:58, 23 September 2012 (UTC)
 * This is part of Vector extension, not core. — Edokter  ( talk ) — 19:43, 23 September 2012 (UTC)
 * Collapsing is useful on some projects (such as this one), but not others (like Commons). Having a preference specifically for that, however, is a little silly. -— Isarra ༆ 19:57, 23 September 2012 (UTC)


 * 30173 External editor and External Diff
 * Very very confusing if accidentally clicked, most people who use external editor (all 5 of them I'm sure) don't use it via the preference. user:Bawolff 17:20, 24 September 2012 (UTC)
 * This feature is actually pre-api. It's entire existence relies on an application interpreting a special mime-type, screen scraping the login page, screen scraping the edit page, and making an edit without using the api. The application still needs to do all the work of downloading and saving the file. And it typically needs to ask the user for their password. So since we want applications to stop screen scraping and asking passwords. And when we have something like OAuth you'll be able to build an application that does external editing without using this feature. I'm in favour of removing this feature from MediaWiki entirely. Daniel Friesen (Dantman) (talk) 17:42, 24 September 2012 (UTC)
 * [above was me] There's still people who use it (especially for editing images, but also for editing pages). There's no reason the feature cannot be used with the api, or be integrated with oAuth. Its really just a mechanism to trigger an external program. What the external program does is up to that program. However its almost useless to be enabled by a preference because most people don't want to always edit with an external editor [and if they did, in can probably be gadgetized by messing with the links in the edit tab via js]. Bawolff (talk) 18:47, 26 September 2012 (UTC)
 * Take a look at the control file format. It uses an absolute url to a UI edit page. It doesn't expose title or anything. So hacks and screen scraping are fundamental to this feature. You can't write a sane external editor using this feature. Daniel Friesen (Dantman) (talk) 18:52, 26 September 2012 (UTC)

Math
See also Requests for comment/Reduce math rendering preferences and 36496.
 * Eliminate math preferences? gadgetize?
 * Now in a MediaWiki extension... hmm
 * The preferences for this are provided due to inconsistent browser support, from the looks of it. Ideally the extension should be smart enough to figure that out itself without ever bothering users with the details, but meantime turning the preference into a purely js-based thing as such a gadget would need to be could prove problematic for the same reason this is there in the first place. -— Isarra ༆ 19:58, 23 September 2012 (UTC)

Date and time

 * Can't all of the date and time formatting be done in JS?
 * Is there any particular reason why the servers can't handle this? Losing this to a sea of gadgets would also be unwise given the international nature of many mediawiki-based projects. -— Isarra ༆ 19:59, 23 September 2012 (UTC)
 * If implemented right there is no cache breakage to worry about from this preference so it's not a burden. Browsers also do not always have the timezome the user using them wants. And none of them expose the user's preferred date format. So this cannot be done without a server side preference. This one absolutely should stay. Daniel Friesen (Dantman) (talk) 20:51, 23 September 2012 (UTC)


 * Move time offset to user profile section?
 * That would make sense. -— Isarra ༆ 19:59, 23 September 2012 (UTC)
 * Sure, we could clean it up so it's easier to understand and place it next to Internationalisation since they are related. Daniel Friesen (Dantman) (talk) 20:51, 23 September 2012 (UTC)

Editing

 * 27257 Size of editing window has no preview option
 * Yeah, what the crap does this row/coll nonsense even mean? -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * They're the value of rows="" and cols="" in the on the edit page. They end up controlling the size. cols="" doesn't have much effect in our modern skins because we use width: 100%; though it does affect some legacy skins, in fact there was a bug in that area recently. rows="" does have the effect of making the textarea bigger/smaller. However after we exterminate legacy skins I'm open to eliminating the preferences, hardcoding the rows/cols used by the textarea, and telling anyone obsessed with their size to just use their user-css to resize it. Daniel Friesen (Dantman) (talk) 20:45, 23 September 2012 (UTC)
 * That was a rhetorical question. It is completely unreasonable to expect our users to know this. I'm not sure what 'exterminating legacy skins' has to do with it, but the size of the text area either needs to be adjustable somehow, or would need intelligent determination according to screen size simply because there just plain is no one-size-fits-all solution with this. -— Isarra ༆ 21:15, 23 September 2012 (UTC)
 * This is one of the few features I frequently toggle, depending on what I am doing and where I am working. Having it further hidden would make it considerably more difficult, because ppeople wouldn't know about it. More generally, when people talk about doing things is css, they should realize that not everyone who needs a modification is comfortable with that--perhaps we should have a css preferences page for commonly used changes. 65.88.88.208 18:22, 27 September 2012 (UTC)
 * Can you explain further what you do with it? Why is the default size not good enough for you? Doesn't your browser support a native resize handle for textareas? Or is there another reason that native resize isn't good enough for you? Would that issue be fixed if we added some JS that will make it so that when you resize the textarea the height will be stored in localStorage and re-applied when you next visit the edit page? Daniel Friesen (Dantman) (talk) 19:09, 27 September 2012 (UTC)
 * I use the feature, changing my default size rather frequently, presetting the size according to what I will be doing and what computer I am working from. I know there are other ways or doing this, but I find this simplest. DGG (talk) 03:56, 26 October 2012 (UTC)


 * Show preview on first edit &mdash; gadgetize?
 * This is supposed to work right away without any extra load. Doing such a thing will destroy the feature with http latency and page jumps. You can't gadgetize it. Daniel Friesen (Dantman) (talk) 17:23, 23 September 2012 (UTC)
 * Indeed, previews can be big (like this section, it's pretty big); any delay could just make the thing unusable if it's bumping down the text area after load. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * You can gadgetize rewritting links to ?action=edit&preview=yes --Ciencia Al Poder (talk) 17:08, 29 September 2012 (UTC)


 * 27258 Enable section editing via [edit] links &mdash; why is this a user pref?
 * It probably shouldn't be. Disabling it leads to less specific edit summaries and having to load more, as well as encouraging edit conflicts... -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * See also Thread:VisualEditor/Feedback/3 comments. Helder 22:12, 23 September 2012 (UTC)
 * Please keep this. I prefer having this disabled. - Jc37 (talk) 01:52, 18 October 2012 (UTC)


 * Enable section editing by right clicking on section titles (requires JavaScript) &mdash; gadgetize?
 * Yes. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * Yes. Helder 22:12, 23 September 2012 (UTC)


 * 27197 Mark all edits minor by default &mdash; gadgetize?
 * This has already been disabled on some projects. Pulling the preference out of core entirely would probably be wise for the same reason they did that; anyone who does need it could probably use a gadget. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * right! better to remove entirely--has very unfortunate consequences for anyone trying to maintain quality. Some wikignomes may need it, so it should remain as a gadget, with a warning.65.88.88.208 18:22, 27 September 2012 (UTC)
 * Why not make this a user-right instead? Other user-rights related to minor edits: minoredit and nominornewtalk. It would be useful for the bot group, for example, and anyone using automated tools specifically for minor edits. - Jc37 (talk) 01:52, 18 October 2012 (UTC)


 * Prompt me when entering a blank edit summary &mdash; gadgetize?
 * Maybe, maybe not - for projects that really value edit summaries, keeping this with the main stuff would probably be a good idea. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * Should be kept. - Jc37 (talk) 01:52, 18 October 2012 (UTC)


 * Use live preview (requires JavaScript) (experimental) &mdash; kill from core?
 * We actually have some plans to fix one of the issues with live preview some time soon. Daniel Friesen (Dantman) (talk) 17:23, 23 September 2012 (UTC)
 * Actually, it should probably be enabled for everyone, it was even suggested on the design list recently. Recent improvements I coded up made this usable, there's a tracking bug and a rewrite by Krinkle now pending on gerrit. Matma Rex (talk) 17:58, 23 September 2012 (UTC)
 * Does this... do anything? -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * Yeah... it enables livepreview. ie: ajax preview.
 * Which does what, exactly? I could see no difference. Something along the lines of what the side-by-side preview does, I suppose, but where? -— Isarra ༆ 21:21, 23 September 2012 (UTC)
 * With the feature enabled, you don't need to reload the whole page to see how your changes will look like: the JavaScript will load only the parsed content, obtained from MW API. See also w:User:Js/ajaxPreview. Helder 22:12, 23 September 2012 (UTC)
 * Gadgetize? Since it's all JavaScript. There are other implementations of a live preview, like w:User:Cacycle/wikEd --Ciencia Al Poder (talk) 17:08, 29 September 2012 (UTC)


 * Warn me when I leave an edit page with unsaved changes &mdash; hmmm
 * Also part of Vector extension. — Edokter  ( talk ) — 19:46, 23 September 2012 (UTC)
 * Not "also", mw:Extension:Vector adds this preference and a few others. S Page (WMF) (talk) 21:01, 24 September 2012 (UTC)
 * My 'also' was refering to another option listed above ('Enable collapsing of items in the sidebar in Vector skin'). — Edokter  ( talk ) — 15:37, 9 October 2012 (UTC)
 * Would probably make more sense as a gadget for all skins. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * No! Warning users that they didn't save is a standard thing everything letting users edit content should be doing nowadays. This is something useful to every user, not just power users who enable a gadget. This should be baked right into core. We should make sure we don't have any situations it's firing where it shouldn't be. And then consider eliminating the preference and making it always-on. Daniel Friesen (Dantman) (talk) 20:45, 23 September 2012 (UTC)
 * That last bit sounds like a good way to get a wikipedian to punch you in the face. -— Isarra ༆ 07:15, 25 September 2012 (UTC)
 * Not really going to punch Dantman, but I find those prompts quite annoying (since they are on by default and I haven't customized all the wikis). Platonides (talk) 19:43, 13 October 2012 (UTC)


 * Enable input method &mdash; wtf does this even mean????
 * Ambiguously named. The "input method" refers to IME (Input Method Editor). This is added by Narayam. Daniel Friesen (Dantman) (talk) 17:26, 23 September 2012 (UTC)
 * Does this have any use to the general user? Any reason why they should see this? -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * Narayam is new. So I believe in the meantime users need a way to disable it if it doesn't work right and breaks their ability to edit. Daniel Friesen (Dantman) (talk) 20:45, 23 September 2012 (UTC)

Beta features
The WikiEditor extension adds this section and its two prefs. English Wikipedia names this section "Usability features" (with message prefs-beta).

Why does this section still exist? (Related bug: 28555)


 * Enable enhanced editing toolbar &mdash; stop supporting the old toolbar; come on; gadgetize?
 * People still use the old toolbar and like it. Matma Rex (talk) 17:58, 23 September 2012 (UTC)
 * People install the WikiEditor extension to replace the old toolbar, though. Having it add another preference instead of doing so outright is a little weird; a flag to use the old one with a gadget to toggle it would make a lot more sense. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * Enable dialogs for inserting links, tables and more &mdash; hmmm
 * I thought that was a gadget. -— Isarra ༆ 20:16, 23 September 2012 (UTC)
 * it's pretty important; I personally do not enable the dialogs, but I think most infrequent editors should--I'd suggest changing the default. 65.88.88.208 18:22, 27 September 2012 (UTC)
 * I agree with changing the default for the reason just given, though, like the previous editor, I personally do not enable them. DGG (talk) 03:59, 26 October 2012 (UTC)
 * m:Help:Edit_toolbar and possibly other pages confuse these editing preferences with the obsolete w:Special:PrefSwitch. Could someone with better understanding please edit that help page and other references to Special:PrefSwitch? Thanks!! -- S Page (WMF) (talk)

Recent changes
Hmmm.
 * 35768 Current positioning of the "Enhanced watchlist" preference is confusing. Helder 22:12, 23 September 2012 (UTC)

Watchlist
Hmmm.
 * "E-mail me when a page or file on my watchlist is changed" should appear here as well as in the User tab (e-mail options). Neukoln (talk) 23:16, 23 September 2012 (UTC)
 * Not possible, per 35768. Helder 23:36, 25 September 2012 (UTC)

Search options
Hmmm. Another per page results option? Hmmm.


 * This and the two above it could probably be merged, as they're all pretty similar stuff to the point of overlapping in places. -— Isarra ༆ 20:17, 23 September 2012 (UTC)
 * I agree on the first two. I think the 2 entries in the "display options" section of recent changes and watchlist, could probably be combined. Both of these are directly reliant on how active a particular wiki is. Search is a little different in usage though. - Jc37 (talk) 02:05, 18 October 2012 (UTC)


 * What about moving search preferences to the search results page, with a button to "use the current selection as the default search preference"? --Ciencia Al Poder (talk) 17:10, 29 September 2012 (UTC)
 * Hmmm, maybe. I'm not opposed to this idea necessarily. You don't think it would be confusing to fragment preferences like this? Special:Preferences would no longer contain all user preferences. Hmmm. --MZMcBride (talk) 01:36, 9 October 2012 (UTC)
 * I wouldn't mind, presuming that the preferences there would be "remembered". Though there are a LOT of namespaces now, which the average user will never use. shame this isn't clearer. - Jc37 (talk) 02:09, 18 October 2012 (UTC)
 * Proposed as 52817 --Ciencia Al Poder (talk) 19:19, 13 August 2013 (UTC)

Misc
Why does this tab exist?


 * Random diffs section... related to editing? Put it in that tab?
 * Omit diff after performing a rollback &mdash; why does this option exist again? sensible defaults...
 * Because when I added that feature a few people complained that it slowed down the loading of the rollback page when they made a lot of rollbacks of things like page blanking. Daniel Friesen (Dantman) (talk) 17:17, 23 September 2012 (UTC)
 * That is a terrible reason and they should be smacked. -— Isarra ༆ 20:17, 23 September 2012 (UTC)
 * It can be done as gadget, since you can add &hidediff=1 to the rollback URL to hide the diff for specific rollbacks. --Ciencia Al Poder (talk) 17:13, 29 September 2012 (UTC)
 * Things should be made easier, not harder. I'd rather see fundamental things like AjaxSysop in core (at least AJAXy mark as patrolled and rollback everywhere) so that this is less relevant. See also [//www.mediawiki.org/w/index.php?title=Requests_for_comment/Core_user_preferences&diff=593210&oldid=593186]. --Nemo 09:51, 14 October 2012 (UTC)

WikiLove should be a gadget, surely.
 * Anyone know why it was implemented as an extension in the first place? Is that reason still relevant? -— Isarra ༆ 20:18, 23 September 2012 (UTC)
 * Maybe one reason is so other wikis do not need to create lots of forks of the main code? For this, the Gadgets 2.0 will be of some help. Helder 22:12, 23 September 2012 (UTC)

Gadgets
Fine.

Threaded discussion
LQT wtf bbq.

Contests

 * Show a link to My Contests in the user menu.

A whole tab for this? Seems disproportionate and excessive. Really outside the scope of this RFC, though.

Edit review
FlaggedRevs wtf bbq.
 * At least the flagged revisions tab has a name that makes sense. Pending changes has a tab literally called 'Pending changes', which is not going to mean anything to most people. And these both could probably be merged into the editing section, since they're directly related to editing. -— Isarra ༆ 20:19, 23 September 2012 (UTC)

General comments
Krinkle should make that magical searchable gadget repository thing he was talking about. Unless that was someone else. But whoever it was... well, that would be useful. A lot of the more random preferences would go well dumped in a searchable repository, along with a whole slew of rather bizarre user scripts. And some not even remotely bizarre ones, for that matter.

Also, we should be careful when considering gadgetising commonly used things and accessibility features, if there are any. I'd also mention things added for the sake of compatibility, but chances are most people will have no idea what they mean and thus having an extra tick box with the main stuf won't actually help anything for them.

Also also, while gadgets normally function as snippets of js and css, would it not also be possible to have some that exist simply as a piece of js that toggles a non-visible preference flag? Or... something? -— Isarra ༆ 20:24, 23 September 2012 (UTC)
 * I believe that the "searchable gadget repository thing" will only be available on Gadgets 3.0. Helder 22:12, 23 September 2012 (UTC)

Mark some user preferences as "Advanced" instead of removing them

 * ''See also 40346

We're talking about removing user preferences, but what about "hiding" them by default? Some programs already follow the convention of having an option to "turn on advanced options", so advanced or obscure options are hidden by default to newbies who still may not understand what they actually do, and advanced users can enable them.

So, if I didn't miss anything, the rationale for the removal of user preference is to not overwhelm the user with so many options by one side, and probably delete some of them so they don't need to be taken into account when making changes to the code. The first part can be done by just hiding them, and yet allow advanced users to use them. Then we could argue which of them are useful at all and may be removed.

And I'm talking about some of them that probably only makes sense to a specific role of users, like sysops or patrollers, one of them being the "diffonly" preference (see my personal experience on ). --Ciencia Al Poder (talk) 11:28, 14 October 2012 (UTC)


 * Just for clarification, my intention is not to move them to another tab (like 40346 suggests). They may still remain on the actual tab as they are now, but hidden. That way they're still organized for people that want to see them. The idea is to add an additional boolean option "show advanced options", unmarked by default, that when marked would render them as they are now. Each option could be marked as "advanced" using a variable like $wgHiddenPrefs --Ciencia Al Poder (talk) 12:30, 14 October 2012 (UTC)


 * Strong support. "Show Advanced Options" is a widespread interface option. Progressive disclosure.
 * Because: We need Photoshop for powerusers, as well as MS Paint for the newcomers and casual editors.
 * MS Paint is great! It's Welcoming, and easy to learn via experimenting, and easy to create simple (sometimes even complex) projects in!
 * Photoshop is great! A dense abundance of menus, with a profusion of tiny and detailed-metadata, for those who need it! For those who spend hours, every day, for many years, working *hard* within it.
 * We want and need both. Progressive disclosure is the sanest way to do that. –Quiddity (talk) 01:34, 11 March 2014 (UTC)

Related bugs

 * 40346 – Convert some MediaWiki user preferences into JavaScript gadgets (tracking)
 * 52807 – User preferences in MediaWiki core to be removed (tracking)