Page MenuHomePhabricator

Include echo notification count as a favicon badge
Closed, DeclinedPublic

Event Timeline

Jaredzimmerman-WMF raised the priority of this task from to Needs Triage.
Jaredzimmerman-WMF updated the task description. (Show Details)
Jaredzimmerman-WMF changed Security from none to None.
Krenair added a subscriber: Krenair.Nov 9 2014, 4:48 PM

Wow, no, please don't. Unlike, say, email services, providing notifications isn't the primary purpose of Wikipedia.

Wow, no, please don't. Unlike, say, email services, providing notifications isn't the primary purpose of Wikipedia.

This is a common practice on many sites with notifications, not simply email applications/sites. Since many community members seem so concerned with other users missing or overlooking messages this seems like a pretty clear win for those use cases, what is your concern with implementing it?

My concern is feature bloat.

(And users ignoring messages sent to them is a human problem, not a technical one. You can't be seriously suggesting that anyone can accidentally miss an orange bar taunting them in the corner of every page until they click it.)

Legoktm renamed this task from Polish : Include echo notification count as a favicon badge to Include echo notification count as a favicon badge.Nov 25 2014, 10:26 PM

I don't see the orange bar as a permanent element. Do I think ignoring/overlooking messages is a technical/Design problem? It certainly can be.

take a look at this interface, how many seconds does it take you to see how many messages you have? given this product (a bank account) does not have the main purpose of sending and receiving messages, the messages are still quite important, and in some cases time sensitive.

I don't think this request leads to feature bloat, and it has the plus of not cluttering the UI as well. Once we have a way to trigger notifications without page loads it will have the benefit of allowing someone to know a notification is present without even having the tab in focus.

It took me less time than the image took to load, so I guess a second or two. The red "Log off" button was the first thing I looked at, I completely ignored the massive "What can we do better?" image (banner blindness, heh) and started scanning the page for numbers, which I quickly found, since at the very least the number is bold and has an envelope icon.

That is, however, not how our design looks. Ours looks like this:

The red icon and the orange bar are the single colorful point in the entire UI, and immediately draw the eye (this is honestly rather skillful use of color, the Vector skin is subdued and the notifications are accented). This is visible even on the main page (which is rather flashy, compared to regular pages) and even in the miniature visible here (the bright blob shines through).

I use favicon to identify the sites when I have fifty tabs open. I don't need stuff covering them. When I look at Wikipedia, the indicator is obvious (to the point of being distracting sometimes when I really don't care what people want from me and just want to read the article); when I don't, I don't need to care about it. Please don't force-feed me more data every second, I am already sick from overeating.

(And users ignoring messages sent to them is a human problem, not a technical one. You can't be seriously suggesting that anyone can accidentally miss an orange bar taunting them in the corner of every page until they click it.)

That's simplifying the issue, since the orange bar does not show for mentions, which are used as messages in some cases.

Quiddity added a subscriber: Quiddity.EditedNov 26 2014, 2:44 AM

Could this be implemented as a userscript/gadget, instead? Then people can opt-in, if they want it.

I find the numbers in the titles of Trello, Gmail, and Phabricator to be annoying. They blink/change, and distract my attention, 99% of the time for something that isn't urgent.
If I have a lot of tabs open - which I and many highly active editors usually do - then all those tabs will be blinking/updating.

See also T75209: The document title should be dynamically updated to include a (n) notifications count in the browser title bar.
See also (?) T34283: API method to poll centralized notifications

@Quiddity I've never noticed any blinking, are you just referring to when a new notification arrives? Or something else. Perhaps a video would be helpful. 

I'd prefer not to proliferate gadgets but that might be a good way to do some quick testing. 

sent while mobile

Ah, "blinking" was the wrong word, as that implies on&off. I'm just referring to when a new notification arrives. Especially the first one (going from nothing to (1) in a red bubble).

Also I updated my comment above, to note how the issue is magnified when there are multiple wiki tabs open at the same time.

I'd prefer not to proliferate gadgets but that might be a good way to do some quick testing. 

This is exactly what Gadgets (and preferences) are for! Customizations that not everyone wants or needs, but are helpful to some people; customizations that will significantly detract from the experience of many, whilst benefiting others.

I'm not sure that "significantly detract from the experience" is a reasonable characterization of an established pattern like this. Although I understand that you find it distracting. Perhaps some subtle animation rather than it flashing in would would make it less distracting for you.

I'm not sure this is an established pattern.

Isarra added a subscriber: Isarra.Nov 26 2014, 7:14 PM

As Matmarex indicates, the purpose of the favicon is to visually identify the site, and while such notifications for email might be useful because it can tell you that you got a new email when you're on another tab (I assume there are folks out there who don't get so much noise email as to make it utterly meaningless), wikis aren't like email. You tend to care most about what's happening on the wiki when you're on the wiki itself, on one of those tabs, and there what we have on the page stands out quite effectively already, far more so than a favicon number would if implemented properly. When you're not on it, you're doing something else, and don't need the distraction.

Now I could buy that a subset of users might find this useful regardless (especially perhaps new users), but that is what a gadget would be for, as quiddity suggests. New users, too, would probably need to turn it off after awhile when it becomes less useful over time.

If you think that this would be useful to new users than a gadget is not a
very reasonable way to implement, as new users are unlikely to discover it,
by that logic it should be on for everyone and use a gadget to disable for
users who find it distracting.

*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

M +1 415 609 4043 \\ @Jaredzimmerman http://loo.ms/g0

Has that not been fixed? Seems like there would be a lot of use cases
for off-by-default; on-for-new-accounts gadgets, potentially.

Either way it'd need A/B testing to see if it even does affect new user
retention here, however.

Sadly we don't have a standard A/B test framework so until then I don't
know that having it as a blocker makes sense.

*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation

M +1 415 609 4043 \\ @Jaredzimmerman http://loo.ms/g0

If there's no way to test it, then adding something that only *might*
help is probably not a good idea.

I concur with the Isarra feedback on the issue.

There are qualitative ways to test many things which are much more difficult to quantitatively test. 

sent while mobile

Quiddity updated the task description. (Show Details)Dec 4 2014, 11:30 PM
matthiasmullie triaged this task as Low priority.Dec 10 2014, 2:44 PM
Technical13 added a subscriber: Technical13.
Legoktm closed this task as Declined.Jul 6 2015, 7:58 AM
Legoktm claimed this task.
Legoktm added a subscriber: Legoktm.

Per above comments by Quiddity, Matma Rex, and Isarra.

Restricted Application added a project: Design. · View Herald TranscriptApr 3 2017, 3:28 AM