Community Wishlist Survey 2021/Miscellaneous/Unify Preferences and Global Preferences
Appearance
Unify Preferences and Global Preferences
- Problem: Right now we have Special:GlobalPreferences and Special:Preferences for each wiki. While Global Preferences does not include the Gadgets section, rest settings are duplicated in both of them. Global Preferences are very confusing and the system of having Preferences for each wiki with having Global Preferences is confusing.
- Who would benefit: All users.
- Proposed solution: Best solution could be to unify them and label it Global Preferences or Preferences and Gadgets section could be single searchable place per Community Wishlist Survey 2021/Bots and gadgets/Add more gadgets to Preferences/Gadgets or gadget page could change according to where user open new preferences. It will also make Global Preferences less confusing and simplify the overall user preferences system.
- More comments:
- Phabricator tickets: phab:T188424, phab:T174521, [1]
- Proposer: ‐‐1997kB (talk) 10:20, 17 November 2020 (UTC)
Discussion
- Some users want to have some different preferences across all Wikimedia projects. The signature setting is the most important here, I guess, because user signatures typically contain a link to the talk page of the signer and it is good if the link can be translated. For example, I use “PiotrekDDYSKUSJA” on pl.wikt, but would like to use “PiotrekDTALK” here or on en.wikt. (Actually, I have just set it here.) PiotrekDTALK 21:33, 17 November 2020 (UTC)
- There's already a task to add signatures in global preferences, but as you said some people want different signature for different wikis, there can be an option to apply A sign on X, Y, Z wikis and B sign on others. All I'm trying to say is that having one place for all user preferences is much preferred than 700+ different preferences. ‐‐1997kB (talk) 06:40, 20 November 2020 (UTC)
- I don't think they should be unified, instead, we should simply flick the default for new users who never know about, nor would care very much about the fact that you can have local preferences. —TheDJ (talk • contribs) 10:53, 20 November 2020 (UTC)
- While this product was being built, I told the team the design was horribly backwards. The current design theoretically provides the needed functionality, but in reality it is almost unusable. It is particularly unhelpful for new users. If this project is taken up you can ping me and I'm happy to discuss details. In short here is my suggested userstory:
- A new user finds their way to the Preferences for the first time. They look for, find, and change a setting. They expect this change to apply globally (which is what it should do). This is the primary and basic use-case. The user likely returns to this use case many times before encountering the next use case.
- The user becomes more experienced, more sophisticated, their needs become more sophisticated. They realize they want/need a different preference-value for something on this particular wiki. They either click a special option displayed next to the preference, or they enter some more advanced mode, and they create a LOCAL override for this preference. The user can then change the local setting, which only applies on the current wiki.
- When the user returns to the preference panel they see all active preferences. Most preferences display the GLOBAL setting for simple direct editing, but where a LOCAL override exists then the LOCAL value is displayed for simple direct editing. (The local-value-display directly replaces the global-value-display, and the UI uses a colored-background or other styling to highlight that a LOCAL preference is displayed in this slot.)
- I considered writing comparison Story for a user attempting to use the current interface, but it would be long and ugly as the user repeatedly runs into problems.
P.S. I am not thrilled with consuming another Community tech slot to complete a project was abandoned in an almost unusable state. Alsee (talk) 10:05, 21 November 2020 (UTC)
- It could include Global and Local preferences tabs.--BoldLuis (talk) 17:31, 11 December 2020 (UTC)
Voting
- Support Support for convenience. MarioSuperstar77 (talk) 19:36, 8 December 2020 (UTC)
- Support Trang Oul (talk) 19:58, 8 December 2020 (UTC)
- Support --NGC 54 (talk / contribs) 20:18, 8 December 2020 (UTC)
- Support —— Eric Liu(留言.百科用戶頁) 04:39, 9 December 2020 (UTC)
- Support for convenience. {{u|Sdkb}} talk 08:49, 9 December 2020 (UTC)
- Support Thomas Kinz (talk) 10:46, 9 December 2020 (UTC)
- Support MilkyDefer (talk) 13:01, 9 December 2020 (UTC)
- Support Em-mustapha User | talk 16:26, 9 December 2020 (UTC)
- Support Make things simple. Петър Петров (talk) 17:23, 9 December 2020 (UTC)
- Support dwf² (talk) 22:59, 9 December 2020 (UTC)
- Support Ciao • Bestoernesto • ✉ 04:34, 10 December 2020 (UTC)
- Support Libcub (talk) 19:38, 10 December 2020 (UTC)
- Support BoldLuis (talk) 17:31, 11 December 2020 (UTC)
- Support. Meiræ 22:11, 11 December 2020 (UTC)
- Support DGG (talk) 01:31, 12 December 2020 (UTC)
- Support Klaas `Z4␟` V: 15:51, 12 December 2020 (UTC)
- Support Gnom (talk) 15:54, 12 December 2020 (UTC)
- Support Novak Watchmen (talk) 19:40, 13 December 2020 (UTC)
- Oppose When certain problems occur locally, the only way out is to modify certain parameters of the preferences that should not necessarily be changed in other projects (typically tests carried out locally, ex: mw:Reading/Web/Desktop Improvements/Features/Search). The choice to have certain things globally is more than enough and is not confusing for me. —Eihel (talk) 21:22, 13 December 2020 (UTC)
- Support Pinage404 (talk) 22:35, 14 December 2020 (UTC)
- Support —Thanks for the fish! talk•contribs 22:46, 14 December 2020 (UTC)
- Support Thanks, EDG 543 (message me) 15:48, 15 December 2020 (UTC)
- Support Lt2818 (talk) 15:00, 16 December 2020 (UTC)
- Support Joalbertine (talk) 08:10, 18 December 2020 (UTC)