Talk:Community Tech/Global preferences

Feel free to write your questions, comments and suggestions on Global preferences here.

Local exceptions

Regarding local exceptions: Global preferences works on the basis of a single preference that you choose to be global -- for example, being able to set "show 500 edits in page history" on every wiki. "Local exception" means that if you choose to set "show 500 edits in page history" as a global preference, you would also be able to say "except on French Wikisource". What we'd like to know is which preferences you would want to set as global, and still have an exception. If there's a preference that you would want to be different on every wiki (for example: signature), then you wouldn't use global preferences as the way to express that.

• Global preferences without local exception: "I want this setting on all wikis. I can set it on all wikis, but then without exceptions."
• Global preferences with local exception: "I want this setting on almost all wikis. I can also make exceptions for some wikis."

In either case, you will still be able to use local preferences (what we have now):

• Local preferences: "I can choose settings individually for each wiki, but not all wikis at once."

Local exceptions use cases

Here's a concrete local override usecase that I would personally use:

As a user of several wikis with one "home" wiki that is used the majority of the time,

I want to see cross-wiki notifications only on my home wiki

so I can be informed of activity related to my account on other wikis in the Wikimedia SUL farm without being distracted when I am on a seldom visited wiki.

With global prefs this would mean that I would want to globally disable cross-wiki notifications and then override that global default on my home wiki (e.g. mw.o in my specific case). --BDavis (WMF) (talk) 20:19, 23 August 2017 (UTC)

It's sensible for many people, who use one wiki 95% of the time, but some other people have more than one wiki that they use a lot. For me it's (very) roughly 40% Hebrew Wikipedia, 30% English Wikipedia, 10% Russian Wikipedia, 10% mediawiki.org, and 10% everything else. I'm certainly not the only one with such diversity.

Whatever ends up being developed should serve all kinds of users. --Amir E. Aharoni (talk) 18:13, 27 August 2017 (UTC)

Languages

As someone who edits in more than one language, I want to be able to set global preferences for a language (e.g. Swedish or English) to be used on most wikis, and then keep the language where I can understand it, e.g. Norwegian, Danish, German, Icelandic et cetera. Not doing this would mean it would be more difficult to follow and take part in discussions on that wiki, so without the ability to override them, global language preferences would be useless to me. /Julle (talk) 20:30, 23 August 2017 (UTC)

+1 This was the first case I thought for a local preference override Platonides (talk) 06:56, 24 August 2017 (UTC)

Another +1: definitely useful. Litlok (talk) 07:04, 29 August 2017 (UTC)

Local exception use-cases, reasons, and importance

I'd like to be able to set these preferences as local overrides, because (reasons):

• "Email me when a page or a file on my watchlist is changed" -- Because: As specified in the example on the project page -- highly useful. --Quiddity (talk) 20:40, 23 August 2017 (UTC)
• "Language:" -- Because: As a monolingual user, but someone who needs to be able to temporarily see the local language in order to test things (e.g. RTL output), I'd like everything to be set to (English), but be able to toggle it to the local language for quick tests. (Note: uselang=foo doesn't solve it, because of actions like edit-preview). -- highly useful. --Quiddity (talk) 20:40, 23 August 2017 (UTC)
• "Show notifications from other wikis" -- Because: I have this turned off on my primary wiki to avoid distractions, but turned on everywhere else. -- somewhat useful. --Quiddity (talk) 20:40, 23 August 2017 (UTC)
• Language settings are definitely essential, especially if locally some extra buttons have been added, or scripts are active. It would be very confusing to have Dutch Wikipedia in English language settings, simply because I don't want anything but English on the other 200+ wiki's. Effeietsanders (talk) 20:52, 23 August 2017 (UTC)
• Email settings local override is helpful when you're being spammed from a particular project. Effeietsanders (talk) 20:52, 23 August 2017 (UTC)
• Display options make sense to have local override, because, well, every language has a different rhythm. Effeietsanders (talk) 20:52, 23 August 2017 (UTC)
• signature: For people that use to have custom signatures, I would expect that would be one they would be overriding in order to eg. link to a page on a given wiki on most wikis except a few ones they edit most. Platonides (talk) 07:28, 24 August 2017 (UTC)
• timezone: I use my local timezone in my home wiki, but have commons set to the server time (which happens to be UTC). Yet, if I wanted to make sense of timestamps on most wikis with odd ones, I would have to set a global preference with something I considered a sane default. Platonides (talk) 07:28, 24 August 2017 (UTC)
• minordefault -- Because: you make different types of edits on different wikis Platonides (talk) 07:28, 24 August 2017 (UTC)
• see wikidata edits in Watchlist: I only want this on my l0cal project, so that the other watchlists don't get flooded with notifications I already have seen - somehat useful. Ainali (talk) 08:02, 24 August 2017 (UTC)
• notifications for page links: I only want this on my l0cal project, because there is the only place I might follow up on them - somewhat useful. Ainali (talk) 08:02, 24 August 2017 (UTC)
• I would override followed pages notifications and language settings, as explained above, plus gadgets in that future when global gadgets will exist.--Strainu (talk) 08:05, 24 August 2017 (UTC)
• Especially the notifications have made it essential to have global settings. And your local settings depends on what kind of activity you have there. -- Innocent bystander (talk) 09:10, 25 August 2017 (UTC)
• I contribute to many projects with different frequencies [1] and hope to be able to keep specific settings for each of them, in particular language, signature, watchlist, notifications. Thanks, — Racconish^☎ 15:23, 28 August 2017 (UTC)

Racconish: You'll definitely be able to keep different settings. The thing being discussed here is the ability to have global preferences and exceptions to them, when you want the same preferences for most but not all wikis. Whatever the outcome, you will still be able to choose to not have global prefrences at all. /Johan (WMF) (talk) 15:43, 28 August 2017 (UTC)

Global preferences and the option to override them in specific projects is fine for me. Thanks, — Racconish^☎ 15:53, 28 August 2017 (UTC)

• "Language:" -- Because: Most time, I am using German as language, but when I am explaining my Timorese friends, how to do Wikipedia, I need to know the terms in their language. -- highly useful. --J. Patrick Fischer (talk) 18:15, 28 August 2017 (UTC)
• I have activated the Wikidata edits in my German watch list, I do not need them in other languages or in Wikinews. --Matthiasb (talk) 21:41, 28 August 2017 (UTC)
• I would override these preferences: "Email me when a page or a file on my watchlist is changed", "Language:", signature, minordefault, options to hide/show edits in recent changes and watchlist. --β₁₆ - (talk) 07:51, 29 August 2017 (UTC)

importance

