Page MenuHomePhabricator

Investigation: Global preferences
Closed, ResolvedPublic5 Story Points

Description

Investigate possible approach for T16950: [Epic] Support global preferences on Wikimedia wikis -- wish #4 on this year's Community Wishlist.

  • Would this be a change to the Preferences interface, or an external tool?
  • Should we use the GlobalPreferences extension?
  • Does this need to be a gadget?
  • Does making a change to global prefs result in a push action, or do we need to call every time the user's on a wiki?
  • What happens when an existing user joins a new wiki?
  • Are there preferences that should not be able to be set globally?

Notes from discussion on 2017-07-20:

A global preferences system could be a tool, extension, or built into core.

It could not be a gadget because we do not (yet) have global gadgets, and so a global preferences gadget would have to first be installed in every wiki and this isn't feasible.

Extension

The existing GlobalPreferences extension. A working installation is here: https://commandos.shoutwiki.com/ (random example, or any other shoutwiki). This introduces a new special page that uses the existing preferences page and adds "make this global" checkboxes to each option.

The GlobalPreferences extension works by having a new database table,
exactly the same in structure to the normal user_properties table,
that is created on only one wiki and accessed by all wikis in the family.
It doesn't matter where this table is (i.e. it doesn't even have to be in a mediawiki database, and if it is it doesn't make that wiki special).

When a wiki loads user-options, all global ones for that user are loaded to override the local options.

It uses a user's Central ID to idenfity the user.

Pros:

  • Just one link is added to the standard preferences page.
  • Will be able to handle new settings when they’re introduced.
  • Easily handles new wikis
  • Only shows the prefs that exist on the wiki you’re on
  • Doesn’t require a ‘central’ wiki (Special:GlobalPreferences is on every wiki in the farm)
  • Discoverable from preferences

Cons:

  • Inability to override locally (this could be a future feature, see below).
  • Lots of checkboxes on the global prefs page (one for each option, to say whether it should be used globally; there's no way to determine which should be used otherwise).
  • NW: UI tweaks are welcome. I submitted T68869 which is why the 2nd checkboxes are now indented! But some unresolved questions still in that task.
  • The localprefs form is further complicated by showing when an option is global (and thus not settable in the localprefs form). Only for people who have opted in though, so it won't be surprising to them.

Overriding with local value over global value:

  • A local-set value should override a global-value, which should override a local-default value.
  • One problem with the transition will be that lots of people have local-set values which they'll want to be globalized, but because they're already set locally they won't be.
  • The globalprefs database would have to store this new local-set value, because otherwise it can't be distinguished from the local-default. For example, if a user sets French globally, but wants Russian on Russian Wikipedia, it's not possible to just set the relevant value in user_options because it's the same as the local wiki default.

Tool

The other option is a Toolforge tool - e.g. Kunal's old experiment https://git.legoktm.com/legoktm/globalprefs

Pros:

  • Could override locally
  • Easiest to implement
  • More flexible for UI implementation
  • Discoverable from preferences
  • Doesn’t require a central wiki
  • Could be used to 'unset' a local pref, if the extension did include the override feature (above).

Cons:

  • Won’t include new settings when they’re introduced
  • May not handle new wikis (the user would have to go back to the tool after logging in to a new wiki for the first time)
  • Takes a while to copy to all the wikis after saving. (This could happen in the background though, which would be less annoying if no faster. If it did, it could also copy to new wikis; this would require saving OAuth tokens).

Other ideas:

Having a two-part form, to simplify the UI:

  1. pick notifications you want to change globally (say, language, notifications, and skin) ;
  2. then get only those preferences in the global prefs' form.

This probably doesn't actually simplify things, because there are up to 60 preferences that would have to be navigated in the first part. At least in the duplicate-the-existing-form approach, the layout is familiar (there's just extra checkboxes added everywhere).

Redesign preferences:

RFS: Redesign user preferences

Would a overhaul of preferences (internal structure, and/or UX) help with globalprefs? It might, but probably doesn't need to come first.

Redesigning would help with the lack of a preferences system for anonymous users, who at least could have a reduced set of basic preferences (contrast, text-size, Page Previews, fixed-page-width) like this wireframe.

Summary

Perhaps build a tool as a useful and easier thing, but the extension is the better route. This would (at least to start with) provide non-overridable global preferences only.

