Page MenuHomePhabricator

Minimal exposure of cross-wiki notifications in the Notification Panel
Closed, DeclinedPublic

Description

As an initial step to surface cross-wiki notifications, we can show an indicator of notifications existing in another project, that leads to that project. This won't result int he most fluent experience, but will help with the user navigation and awareness of external notifications, and other tasks will be created for upcoming iterations (more details in T114350).

Acceptance criteria:

  1. If the user does not have unread notifications in other wikis, the usual notification panel is shown without anything different.
  2. If there are unread notifications, a special notification item is shown to make the user aware of it.
    1. The indicator will tell the user about the notifications from one project ("10 notifications from Commons")
    2. If the user clicks on the notification, the user will navigate to the main page of such project with the notification panel open. Which will allow to read those notifications.
    3. If the user discards (or reads) the notification, another one will be shown for the project with the most recent notifications (if any).

Design details

Event Timeline

Pginer-WMF raised the priority of this task from to Needs Triage.
Pginer-WMF updated the task description. (Show Details)
Pginer-WMF added subscribers: Aklapper, Pginer-WMF.
Pginer-WMF updated the task description. (Show Details)Oct 1 2015, 12:41 PM
Pginer-WMF set Security to None.
This comment was removed by Pginer-WMF.

I love it because:

  1. It's simple and minimally intrusive. It doesn't flood your notification panels with a lot of small details. It's more like a gentle reminder that there's something happening over there.
  2. There is already many things we can measure and learn from
  3. It certainly meets out goal for the quarter: "cross-wiki notifications, in one form or another"

@Legoktm: How feasible is this? My understanding is that CrossWatch can only pull this off by doing dozens of API requests and taking a long time to load. Do you think it's feasible and/or worth it to implement this ahead of "real" cross-wiki notifications?

@Mattflaschen pointed out this could also be done by leaving "pointer" notifications on all (or some?) other wikis.

Catrope triaged this task as High priority.Oct 7 2015, 11:58 PM
Catrope moved this task from Untriaged to Team discussion on the Collaboration-Team-Triage board.

It wouldn't be very difficult IMO. We'd need a db table (or we could abuse an object cache)[1] that keeps track of what wikis you have unread notifications on, that we update whenever a new one is created. And we add that to the API response and have it show up in the flyout.

[1] My proposal for cross-wiki API requests (link) has the same requirement.

@Legoktm: How feasible is this? My understanding is that CrossWatch can only pull this off by doing dozens of API requests and taking a long time to load.

I'm not exactly sure how they do it. They're apparently using WebSockets for part.

I don't think spending users' conceptual space (and developer effort) on building something we don't think is the real solution is a good idea. It will spoil the idea of 'cross-wiki notifications' to be a poor imitation of what people want. You only get one first impression.

I don't think spending users' conceptual space (and developer effort) on building something we don't think is the real solution is a good idea. It will spoil the idea of 'cross-wiki notifications' to be a poor imitation of what people want. You only get one first impression.

I don't think that the iterations vs. increments debate has a always a clear winner for all situations (i.e., applying the "best first impression" or " release early and ofter" always at any cost). I can detail a bit the reasons why I thought an iterative approach could work here.

This was proposed as an initial iteration because while still being useful and providing value, it won't require many route changes (in terms of development effort or changing the interaction paradigm). Users get a basic notification that will become expandable in a later stage with access to the individual notifications (keeping the same icon and text that was provided in the first step, but adding more details).

agree there is always a risk to provide an initial step that it is too basic, but the delivery through beta features (T114237) was intended to compensate that.

Pginer-WMF closed this task as Declined.Nov 9 2015, 7:24 PM
Pginer-WMF claimed this task.

As per the different meeting discussions, it seems the first iteration can already achieve what is described in T114350