Requests for comment/Core user preferences

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

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)

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)

Files
Weird section.

Advanced options

 * 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)


 * 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)


 * 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)


 * 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)


 * 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)


 * External editor
 * 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

 * 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)


 * 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)


 * 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)
 * 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)
 * 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)
 * 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)
 * 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)
 * 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)
 * 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)
 * 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?


 * 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)


 * 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)

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)

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)

Related bugs

 * 40346 &mdash; Convert some MediaWiki user preferences into JavaScript gadgets (tracking)