For me, local override is an essential element, without which the whole project could fail to be accepted by the community. My behavior has to be different in different communities because the projects are different set up. If I'm forced to use settings designed for enwiki on nlwiki, that would negatively impact my experience and interaction with nlwiki community. Effeietsanders (talk) 20:52, 23 August 2017 (UTC)

It should be noted that it would be incredibly helpful to easily identify which wiki's are overriding the default, and to reset those, if wanted. Not sure how that would find its way to an implementation, though. Effeietsanders (talk) 12:51, 24 August 2017 (UTC)

Effeietsanders, thanks for your comments. I may have miscommunicated the way that the feature works, so I want to make sure. With global preferences, you would choose a specific preference to make global. It's not a whole set of preferences that have to be global everywhere. The reason I'm asking is because you said "if I'm forced to use settings designed for enwiki on nlwiki" -- you wouldn't be forced to do anything, you would choose a single preference that you'd want to set on all wikis. Did that come across? I may need to rewrite some of the page to make that more clear. -- DannyH (WMF) (talk) 15:01, 24 August 2017 (UTC)

"It should be noted that it would be incredibly helpful to easily identify which wiki's are overriding the default, and to reset those, if wanted." This is a great point Effeietsanders, and one that I think has not been recognised by too many people in these discussions. It revolves around gaining insight into a complex situation. I had not considered this and I don't think most developers had considered this either, but now that I think about it, you are 100% correct. If you allow 'deviations', it should be easily discoverable where these 'deviations' exist. DannyH (WMF) please make sure this suggestion is logged appropriately, it's value is likely underestimated by people's short term desire of having an option, without them considering the longer term usability of the feature. —TheDJ (talk • contribs) 08:48, 29 August 2017 (UTC)

@DannyH (WMF): I indeed understood it to be all or nothing - but that may have been because I read it too quickly. However, even on a setting-by-setting basis, I may want to standardize my signature for most wiki's using whatever I have on enwiki, but not use that on nlwiki.

@TheDJ:: Yeah, good summary, thanks for emphasizing that. One additional, related, point is the situation where I deviated a setting on frwiki, and after a year I decide that this is no longer necessary, and that my default will be good enough. Then, what do I do? If I just change it to whatever my default happens to be, will it re-merge it into the default? I would imagine that re-attaching it would have to be a separate step. But especially for those cases it is hard to see which are on the default, and which are just happening to have the same value :) Effeietsanders (talk) 08:55, 29 August 2017 (UTC)

Home

Hi. I think it's necessary to have local override. I'm a very heavy user of special:preferences, and I have three sets of preferences values - one for my "home" wiki, one for almost all rest wikis I enter, completely different from the first, and one for about two wikis which I prefer to edit from time to time, and here the preferences values are the middle of previous two sets. Global preferences are a miracle that I always wanted, but I can't think about one single preference that I use the same on all wikis - always is some wiki with different value. So without local override it will be irrelevant for me. So please add it, and until then, maybe you can think about a local override simple placeholder - a checkbox on special:preferences "do not use global preferences on this particular wiki". Thank you. IKhitron (talk) 21:19, 23 August 2017 (UTC)

Yes, I have at least one edit on around eighty wikis, so I really want global preferences, but without local overrides I wouldn't be able to use many of them, simply because of different editing patterns on the wikis where I'm most active. To take a specific example, I want to have "Edit pages on double click" on a fair number of wikis because I'm more likely to edit than to read them, but can't have it on the smaller number of wikis where I read regularly (Wiktionaries, a dozen Wikipedias, Swedish and English Wikivoyage and so on), because I'd accidentally end up in editing mode all the time. /Julle (talk) 16:55, 24 August 2017 (UTC)

Previous discussions

Hi. I'll just point to the previous discussions about this, such as phabricator:T154956#2929966. --MZMcBride (talk) 04:12, 24 August 2017 (UTC)

Everything should be overrideable

Looking through preferences, I thought that the only thing I will not override for sure is gender. Being active on different levels in different wikis, I may need to override pretty much every other preference, and this would be essential for me:

• languages: for example, I prefer English on Commons as almost everything is primarily in English there and my native Ukrainian on Wikidata to see all labels and descriptions in Ukrainian
• signature: I would at least translate the word "talk"
• email: I may want to receive emails from wikis where I follow few pages but not from Commons where I watch thousands of files
• appearance: I am using Monobook on wikis where I have advanced rights (to have easier access to admin buttons instead of the drop-down menu) but I am using Vector on Wikidata as Monobook does not really fit there. I can also change other settings depending on particularities of some wikis
• editing: I may want somewhat different settings for wikis where I need to edit quickly (e.g. I want to have edits minor by default as I do many of them) and for those where I want to make sure I do not break anything (and thus I want to have preview by default etc.)
• recent changes: settings may vary depending on whether one is an RC patroller or not
• watchlist: I may want to see even the smallest edits on Meta where I mostly watch discussions and Grants pages but I am not sure I want to see these edits on Commons where I watch thousands of files
• search: I may need a strict search in my native language (e.g. when I am fixing typos on my home wiki) but correct up to two typos in languages where I can make mistakes in queries myself
• gadgets: pretty obvious I think
• notifications: these depend on the level of my activity on a given wiki: I may want to have Page link notifications on Meta where I mostly create Grants/programmes/events pages but not on Wikidata where I can happen to create a completely random item.

Of course, personally I am not sure I will override all of these at the same time, but I already rely on some of these local preferences and keeping them without affecting other wikis is crucial for me — NickK (talk) 13:58, 24 August 2017 (UTC)

NickK, I want to make sure that I haven't miscommunicated how the feature works. The way that global preferences works is that you pick a specific preference, and make that one preference global across all wikis. It sounds like you might have interpreted it as a complete set of preferences that is made global. So, for example, if signature needs to be different on every wiki, you wouldn't choose to set that one as a global preference. Did that come across? -- DannyH (WMF) (talk) 14:54, 24 August 2017 (UTC)