Event Timeline

DannyH created this task.Jul 11 2017, 12:59 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 11 2017, 12:59 AM
Samwilson updated the task description. (Show Details)Jul 11 2017, 1:38 AM
kaldari updated the task description. (Show Details)Jul 11 2017, 11:42 PM
kaldari updated the task description. (Show Details)
kaldari set the point value for this task to 5.Jul 11 2017, 11:45 PM
DannyH triaged this task as Normal priority.Jul 11 2017, 11:45 PM
DannyH moved this task from To be estimated/discussed to Estimated on the Community-Tech board.
MaxSem added a subscriber: MaxSem.Jul 15 2017, 6:25 AM

Possible solution: turn preferences on a central wiki into global prefs. login.wikimedia.org sounds as the best candidate because this wiki has no content so users don't need local preferences there. Then we just use it for global prefs.

Problem: the way preferences works is that we record only the deviations from wiki defaults. Thus, there is no clear way to specify stuff like "I want loginwiki's default language as my default one everywhere".

  • Would this be a change to the Preferences interface, or an external tool?

Making an external tool is rather easy to do (e.g. https://git.legoktm.com/legoktm/globalprefs) but I think if it's going to be sustainable and robust it needs to be part of MediaWiki

  • Should we use the GlobalPreferences extension?

Probably? The integration is pretty hacky though, it would probably do better to be part of core itself. I'm not sure what that would look like exactly though. Either way I think some refactoring of the Preferences stuff is necessary.

  • Does this need to be a gadget?

?? It should definitely not be a gadget.

  • Does making a change to global prefs result in a push action, or do we need to call every time the user's on a wiki?

I don't really understand this question.

  • What happens when an existing user joins a new wiki?

I think what you're really asking is what the order of precedence would be? Currently it's: 1) global preferences 2) local modifications, 3) local defaults

  • Are there preferences that should not be able to be set globally?

Gadgets are probably the main outlier, because equality is not guaranteed across wikis. Extensions that are only enabled on a subset of wikis should be fine since an extra non-registered preference shouldn't do anything on other wikis.

Possible solution: turn preferences on a central wiki into global prefs. login.wikimedia.org sounds as the best candidate because this wiki has no content so users don't need local preferences there. Then we just use it for global prefs.

Uh, please don't. loginwiki is designed to never be visited by users. It should be entirely invisible. The central wiki is meta - most other global things (global user pages, css/js) are already there.

Problem: the way preferences works is that we record only the deviations from wiki defaults. Thus, there is no clear way to specify stuff like "I want loginwiki's default language as my default one everywhere".

Have you tried using the GlobalPreferences extension? :)

Have you tried using the GlobalPreferences extension? :)

All those checkboxes!

@Legoktm What do you think of having a dedicated special page for handling global prefs as part of GlobalPreferences extension instead of the checkboxes we have right now?

@Legoktm What do you think of having a dedicated special page for handling global prefs as part of GlobalPreferences extension instead of the checkboxes we have right now?

That's already how it works? You have to go to Special:GlobalPreferences to set global preferences.

Ah. I was under the impression it changed existing Special:Preferences. Thanks for clarifying!

Just my unsolicited two cents:

I would imagine that the average user is unaware that preferences are not already global. And I would say that the average user would have little need to set per-wiki preferences (although I acknowledge the need to do so in some use cases and support keeping the functionality to do so.)

Expecting new users to go to a different special page (or even a different wiki) to set global preferences seems a step too complicated. I propose a solution that allows users to have their preferences on their primary wiki serve as their global preferences. For example — if I only edit on English Wikipedia, then my preferences on English Wikipedia would be copied globally. However, I can go to French Wikipedia and change my preferences just for French Wikipedia.

If we go this route, I think we should consider making global preferences on by default for new users (and probably even existing users).

TheDJ added a subscriber: TheDJ.Jul 18 2017, 10:04 PM

Expecting new users to go to a different special page (or even a different wiki) to set global preferences seems a step too complicated. I

I would counter with: Solving all problems at once tends to be a good way to set yourself up for failure. By keeping global settings and local settings separate, you can get a solid technical foundation going, before you have to tackle incredibly difficult UX problems.

