Some possibilities explored for the badge behaviour (T130363):
- Ignore cross-wiki notifications. While this avoids distractions, it goes against the goal of providing visibility to the global wiki activities.
- Count notifications globally but don't highlight on new cross-wiki notifications. While keeping an overview of the total pending work, it will only draw use attention for what's new in the current context.
- Don't count cross-wiki notifications but highlight as they arrive. This can communicate that new activity happened but keep a clear count of the pending tasks for the current wiki only.
- Distinguish cross-wiki events. Surfacing in the badge the kind of events it contains (e.g., by different colors, icons, etc.) helps to anticipate what to expect in the panel, however that requires a cognitive effort to process the information and make a decision.
- Allow filtering specific kinds of notifications. If distracting notifications are of a given type or from a specific origin, we can rely on mechanisms of volume control (T115264) or settings (T114917) for the user to filter them. This provides a greater degree of control but also require a bigger effort from the user. Before providing such tools, we may want to explore which are the most useful defaults.
In the current context it may make sense to focus on solutions which are simple (don't introduce new elements to be learnt), and reduce the distraction but still surface external notifications. Some rationale:
- Currently our data about the volume of notifications from different wikis and notifications per user seems to be relatively low. So we should not assume a big torrent of interruptions by tenths of wikis.
- Users come from a completely isolated model where there was no visibility on what was going on in other wikis (except for actively looking for it or through email notifications). We may need to evaluate how often this connection across wikis is navigated or the one-wiki-at-a-time model persists.