@DannyH (WMF): Yes, I understand it correctly. For example, I want to have the same signature in most wikis (let's say NickK (talk)). However, I found that the Ukrainian word for "talk" ("обговорення") is twice as long as my username, thus I want to override this global preference and use an abbreviation "обг." instead of the full word "обговорення" and set NickK (обг.) as a signature in all Ukrainian wikis. Does this make sense? I would specify that this particular case is rather hypothetical as I am not a big fan of custom signatures, but a lot of other things are real (e.g. I want to have Monobook as a global preference but override it for Wikidata indeed) — NickK (talk) 15:19, 25 August 2017 (UTC)

NickK: Okay, thanks for clarifying! That does make sense. -- DannyH (WMF) (talk) 17:25, 25 August 2017 (UTC)

I agree, I think it is very important to have local overrides. I would imagine that I would use the global preferences to configure wikis that I am not very active on, but for each wiki I am very active on, I would want local customizations that would conflict with my global preferences. If you want me to give more specific examples, I can do so. Thanks! --Wikitiki89 (talk) 17:21, 28 August 2017 (UTC)

Wikitiki89: If you'd be willing, more specific examples would be helpful! /Johan (WMF) (talk) 09:40, 29 August 2017 (UTC)

Well it would be nice to see a list of which specific settings will be possible to globalize (I presume gadgets, for example, would be very difficult, because every wiki has a different set of gadgets). For the settings that NickK listed above, I generally agree with exactly what he said about them. --Wikitiki89 (talk) 17:24, 29 August 2017 (UTC)

Watchlist

I want to use global settings to raise the period of time to display to a month for almost all wikis, because I rarely edit there, but keep it for a shorter period of time on the few wikis where I edit the most. It would be annoying to not be able to do this, and potentially make the global setting useless in this case, but not as annoying as e.g. languages. /Julle (talk) 23:04, 25 August 2017 (UTC)

I second that. Watchlist time span is probably and only non-global preference I personally need at the moment. I check my home wiki very often, and I have a high rate of activity on my home watchlist. Setting the home watchlist to more than a few days would be useless and severely cluttered. On other wikis I set the watchlist to a month to be sure I don't miss anything, and that's fine because I'm only watching a low rate of activity on those wikis. Alsee (talk) 12:23, 4 September 2017 (UTC)

UI language setting

The UI language setting is often brought up as an example of a global preference, but it's not necessarily the best example of one. There are several reasons for this:

• Some people indeed want to see the same UI language everywhere. Possibly this is the majority, but I suspect that it's not a 97% majority. I'd guess that it's more like 70%.
• By default, I want to see every wiki in the language of that wiki, because usually I want see it like its readers see it. Including incomplete translations, bugs, etc. Occasionally I switch to another language. Again, I suspect that there are more people like me, and I'm not the only one who's crazy.
• Using English in a right-to-left wikis works surprisingly well (especially since 2011, thanks to SPQRobin and many others who helped). But nevertheless, it's not perfect, and it probably never will be.

So—this can be a global preference. Just don't assume that it's the most important one that must be global, or that it's the best example. --Amir E. Aharoni (talk) 18:22, 27 August 2017 (UTC)

Amir E. Aharoni: The problem isn't making something a global preference, it's the combination of making it a global preference and being able to locally override it. /Johan (WMF) (talk) 11:17, 28 August 2017 (UTC)

In my case, I prefer to set the language to English, except on Portuguese wikis, Wikidata and wikis where I use the Translate extension. Helder 13:27, 29 August 2017 (UTC)

Preferences that aren't available globally

Some preferences are not available globally. A simple example is a beta feature that exists on some wikis, but not on others.

What will happen with these preferences? --Amir E. Aharoni (talk) 18:23, 27 August 2017 (UTC)

Amire80: I answered a similar question a couple sections down, about left to right and right to left wikis. Let me know if that does or doesn't make sense. :) -- DannyH (WMF) (talk) 22:38, 30 August 2017 (UTC)

Header banners

I hope that it will include the header banners, because today we have to close them on every wiki one by one. JackPotte (talk) 16:02, 28 August 2017 (UTC)

++ - Amgine/^meta 17:22, 28 August 2017 (UTC)

Same for the annoying feature pop-ups, like when you visit every wiki's recent changes page you will get the popup New beta feature available for this page. Try the "New filters for edit review". Find the most relevant edits for your review needs. It's very annoying to close the same stupid ad (sorry) in over 700 wikis one by one. Stryn (talk) 17:34, 28 August 2017 (UTC)

JackPotte, Amgine and Stryn: This is only going to apply to settings that are in the Preferences tabs. Annoying header banners and pop-ups are still going to be annoying. Sorry. :) -- DannyH (WMF) (talk) 22:43, 30 August 2017 (UTC)

For what it's worth, someone should really look into making pop-ups use a global data-value. When I visit a wiki for the first time, I really do not need another 'welcome' pop-up asking whether I want to use VE or Wikitext. Alsee (talk) 12:35, 4 September 2017 (UTC)

left to right and right to left wikis

Some settings only work if a page is left to right or right to left so how would this work for those wikis Flow234 (talk) 22:24, 28 August 2017 (UTC)

Flow234, the preferences will match the wiki that you're currently on. You'll be able to access Special:GlobalPreferences from any wiki -- for example, it.wikipedia.org/wiki/Special:GlobalPreferences -- and the preferences that you see there will match what's on your Italian Wikipedia Preferences page. So if there's a preference that exists on Italian and not on Hebrew, then you'll only see it on the Italian Wikipedia Global Preferences page. If you set that preference globally, it'll apply to all of the wikis that have that preference. Sorry if this is a confusing answer, this feature is tricky to describe. :) Let me know if that didn't make sense. -- DannyH (WMF) (talk) 22:32, 30 August 2017 (UTC)

I think I can describe it more clearly: Some preference options may be hidden on some wikis. If it is hidden, it does not effect that wiki. Gadgets in particular are locally installed objects, so specific Gadget-preferences often won't exist at other wikis. Alsee (talk) 09:07, 4 September 2017 (UTC)

Skins

I would like to be able to set for my account a skin for all my accounts at all wikis. —MarcoAurelio (talk) 09:58, 29 August 2017 (UTC)

"Cost" of this feature?

Costs in terms of site performance were mentioned in the past as a reason why changes in preference settings for millions of accounts weren't ideal. --Elitre (WMF) (talk) 10:11, 29 August 2017 (UTC)

I don't think that's really relevant here. This would just affect loading of preferences at the beginning of requests for logged-in users. The cost there is in *updating* millions of preferences for users which is a very costly migration. 😂 (talk) 00:24, 30 August 2017 (UTC)

Setting local exceptions: interface idea

Hi to everyone who's posted about the local exceptions; I'll ping people at the end of this message. Thanks for giving your feedback -- these conversations have helped me to understand people's appetite for setting exceptions. I was thinking that people might just want to set a few common things as local exceptions, but folks here have described a lot of different use cases, so it looks we need to figure out how to make this work.

The big challenge for this project is how to give people the options they want, without creating a UI nightmare. I think that the core idea of GlobalPreferences as a separate page, with a series of checkboxes down the side, is relatively easy for experienced contributors to understand. Adding the possibility of local exceptions for almost every preference is a new level of complexity that we'll need to plan carefully.

A big question for local exceptions is whether you set the exceptions on GlobalPreferences, or in the local Preferences page. I drew a wireframe for what it could look like if the exception was in GlobalPreferences -- it's here, on the project page. That wireframe doesn't really work, because it involves a form field that would have to accommodate multiple different scripts and LTR/RTL. So that doesn't work.

