Page MenuHomePhabricator

CheckMatrix is not future proof
Open, Needs TriagePublic

Description

  • User globalizes their notification preferences
  • At a later point, software adds another notification type
  • Settings for this type are not global
  • The user notices something wrong and goes to their global preferences
  • UI says that this preference is global

We need some reasonable way to handle this. Maybe, don't store whether each individual checkbox in CheckMatrix is global but rely on the global checkbox?

Event Timeline

MaxSem created this task.Jun 21 2018, 9:46 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 21 2018, 9:46 PM
Niharika added a subscriber: Niharika.

I'm considering this to not be a blocker for Global Preferences rollout on Wikipedias.

Vvjjkkii renamed this task from CheckMatrix is not future proof to vhaaaaaaaa.Jul 1 2018, 1:02 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from vhaaaaaaaa to CheckMatrix is not future proof.Jul 2 2018, 11:07 AM
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptJul 3 2018, 11:46 PM

Notes from the meeting on 16 July.


Potential ways to handle this:
  1. Allow every option (web and email for instance) to be separately globalizable (I coined that term).
    • Pros: Easier to handle this issue.
    • Cons: UI complexities and ugliness.
  2. Show a red error indicator/background for options that are not globalized.
    • Pros: Error is communicated to user and the UI isn't "lying" to the user anymore.
    • Cons: Potential for confusion about what the error means and how the user can fix it.
  3. Auto-save local preference as global on Special:GlobalPreferences page load
    • Pros: The UI is accurate in terms of what the backend is storing.
    • Cons: Auto-saving a user's global preferences is not necessarily a good idea. It has potential for being disruptive.
  4. Update global preferences whenever the user Updates their global preferences on a wiki that has those extraneous preference(s). This is the current behavior.
    • Pros: The user can mindfully select their globals and the software doesn't store anything for a preference until a user has picked it themselves.
    • Cons: Causes the problem of the UI lying to the user for a while.

We decided to go with #4 after the meeting because it is minimally disruptive among them all. This is also an edge-case which will not effect too many people.

Follow up questions I have:

  • When a user goes to Special:GP on a wiki that has a new CheckMatrix row which was not present on another wiki where they initially made their preferences global, what are the checkbox values for the new row?
  • Max wrote "Maybe, don't store whether each individual checkbox in CheckMatrix is global but rely on the global checkbox?" in the task description. I don't think we discussed this as a potential option yesterday. @MaxSem Do you want to elaborate on what you meant by this? IIUC, this still leaves the UI issue.
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 17 2018, 7:26 PM
SBisson moved this task from Inbox to External on the Growth-Team board.Jul 17 2018, 8:19 PM