Also

  • Continuously adding to the concept of "global" (meta, commons, login, homewiki) is likely to be highly confusing for all editors
  • When you say "new users", also consider that most casual users likely never think about preferences to begin with, and that those that do reach that stage, are unlikely to leave their homewiki until they are much more experienced.
  • We also need to consider API access for global preferences, and how that will/should influence the various tools that make use of the existing preferences API.

I would imagine that the average user is unaware that preferences are not already global.

I don't think that is true but depends on what you mean by "average user". Most people with accounts on multiple wikis are very likely aware of this. It's also kinda hard to define counts as "primary wiki". For example I setup my account initially on enwiki but now my most-edited wiki is MediaWiki.org followed by meta. And there are a lot of such cases.

Also, I agree with @TheDJ. Touching the existing, working stuff which people user everyday is tantamount to setting ourselves up for failure. We don't want to overwrite people's existing (probably complicated) preferences without their explicit consent for that. Having a different special page (linked from the standard Special:Preferences) is a good starting point. We can at some point think about merging the two when enough people are happy with it. Keep in mind that this is a feature that will probably be used by our power-users who juggle multiple wikis and have different preferences on those wikis. Navigating to a new special page is trivial for them.

And your two cents are very welcome, @TBolliger!

Samwilson moved this task from Ready to In Development on the Community-Tech-Sprint board.

The integration is pretty hacky though, it would probably do better to be part of core itself. I'm not sure what that would look like exactly though. Either way I think some refactoring of the Preferences stuff is necessary.

What is hacky about it? It seems to me that loading global prefs for a given user when loading their local prefs is about as efficient as it can get. Or do you mean the editing interface?

And is it an option to build it into core? Am I right in thinking that at the moment the only "multi-wiki" concept in core (beyond shared database tables) is that of Central ID? (And that's not really a multi-wiki thing, come to think of it.) I would have thought that global preferences would be a bit unusual in core (but I don't really know that much about it).

The integration is pretty hacky though, it would probably do better to be part of core itself. I'm not sure what that would look like exactly though. Either way I think some refactoring of the Preferences stuff is necessary.

What is hacky about it? It seems to me that loading global prefs for a given user when loading their local prefs is about as efficient as it can get. Or do you mean the editing interface?

Hacky stuff:

  • Creating non-declared member variables on the User class, meaning it doesn't take advantage of the user caching
  • Anything that checks GlobalPreferences::onGlobalPrefsPage() or GlobalPreferences::onLocalPrefsPage()
  • Registering a hook in an extension function to be late
  • The mess that is onPreferencesFormPreSave (doesn't handle stuff like checkbox matrices properly)

And is it an option to build it into core? Am I right in thinking that at the moment the only "multi-wiki" concept in core (beyond shared database tables) is that of Central ID? (And that's not really a multi-wiki thing, come to think of it.) I would have thought that global preferences would be a bit unusual in core (but I don't really know that much about it).

I think it's definitely an option. Usually multi-wiki things are implemented in core, but in an abstract way so that extensions can expose the multi-wiki functionality. An example is GlobalCssJs. Most of the multi-wiki code is actually handled in core ResourceLoader itself, but its exposed by an extension.

At the very least I think the Preferences UI needs to be easier to extend. Maybe it can already be done with more HTMLForm magic that I just didn't think of at the time.

I think there are a few different ways we can abstract this, the one I've been thinking most about lately is to support arbitrary layers of preferences in core, with the concept of higher layers overriding lower ones.

daniel added a subscriber: daniel.Jul 20 2017, 1:24 PM

At the very least I think the Preferences UI needs to be easier to extend... I think there are a few different ways we can abstract this, the one I've been thinking most about lately is to support arbitrary layers of preferences in core, with the concept of higher layers overriding lower ones.

Fully agree that the prefs code needs an overhaul, but it's outside the scope of Community Tech. Community Tech is a small team that works on lots of small projects that can be completed quickly. If we try to overhaul the prefs code, it's unlikely it will be completed before our next wishlist survey starts.

kaldari closed this task as Resolved.Jul 20 2017, 8:00 PM

See description for results.

Are there any follow-up tickets from this investigation yet?

DannyH moved this task from Estimated to Archive on the Community-Tech board.Aug 2 2017, 12:34 AM