So here's wireframes for the other way to approach it, which is setting the exception on the local Preferences page. I'll walk through the idea, and I'd like to know what you think.

Current Special:Preferences layout
The current preferences layout, without global preferences.

Local preferences, when there's a global preference (current version)
The current version of the extension that we're building.
You've set a global preference in Special:GlobalPreferences, and now you're looking at the local Preferences page on your home wiki.
The preferences that have been set globally are grayed out, with a line underneath telling you that you can change that preference on GlobalPreferences.

Local preferences, with a new "make a local exception" checkbox (proposed change)
The proposed change, to add local exceptions.
You've set a global preference in Special:GlobalPreferences, and now you're looking at the local Preferences page on your home wiki.
The preferences that have been set globally are grayed out, plus there's a checkbox underneath that says, "Set a local exception for this global preference."

Local preferences, with the "make a local exception" checkbox enabled
The proposed change, using the local exception checkbox.
The preference is live again, and you can set it to whatever you want the local exception to be. The global preference is still set on the GlobalPreferences page.
If you uncheck this checkbox, the preference will return to the state it was in on the previous wireframe -- a grayed-out preference that shows what you've set as a global preference.

One positive thing about this approach is that you can always see the preferences of the wiki that you're currently on, and if you see a preference that you want to change locally, then you can change it right there.

One downside of this approach is that if you want to see a list of all the wikis where you've made exceptions to a preference, it won't be on GlobalPreferences. You'll have to look on each local Preferences page where you set that exception.

What do you all think? Pinging people who responded to the local exceptions questions: Platonides, Litlok, Effeietsanders, Ainali, Strainu, Innocent bystander, Racconish, J. Patrick Fischer, Matthiasb, Beta16, TheDJ, IKhitron, NickK, Wikitiki89, He7d3r, MZMcBride. -- DannyH (WMF) (talk) 20:40, 30 August 2017 (UTC)

It looks good to me. I don't think this approach would preclude also having a list of exceptions in the global preferences interface. --Wikitiki89 (talk) 20:49, 30 August 2017 (UTC)

Brilliant idea. Two suggestions: (1) Think about adding a checkbox per wiki, on preferences or on global preferences, "use only global preferences on this wiki", which overrides checkboxes for each preference. (2) When you check "use local" you suggested, gray disappears and the value is changed from the global to last local value ever setted, if any. IKhitron (talk) 20:59, 30 August 2017 (UTC)

IKhitron: Sorry that I'm being confusing. (1) We don't need a checkbox that says "use only global preferences on this wiki," because that's how global preferences works. If you set a global preference, then it'll appear on every wiki. (2) I think you're describing how the feature works here, as well. Check out the video below, I hope that makes things more clear. Let me know if I'm not understanding what you mean. -- DannyH (WMF) (talk) 23:50, 31 August 2017 (UTC)

Thank you, DannyH (WMF). (1) That's not I'm talking about. If there are some global preferences and some local overrides, and one day I want to remove all local overrides from one particular wiki for one hour 32 minutes 11 seconds, I can click on all local checkboxes before, remember what they are, and click on all of them after. I suggest one checkbox that totally overrides all these - one click before makes the wiki global and one click after returnes exactly the previous state. (2) No, it does not. At least not in the video. For example, if I want es language locally at fr wikisource, I put it in local preferences. One day I decide to make global en language, so it will be also there, "en" gray. But when I click on use local over there, I'd like that it will remove gray, and change from "en" to "es", the last local value. Hope I explained better. IKhitron (talk) 12:06, 1 September 2017 (UTC)

Overall the idea looks good, thanks. Can we simplify it to keep everything in one line?

• For instance, if a person has a global preference, it shows the value of this global preference in the box, and any action with this box will overwrite that global preference (maybe with a warning message). If a person has already overridden the global preference, it can show a button like "Reset to global preference".
• Or have a variable message with a button in the same line. For example, the message "This is a global preference. <Override locally>" when the global preference is active with the button activating the local selector. The corresponding message can be "This global preference was overriden locally. <Restore global>" with the button restoring default.

The main idea is to avoid too complex and similar messages, as having the same long message everywhere would be rather annoying — NickK (talk) 21:03, 30 August 2017 (UTC)

Thanks for sharing. It looks nice, for the scenario where we're talking about one or two settings that have a global setting. If that's the idea, then go ahead. If you're planning to have lots of options globally set - you may have to find a more dense version, or I'd loose the overview in the settings page. I can for example imagine that the whole line of 'this is globally set' can be summarized in "(global default setting)" behind the number. Maybe even with a checkbox "overrule locally". But I admit, dense text typically translates poorly.

There is another approach though. And that is to put the option to locally overrule in the global settings page. People who want to overrule locally, are typically experienced editors. So keep one place of truth, the global settings. There they can tell you that they want a certain setting to be local on nlwikipedia, bewikisource and ukwiktionary. The rest is global by default. Once that option is set, they can go back to the local page, and the option will be black and adjustable. You could even consider not to put this on meta (which also needs local settings), but on settings.wikimedia.org or something. That should give you more freedom. Just thinking out loud here.

I'm especially curious how you're going to provide an overview of all the settings worldwide. Perhaps the username merge is a good experience to draw from? Effeietsanders (talk) 21:03, 30 August 2017 (UTC)

It looks good to me. Placing a <Override locally> link in the same line as "This is a global preference" would help in that it adds a couple of lines per preference, enlarging the whole Special:Preferences. However, given that this should also work on UAs without javascript, it'd probably be hard. How would the Special:GlobalPreferences UI be? Platonides (talk) 21:52, 30 August 2017 (UTC)

Seems headed in the right direction. I have faith that UI/UX issues will get ironed out by folks more qualified than I am. At a purely technical level it seems reasonable that the lookup of preferences follows a cascade where resolution looks something like (lowest to highest precedence): defaults -> global settings -> local settings. I think this would only add one net new database query to looking up a preference. --BDavis (WMF) (talk) 22:07, 30 August 2017 (UTC)

Thanks for pinging us DannyH (WMF), I really appreciate it. The current proposal for local changes works, but I agree with NickK that it could become quite crowded for a wiki with lots of overloads. I am personally thinking about the following workflow (very similar with your proposal, but with less text/controls/clicks I would think):

• Controls for Global preferences; you need to have those available at a moment's notice, not force people to go to a different page:
  • A checkbox for enabling Global preferences - that could be set globally (e.g. from any wiki, it would affect all wikis) or per wiki, whichever is easier. The first time that would be checked, it would populate the global settings with the settings from the current wiki. Re-enabling global preferences after they've been disabled could either transfer the current local settings again or go with the old global settings - not quite sure here.
  • A button for resetting all local overrides. This one would appear/be enabled only when global preferences are enabled and overrides are in effect on the local wiki. Optional, but useful.
• Individual controls for overriding/resetting anything that can be overridden
  • The local controls would be active at all times - no need to click on something to edit. Changing a setting from the global value would prompt a confirmation alert (Are you sure...? Yes/Always/No)
  • The resetting control should be easy to use, but at the same time not as long as in your proposal. I would propose a link on the same line as the control whenever possible instead of a checkbox. The text should be as short as possible (e.g. "Reset to global") and if it doesn't break accessibility some fancy effect could be used, kind of like the Echo "read" button.
  • If there is no way to put a reset control next to every option, a single one per preferences section (not page!) should work as well. The sections are generally short and/or contain tightly related options.

Sorry for the wall of text, if something isn't clear I'll try to explain it more clearly or even draw something. Best of luck with the project!--Strainu (talk) 22:19, 30 August 2017 (UTC)

Responding to Platonides, since we seem to have the same idea about placing the link on the same line as the control: why do you see an issue with links and browsers without JS? I would say a link would work better than a control in those environments, as it can force a page reload with a single click; I am not aware of a way to do that with a checkbox without JS or a 'submit' button.--Strainu (talk) 22:31, 30 August 2017 (UTC)

I was thinking not doing it with javascript would require a separate page for submission, Strainu. Certainly, a link that reloads Special:Preferences with the enabled status of a preference changed would work. :) Platonides (talk) 22:53, 30 August 2017 (UTC)

I see... You are right, of course, clicking on that link could make one lose previous non-saved changes in other fields. I'll have to think if there is any way the risk could be totally eliminated (in my version, where editing does not require a click, the risk would be minimized, but not removed entirely)--Strainu (talk) 23:09, 30 August 2017 (UTC)

It looks good to me. In a scenario where a user has almost all global preferences except one or two, with the message "This preference has been set globally..." and checkbox "Set a local exception...", maybe the page become very long. If is possibile to use only a single line (for example with a variable message like proposed by NickK) maybe it will be even better. Thanks and good work! --β₁₆ - (talk) 13:00, 31 August 2017 (UTC)

Yeah, that's a good point about adding two long messages under every global preference. I changed it in this wireframe to one line, a checkbox with the text "Set a local exception to this global preference". Global preference would link to your GlobalPreferences page.

The top two preferences in this wireframe look extra busy because those preferences already have some supplementary text. :) I added a third preference to the wireframe so that we could see what it looks like when there's just one line. What do you think? -- DannyH (WMF) (talk) 21:44, 31 August 2017 (UTC)

A All the links to global preferences go to the same page? B What about extra column? Most of preferences does not need the whole width. IKhitron (talk) 21:55, 31 August 2017 (UTC)

IKhitron: We're not putting the global checkboxes on the local Preferences page, because it would be really confusing for the regular editor who only works on one wiki. The extra stuff on the local Preferences page only appears if you've already gone to GlobalPreferences and chosen to make something global. -- DannyH (WMF) (talk) 23:36, 31 August 2017 (UTC)

Sorry again, DannyH, I can't understand this answer either. Maybe my very poor English makes you answer on the things I did not say. IKhitron (talk) 23:40, 31 August 2017 (UTC)

IKhitron: Oh, I'm sorry. I'll try again. :) Your question "All the links to global preferences go to the same page?" -- Yes, they'll go to the GlobalPreferences tab that you're currently on. If you're on the Recent changes tab in Preferences and you click on the "global preferences" link, you'll go to the Recent changes tab in GlobalPreferences. The video below shows how it'll work. Your other question "What about extra column? Most of preferences does not need the whole width." -- This is the question that I didn't understand. I thought you were suggesting that we put the extra column of checkboxes on the local Preferences page. Can you say more about this question? -- DannyH (WMF) (talk) 23:47, 31 August 2017 (UTC)

Thank you, DannyH. (1) As I expected. But it's redundant to have many links to the same place, it's better to have one link from each tab. (2) Sorry. You put the checkbox with explanation below the value, and it takes place - twice lines. I suggest to put it in the same line, in the empty right side of preferences tab. Meaning, create one more virtual columns, just for global preferences, so the local preferences tabs will not grow. IKhitron (talk) 12:13, 1 September 2017 (UTC)

days to show in recent changes: 3 X set a local exception for the global preference

Video clip showing how you can switch from Preferences to GlobalPreferences, and back again.

I have responses to a bunch of people's comments above; I'm going to do all of them here. :)

IKhitron: If you want to use only global preferences on a wiki, then you don't need an extra checkbox; that's what happens automatically. When you set a global preference, it'll be on every wiki. The only extra thing you'd have to check is if you wanted to make a local exception.

Wikitiki89: Yeah, it could be possible to have a list of local exceptions on GlobalPreferences for each preference. It's a little unwieldy, but it could work -- I'll try making a wireframe.

NickK: You're totally right about having too many lines of text. See the above wireframe for an updated version.

Effeietsanders and Strainu: You'll be able to access Special:GlobalPreferences on every wiki, and what you'll see is the preferences that exist on that wiki. So on French Wikipedia, you'll be able to set global preferences for all of the options that exist on French WP. If there's a preference that exists on Hebrew WP and not on French WP, then you'll see it on he.wikipedia.org/Special:GlobalPreferences and not on fr.wikipedia.org/Special:GlobalPreferences. It's a tricky thing to explain, so Sam, the developer working on this project, has created this video that shows how it works, which I'll post here and on the project page. -- DannyH (WMF) (talk) 23:32, 31 August 2017 (UTC)

Sorry, DannyH, I don't understand. I spoke about five different things, and I can't see your answer has to do with any of them. My apologies. IKhitron (talk) 23:37, 31 August 2017 (UTC)

IKhitron: Sorry about that. I responded above to your messages; I hope I'm understanding them correctly now. -- DannyH (WMF) (talk) 23:51, 31 August 2017 (UTC)

Thank you very much, it's much better. My apologies again. IKhitron (talk) 12:16, 1 September 2017 (UTC)

DannyH (WMF): The whole list doesn't have to appear right on the global preferences page. There could be a link that says "5 local exceptions", which expands into a list or takes you to another page that lists them (or something of the sort). --Wikitiki89 (talk) 14:39, 1 September 2017 (UTC)

Links

FYI, some small discussions in other places: German Wikipedia, Dutch Wikipedia, English Wiktionary, Italian Wikipedia. /Johan (WMF) (talk) 15:18, 31 August 2017 (UTC)

Languages and families

There are some preferences, which I would like to set for specific group of wikis, usually for one family. I would like to have global settings for all Wikipedias, but different eg. for all Wiktionaries (and probably different for the rest (wikinews, wikiquote etc.)) (example)

There are also some setting which I would like to have for all wikis in my native language (cs) or in slovak language (sk).

Setting exceptions from global preferences for 7 projects in one language is possible, but for 150 Wiktionaries is not so easy. JAn Dudík (talk) 21:26, 2 September 2017 (UTC)

I can see why you'd want that ability, but ouch. I think it would require too much of an interface nightmare to do things like "all Wiktionaries". Maybe there could be an external tool that could push out bulk-local customizations like that. Alsee (talk) 11:45, 4 September 2017 (UTC)

Suggested interface design

Assumptions:

1. The common/default case is for a preference to be global.
2. Changing a preferences between global/local is the uncommon action.
3. Once a preference has been set as local, changes to that setting are normally expected to stay local.

I'll describe the interface with a user story:

• When I first go to Preferences, I find that almost nothing has changed. However I do see one new control-object. It has a label such as "Manage global/local preferences".
• I click the new control. All of the preferences are now greyed out / disabled. Empty check boxes appear to the left of each preference item. Above this column of check boxes I probably see something like "Make this preference local".
• I click one of the check boxes. The preference gets highlighted with a pale green background (the reason for this will be clarified later.) That preference item is unlocked / no longer greyed out. I can change preference setting.
• I click the SAVE button. That preference is now set to a local override. The setting is saved as a local value.
• I click a different preferences tab (Appearance/Editing/Etc). I am still in "Manage global/local preferences" mode. I can set other local preferences.
• I click to turn off "Manage global/local preferences", or I leave the Preference page and I come back later.
• I see the standard Preferences page, I see the new control for "Manage global/local preferences", and I also see that local preferences are highlighted with a pale green background.
• I change a green preference and click save. This changes the local value. The preference remains local.
• I change a non-green preference and click save. This is a global preference, and this changes the global value.
• I turn on "Manage global/local preferences" again.
• I see local preferences have a filled check box. For a consistent visual pattern they are highlighted in green. The preference item is unlocked / no longer greyed out.
• I clear one of the filled check boxes. The green highlighting disappears. It is grey/locked. I click SAVE.
• Local-override has been disabled for that preference item. When I return to the normal Preferences view I see that item is no longer green, and I see the global value.

Alsee (talk) 10:33, 4 September 2017 (UTC)

Hi Alsee, I'm not sure why the interface that you're describing would be better than the one we've been talking about in the wireframes on this page. The local/global preferences distinction is hard to get across, so in our current design, they're split into two different pages -- Preferences for local, GlobalPreferences for global. Your idea is similar -- both of our interfaces involve clicking a special control, and going into "global/local" mode. But your interface relies on an association between local preferences and the color green, which I think is difficult to establish. Can you say more about why you don't like the wireframes we've been talking about? -- DannyH (WMF) (talk) 21:24, 5 September 2017 (UTC)

With this concept there's only one preferences page, and it's an extremely clean page. It only adds one extra button at the top, plus passive highlighting on localized preferences. I can see and edit all of the preferences on this wiki, regardless of whether it is global or local.

The rare case is wanting to alter whether or not a preference is using a localized value. In that case I click the new button to enable/disable local override for particular preferences. The ability to edit the preference itself in this mode is actually optional. Alsee (talk) 23:38, 5 September 2017 (UTC)

I'm sorry, I don't see much of a difference. The design that we've been talking about starts out simple, and gets progressively more complicated based on what the user chooses to do. At first, there's just the link to "Set your global preferences". When you click that link and go to GlobalPreferences, you get the ability to set a global preference. Once you've set a global preference, then it gives you the option to set a local exception. Going through that process should help people understand the system. The system that you're describing bundles the global preference/local exception concept into one step. That might make things easier to understand, or it might make it harder to understand. My gut feeling says it would be harder to understand, although I could be wrong. I don't see a super compelling reason to switch to your design idea. -- DannyH (WMF) (talk) 22:27, 6 September 2017 (UTC)

Global preferences interface available for testing on Commtech wiki

#1. On Preferences: Edit area font style default is "Monospaced font".

#2. Preferences: click on the link for Global Preferences.

#3. Global Preferences: Haven't set any global preferences yet, everything looks disabled.

#4. Global Preferences: There's a highlight when you hover over the global checkbox.

#5. Back to Preferences: Edit area font style is "Sans-serif font", you need to go into Global Preferences to change it again.

Hi everyone, we've got a version of the Global preferences interface available for testing on our team's development wiki, and you're invited to check it out and let us know what you think.

To see the interface -- go to commtech.wmflabs.org. You'll have to create an account, because this is a development wiki that's not connected to all the others. (Make up a new password when you create the account -- this wiki doesn't have the security that the real wikis do, so don't expose your real password.)

For the captcha, the channel is called #wikimedia-commtech.

Once you've created an account, you can click on Preferences, and you'll see a link to "Set your global preferences" on the first tab.

The preferences you set on the Commtech wiki won't affect the real wikis, so feel free to play with it and change preferences.

Our main question is: Does this interface make sense to you? Can you set a global preference, and turn it off? Do you feel confident that you understand what will happen when you click save? We're interested in any thoughts or questions that you have about it. What do you think?

Pinging people who've posted on this page before, sorry if this is pingspam: Platonides, Litlok, Effeietsanders, Ainali, Strainu, Innocent bystander, Racconish, J. Patrick Fischer, Matthiasb, Beta16, TheDJ, IKhitron, NickK, Wikitiki89, He7d3r, MZMcBride, Alsee. -- DannyH (WMF) (talk) 22:35, 2 November 2017 (UTC)

Thank you, but I do not understand. Is there one more test wiki that will be afftected by this simulation, and we can see there the influence, and choose global vs. local? IKhitron (talk) 22:47, 2 November 2017 (UTC)

Could you post some screenshots so that we don't all have to create accounts? --Wikitiki89 (talk) 22:56, 2 November 2017 (UTC)

Wikitiki89: Yeah, that's a good idea. I'm posting screenshots now... -- DannyH (WMF) (talk) 18:47, 3 November 2017 (UTC)

Thanks DannyH. Some impressions:

• The «Set your global preferences» is not easily discoverable. Maybe it should be on the top?
• The combo boxes no longer appear on the same line as the label (eg. compare Special:GlobalPreferences#mw-prefsection-rendering and Special:Preferences#mw-prefsection-rendering).
• The checkbox on the gadgets tab is not aligned
• I would probably set a tooltip on the "global checkboxes" explaining its meaning
• The "Make this setting global" text at the top doesn't make much sense (is it expected to be a column header?)
• I can set global email options that are not allowed by Special:Preferences

Overall, I think the interface makes sense, but we went there knowing what to expect and what Global preferences were. For a user simply exploring the interface it may be confusing. I would recommend a short paragraph at the top of Special:GlobalPreferences explaining what global are and how they affect.

Platonides (talk) 23:08, 2 November 2017 (UTC)

Platonides, thanks for the notes!

• Discoverability: It may take a couple iterations to find the right balance. Global preferences is very useful for the people who need it, but it's basically meaningless for the majority of people, who only contribute to one wiki. We want it to be visible, but not too much of a draw for people who will end up being confused by it.
• Combo boxes: Thanks for catching that, I hadn't noticed it.
• Checkbox on the Gadgets tab: I think we need to take out the Gadgets tab completely, because gadgets aren't global.
• Tooltip and paragraph at the top: You're right, there should be some explanation at the top of the page, and maybe tooltips.
• "Make this setting global" text: It should be a column header, we need to split it to two lines and center it.
• Global email options: Thanks for mentioning that, that needs to get fixed.

-- DannyH (WMF) (talk) 18:55, 3 November 2017 (UTC)

The preferences "Send me copies of emails I send to other users" and "Email me also for minor edits of pages and files" seem to not stick when set via global preferences. (when I check the boxes for them, then click save it acts like I never checked the boxes) --Terra ❤ ^(talk) 06:08, 3 November 2017 (UTC)

Also kinda unrelated, but your logo is loading it's image over http instead of https, which is throwing a warning in console, along with firefox saying the page isn't secure due to mixed content loading. --Terra ❤ ^(talk) 06:14, 3 November 2017 (UTC)

TerraCodes, thanks for pointing out the email preferences. We shouldn't even have those preferences on the page, if they're disabled on the regular Preferences page. I'll also pass on the logo issue. -- DannyH (WMF) (talk) 18:57, 3 November 2017 (UTC)

Ok, thanks~ --Terra ❤ ^(talk) 10:39, 5 November 2017 (UTC)

I think it is a good starting point. While I think that preferences in general should be global by default, we can always invert that later on for new users. This is a nice incremental step. I would indeed add a bit more help information somewhere about the functionality. Another thing, that confuses me is that some options are not available, and there is no explanation of why not, it's just missing. This makes it harder to find back options (because the layout is different i depend on order to contextualise now and this order is broken). —TheDJ (talk • contribs) 08:38, 3 November 2017 (UTC)

TheDJ, can you give me examples of the things that are missing? Commtech wiki doesn't get updated very often, so there are a lot of new extensions that don't appear on the dev wiki. Are you comparing the Commtech preferences to your regular preferences, or from prefs to globalprefs? -- DannyH (WMF) (talk) 19:01, 3 November 2017 (UTC)

Hi, DannyH. Until you answer, I tried to create an account, but it's impossible - I get all the time incorrect or missing captcha. IKhitron (talk) 13:08, 3 November 2017 (UTC)

IKhitron, sorry -- I forgot to include the word you need to type to complete the captcha. It's wikimedia-commtech -- I've added this to the instructions at the top of the thread. -- DannyH (WMF) (talk) 18:00, 3 November 2017 (UTC)

Thank you, DannyH (WMF). As I can see after logging in, my previous question is irrelevant, so please ignore it. I like the new interface. Just a couple of things:

1. On global page, if the preference is check box, it looks like two equal checkboxes - open globals on left and preference itself on right. It's vert confusing. Maybe you should redesign the left checkboxes? For example, different background, or thicker square, or something.
2. There are some global defaults that look me wierd. As far as I know, the group mode for recent changes and watchlist is not default, and also see all changes, not just the last one.
3. I really hope the option to exclude some wiki from globals for some particular preference, will come soon.

Thank you for your job, IKhitron (talk) 18:12, 3 November 2017 (UTC)

Hi IKhitron, thanks for your comments.

1. Checkboxes: Unfortunately, that style is set by each browser, and they each use different styles. We can't change that style.
2. Weird defaults: The default that's on Commtech wiki may be different than the default on live wikis. There are a lot of updates that aren't included on this development wiki.
3. Local exceptions: The first version of global preferences that we release won't have local exceptions -- we want to get it out for people to use. We'll add local exceptions in version #2. -- DannyH (WMF) (talk) 21:44, 3 November 2017 (UTC)

Thank you for your answer. 3. It can take a while... 1. But you definitely can design a dom element that will include the checkbox. For example, a span with colored margins on checkbox sides, and this box as its html. IKhitron (talk) 21:50, 3 November 2017 (UTC)

DannyH (WMF), two months ago I posted a Suggested_interface_design. I probably explained it poorly, and I didn't want to be pushy when you disagreed with the idea. I was thinking maybe this design would turn out better than I expected. The current interface has all the problems I anticipated. The current approach was "add a global exception onto to the current interface". That's a straightforward reflection of the developer-viewpoint, however the result of that approach badly clashes with real world usage. Instead of trying to re-explain my interface concept and the benefits, I'll walk through the typical user-experience of this interface.

A new user wants to change a preference for the first time. They're not working cross-wiki yet, so they don't have any need to pay attention to the local-vs-global stuff. They simply set various preferences. Several months later, they visit another wiki and painfully discover all of their preferences have vanished. They need to figure out how to fix it. And here's the answer: They need to go back to their home wiki in order to access their existing preferences. That's gross. And once they get to home-wiki, they have walk through every preference tab converting everything to global. That's not great either. New users should have everything set global by default. Existing users will also want virtually everything set global, although I'm not sure how to make that transition with minimum hassle.

Ok, so let's assume that new users are defaulted to global, and let's assume existing users have converted virtually everything to global. A new user clicks on preferences, and they get a page where every option is greyed out and inaccessible. They're totally confused. Ok, let's consider a knowledgeable existing user wanting to make a simple change. They click preferences and again, virtually every option is greyed out and inaccessible. They have to make an extra click to get to the "live" preference on the global page. That does work, however it's a really bad interface structure.

Maybe you can come up with a better solution than my Suggested_interface_design, but that design does solve the issues above. Aside from changing the expected default, it fundamentally only involves one fix. It replaces the dead-grey preferences with live access to the active preference. (If the option was grey, that implies replacing it with the global control.) The global-panel still has the fundamental purpose of configuring local-vs-global for each item, although the presentation would be revised to more clearly reflect that purpose. On the global-panel the preferences could potentially be greyed-out. Greying-out the preference itself would more clearly focus&communicate the purpose of that panel, but having it non-grey might be more convenient for simultaneously changing global/local and the setting itself. Alsee (talk) 10:54, 4 November 2017 (UTC)

Random subheader with more feedback

Thanks Danny. Helpful insights.

Some thoughts:

• The discoverability is indeed an issue. I have looked through the whole set of tabs, and had to go back to your instructions to find it. Maybe I’m bad at searching (wouldn’t exclude that at all), but it doesn’t feel logical to me. I would expect it to be a tab, or something.
• It would make sense to me to mark more clearly to people that they are editing global preferences. A different background color could help with that.
• I’m sorry to see that the local override of global preferences doesn’t seem to have made it. Hence, I would suggest to rename ‘global preferences’ to ‘override local preferences globally’.
• I like that if global is set for something, there’s a link to it. Good!
• The combination of language setting being local, and gender setting being global can be confusing. You may want to add a ‘if available’ there?
• What I like, is that the system remembers the local settings, even if you set a global one too. Once the global setting is turned off again, it flips back to the old local settings. I'm curious how it handles local accounts that were created in the mean time - will they use the default settings of that wiki, or the defaults that were just turned off. (for example: I set global language to Canadian English. Then I get annoyed with not being able to use nlwiki in Dutch, so I remove that global setting. In the mean time, I visited Arabic Wiktionary, which has Arabic as default setting. Now what is the language setting on my account in Arwiki?)

As a more general point: This interface seems to be built with the aim to keep everything as it is, while allowing the experienced user to add global settings here and there. I think that is a missed opportunity. It is especially the new user that will expect that changes will carry over from a local wiki to all wiki's. This has some drawbacks too, but would make more sense to me as a general direction. Maybe this is something that can be implemented in a later phase.

I would consider it helpful if the local override is possible. Right now, anyone who speaks multiple languages won't be able to use the global setting for languages - which is the most helpful usecase to me. Within the current layout, I would imagine that as a three-options slider: None/global default/global override. Effeietsanders (talk) 22:26, 4 November 2017 (UTC)

OOUI global prefs

So, since we began working on this, the preferences form has been updated to use mw:OOjs UI, and so the global prefs form also has followed it. There's a bit more to be done, but I just thought I'd mention that I've updated https://commtech.wmflabs.org./wiki/Special:Preferences with the work so far. Quite a few things done work as expected yet, but some do and perhaps need more discussion — for example, the "this has a local override" message is now hidden inside a little question mark bubble. Anyway, have a play. :-) —Sam Wilson 07:55, 22 November 2017 (UTC)

Local exceptions 2

The local-exceptions feature (and the current state in general of GlobalPreferences) can be tested now on the commtech testing wiki: https://commtech.wmflabs.org./wiki/Special:Preferences (you need to know that our IRC channel is '#wikimedia-commtech', in order to register an account). Sam Wilson 09:33, 12 January 2018 (UTC)

Thank you, Sam. Looks nice, but does not work well. I have now "use female" in global preferences, "use male" in local preferences, and "set a local exception for the gender" turned off, and the result is male, not female, even after Ctrl-F5. IKhitron (talk) 12:45, 12 January 2018 (UTC)

@IKhitron: That's no good. :-( Can you help me replicate this? It seems to be working correctly for me. If I set the local pref to male, and then the global pref to female, then localprefs shows female. I can then click 'local exception' and can change the pref. I'll keep experimenting. Is there some particular order that you're doing it in? Sam Wilson 05:43, 16 January 2018 (UTC)

Thank you for your answer, Sam. I'm not so sure. And I don't want to make experiments and lose the current state. As far as I remember, I opened the system for the first time, set globals to female, and it worked. Then I set use local, and local male, and it worked. Then I removed use local, but it remained male. IKhitron (talk) 10:21, 16 January 2018 (UTC)

@IKhitron: I have found one bug (T184973), which could be part of what you were seeing. The patch for that bug is now running on the commtech test wiki. Sam Wilson 13:03, 16 January 2018 (UTC)

Thank you, Sam. Looks like it is the problem indeed. As I understand the patch will not fix the current state, just prevent future problems. So, when it will be merged, I'll try this again. IKhitron (talk) 13:06, 16 January 2018 (UTC)

@IKhitron: it's merged now, and the commtech wiki updated with the new code. Test away! :-) Sam Wilson 23:43, 16 January 2018 (UTC)

@Samwilson:, I get 502. IKhitron (talk) 23:49, 16 January 2018 (UTC)

Sam, I gave feedback months ago but didn't get any response. Due to historical happenstance, we started with local preferences and global is being added on as an extra. The interface design naturally flows from that programmer-view, however the design is a poor fit for actual use. It's pretty much backwards. A new user should start with all preferences as global, and existing users will want all (or nearly all) preferences as global. Once you spot that, I think it quickly becomes clear that the interface is wrong.

• Consider a new user. They accumulate some custom preferences. They go to a new wiki for the first time. They are confused that things don't work the way they expect. They figure out it's because none of their preferences exist here. To fix it they either have to carefully examine every preference item trying to remember what they changed, or they need the insight to run back to their home wiki to retrieve their existing preferences and globalize them from there. Then they have to hop back to the alternate wiki to continue whatever they were doing. That's a poor user experience.
• Consider a user who has globalized all (or virtually all) of their preferences, and they want to make a routine value change to one of them. They click the preference link and they get a preference panel where every preference is grey-locked-out. Every item in the panel is doubled-up with a checkbox&link to global prefs. What they really want is for the (global) preference to exist on the immediate pref-panel, but they unhelpfully need to click the link to bypass the useless/locked primary panel first.
• The current design makes things easy if you've already globalized everything and you want to create a local exception. However this is the rarest task, which would only be used by the most sophisticated user wanting to do something unusual.

You could basically swap the local/global panels, however I think it would be better for the main panel to display the active-prefs (possibly a mix of local and global) unlocked and immediately editable. The option to change a pref between local/global could either exist on this panel or the secondary panel could handle that task. Alsee (talk) 10:47, 14 January 2018 (UTC)

@Alsee: I'm afraid we're rather a long way into the design of this to change it for this iteration. I think perhaps the best way forward is to get it deployed with the current global-prefs-as-secondary-page design, which as you say will probably make most sense to experienced users, and then when more people have used it and we've figured out the problems, then we could look at changing things. There seems to have been a fair bit of agreement about the current approach. Perhaps one small improvement we could do that would help with your scenario is to make a more obvious link to the globalprefs page (e.g. people could choose between having Special:Preferences and Special:GlobalPreferences in the top personal-tools menu. Sam Wilson 05:43, 16 January 2018 (UTC)

Sam you misread. I definitely didn't say it "will probably make most sense to experienced users". What I said was that I could understand how the current design arose from the programmer viewpoint, bolting a new global-feature onto the existing local-feature by bolting a global-panel onto the local-panel. However for four months I've said the interface makes little sense for new or experienced users.

If I'm wrong and I'm raising a poor/fringe idea, fine. However if I'm right it seems like a poor plan to confuse people with a poor interface then confuse them again radically reversing that interface. I think it makes sense to take a moment to consider what the right approach is. Alsee (talk) 01:22, 17 January 2018 (UTC)