Ask HN: What's your opinion on notifications in general?
19 comments
I think that's a good idea and user friendly.
In short my opinion on app notifications is that they need to be killed with fire. Then burned again just to be certain.
The only notifications I have enabled are the ones where timely information is important, e.g. gate changes for flights. Anything else gets shut off because it just NEVER is interesting and only succeeds in interrupting me. Call it the worst aspect of the attention economy.
If your app would ever interrupt me for anything that is not absolutely important, it would get uninstalled faster than I can swipe away the notification.
But well, I might not be your target audience (most probably am not actually)
In short my opinion on app notifications is that they need to be killed with fire. Then burned again just to be certain.
The only notifications I have enabled are the ones where timely information is important, e.g. gate changes for flights. Anything else gets shut off because it just NEVER is interesting and only succeeds in interrupting me. Call it the worst aspect of the attention economy.
If your app would ever interrupt me for anything that is not absolutely important, it would get uninstalled faster than I can swipe away the notification.
But well, I might not be your target audience (most probably am not actually)
I am someone like you as well. I hate notifications. The only thing I like to be notified is calendar + clock. And slack at work! I periodically check my email and I rarely need to be notified anything.
My target audience is mostly the average joe internet user. What I found is that the ones who contribute quality content sometimes return back to their post to check for comments and respond. But most of the time it's unattended comments. So I am still experimenting.
It's highly likely that they have been conditioned on all platforms and expecting the same here too. A weekly digest type of email is something I am considering. Not to grab their attention, but to nudge them about the existence of unattended comments.
My target audience is mostly the average joe internet user. What I found is that the ones who contribute quality content sometimes return back to their post to check for comments and respond. But most of the time it's unattended comments. So I am still experimenting.
It's highly likely that they have been conditioned on all platforms and expecting the same here too. A weekly digest type of email is something I am considering. Not to grab their attention, but to nudge them about the existence of unattended comments.
How about when people return to your service, you just show them a little icon somewhere that tells them they have new replies to comments they made. And then when clicking on that, you get to see the relevant comments or threads ? It notifies them without being intrusive in any way.
I mean, I personally attempt to prevent any kind of "push" or "reminder" of happening, because that is to my benefit, but it might not benefit the engagement on your server. In essence, push is bad, pull is good as I see it.
Then again, I'm most certainly not the average technology user, so take my thoughts with a grain of salt.
I mean, I personally attempt to prevent any kind of "push" or "reminder" of happening, because that is to my benefit, but it might not benefit the engagement on your server. In essence, push is bad, pull is good as I see it.
Then again, I'm most certainly not the average technology user, so take my thoughts with a grain of salt.
I prefer systems that default to few/no notifications but let me opt-in to things I specifically choose to be important. E.g. my messengers typically are set to show no notifications, with some important channels giving silent ones and very few people or channels allowed to disturb me.
Configurable notifications (on/off) with opt-in workflow when the user installs the application or joins the site or whatever are probably the good all-round solution. Users who hate notifications don't opt in, and all is good.
Users want notifications that are pertinent to them and useful. Usually that means notifications which are triggered by the activities of other people. Apps that generate internal notifications just to remind the user of their existence("you have not used me for a while" kind of thing) are obnoxious.
Users want notifications that are pertinent to them and useful. Usually that means notifications which are triggered by the activities of other people. Apps that generate internal notifications just to remind the user of their existence("you have not used me for a while" kind of thing) are obnoxious.
I usually disable everything, but I also need to go against the grain in this thread and point out a side effect to that, at least to me personally: constantly manually checking for updates.
In my case it's email or whatsapp groups. For WhatsApp, the upside of disabling notifications greatly outweighs the time I lose checking manually. But for email, sometimes I turn notifications on just so I get rid of that bad habit. (Then turn them off again when it becomes annoying).
In my case it's email or whatsapp groups. For WhatsApp, the upside of disabling notifications greatly outweighs the time I lose checking manually. But for email, sometimes I turn notifications on just so I get rid of that bad habit. (Then turn them off again when it becomes annoying).
I worked for a telecom marketing software service for seven years. My old boss was obsessed with notifications and mobile apps because he was a marketing “guru” and indirectly showed me how broken by design most services are in this respect. One day at work a serious bug was discovered and I suggested we do the responsible thing and notify users affected and my boss said it wasn’t a priority. Where, we as developers, draw the line in the sand seems to be whatever we feel is convenient for us at the moment.
Personally I feel that most users are already drowning in notifications, emails, badges, slack messages, ads, calls, etc that even if you did do an opt-in for notifications that most users would just ignore them since their attention is already too divided.
One thing to consider is not what your software should do but how it will really be used. The software I wrote was designed for sales teams to do marketing and communication but one day I discovered a bug that crippled the service, disabling most calls, while trying to fix an unrelated bug. This bug had been active for months, yet no users had reported it because they weren’t really using the software, in their minds they would rather not work at all and file false reports in the software to make it appear they had done their sales calls to meet their quotas. The bug was fixed but no measures were ever taken to fix the real bug which was the loop hole users were using to commit wage theft. The lesson here is that most users don’t want to use your software, their boss is making them and they hate their jobs. So why not focus on the real problem which is figuring out why your users hate their work and then fix that problem.
Every service is crazy about being “realtime” these days but imagine if git was realtime...cringy...yet more people do “real” collaboration with it than any other technology given the proposition that communication software such as slack isn’t really about collaboration at all. I’ve come to feel that if a software service feels they need notifications in order for it to work then they haven’t truly automated the problem they are solving. It’s like try/catch statements: 80% of the time the catch statements in practice are just //todo comments or log to an error table no one will ever read. So my last piece of advice is to think about notifications like catch clauses, meaning that if you do your job right then notifications shouldn’t be necessary at all.
Personally I feel that most users are already drowning in notifications, emails, badges, slack messages, ads, calls, etc that even if you did do an opt-in for notifications that most users would just ignore them since their attention is already too divided.
One thing to consider is not what your software should do but how it will really be used. The software I wrote was designed for sales teams to do marketing and communication but one day I discovered a bug that crippled the service, disabling most calls, while trying to fix an unrelated bug. This bug had been active for months, yet no users had reported it because they weren’t really using the software, in their minds they would rather not work at all and file false reports in the software to make it appear they had done their sales calls to meet their quotas. The bug was fixed but no measures were ever taken to fix the real bug which was the loop hole users were using to commit wage theft. The lesson here is that most users don’t want to use your software, their boss is making them and they hate their jobs. So why not focus on the real problem which is figuring out why your users hate their work and then fix that problem.
Every service is crazy about being “realtime” these days but imagine if git was realtime...cringy...yet more people do “real” collaboration with it than any other technology given the proposition that communication software such as slack isn’t really about collaboration at all. I’ve come to feel that if a software service feels they need notifications in order for it to work then they haven’t truly automated the problem they are solving. It’s like try/catch statements: 80% of the time the catch statements in practice are just //todo comments or log to an error table no one will ever read. So my last piece of advice is to think about notifications like catch clauses, meaning that if you do your job right then notifications shouldn’t be necessary at all.
> If a software service feels they need notifications in order for it to work then they haven’t truly automated the problem they are solving.
Can't be articulated any better! Thanks. This is the real deal!
Can't be articulated any better! Thanks. This is the real deal!
I've always been a bit bewildered by notifications. I've had so many websites encourage me to sign up -- appealing to my fear that someone, somewhere, might write a blog post and I wouldn't know it right away.
I couldn't find any way to turn off all notifications on my MacBook, but I noticed you can set a "Do Not Disturb" time. I set it for 10:00 pm until 9:59 pm the following day, daily.
All this said, I am very much not the typical user.
I couldn't find any way to turn off all notifications on my MacBook, but I noticed you can set a "Do Not Disturb" time. I set it for 10:00 pm until 9:59 pm the following day, daily.
All this said, I am very much not the typical user.
Do you mean in-app or push? I'd say in-app really depends on the application. As long as they're using it that's great.
But giving up push (or emails and so forth) is much tougher. It's pretty powerful to have the ability to remind people of your app when they stop using it. If you need growth and engagement that's a very powerful tool to have.
But giving up push (or emails and so forth) is much tougher. It's pretty powerful to have the ability to remind people of your app when they stop using it. If you need growth and engagement that's a very powerful tool to have.
Push. That's my plight actually. There are already too many apps trying to find a place in the push notification channels. And given my stance on notifications, I am refraining myself from doing that for now. Planning on surveying my friends and family on this. They might be the right sample space.
When you know a user is likely not coming back you've got virtually nothing to lose by sending them a push or email notification. Active users don't need to get any.
I don't have notification enabled for most apps, we can say all apps.
If I see a notification from an app, I clear it and then turn off notifications from the system settings for that. Android doesn't give an option to do it on device level for all apps.
if you can make do without notifications, I would recommend not integrating notifications.
If I see a notification from an app, I clear it and then turn off notifications from the system settings for that. Android doesn't give an option to do it on device level for all apps.
if you can make do without notifications, I would recommend not integrating notifications.
For less critical apps, I wish they bundled up notifications for a once-per day burst.
I don’t need to know every time somebody likes a post of mine on some networks, but it would be nice if I got some stats at the end of the day.
I mentally tune out most notifications nowadays.
I mentally tune out most notifications nowadays.
The only notification I have on is on a messaging app that I pretty much use only to keep in touch with my mother. Everything else is turned off. That's my opinion on notifications in general.
Do you want something good or do you want engagement? That will tell you if you want to push notifications to your users.
Although asking on HN is a little weird. Everyone here at least tolerates not having notifications.
Although asking on HN is a little weird. Everyone here at least tolerates not having notifications.
My thoughts exactly. I have notifications disabled for everything aside from personal communication from my contacts. I bet a lot of HN users are the same. Don't listen to HN users preferences unless we are your target audience.
Most people seem to be tolerant of notifications. I also suspect most people do not know how to prevent receiving notifications. In public (for example, on the train) I see people receiving many notifications, checking most of them, and manually dismissing the rest.
To build engagement you will want to notify people. However, there is a fine line between a tolerable amount of notifications and an annoying amount of notifications. I would suggest:
1. Make your users feel like the notifications are always a result of their own choice. For example, a notification for something they chose to follow is likely to be tolerated. A notification for something they did not choose to follow will be more likely to be seen as annoying notification spam.
2. Make it really easy for a user to stop notifications in a fine-grained way, or to receive them less frequently. Ideally, they could do this directly after clicking-through the notification (or on the notification itself, if possible). This gives users a way to keep your service from breaching their tolerance threshold, and may therefore prevent them from leaving your service altogether.
Most people seem to be tolerant of notifications. I also suspect most people do not know how to prevent receiving notifications. In public (for example, on the train) I see people receiving many notifications, checking most of them, and manually dismissing the rest.
To build engagement you will want to notify people. However, there is a fine line between a tolerable amount of notifications and an annoying amount of notifications. I would suggest:
1. Make your users feel like the notifications are always a result of their own choice. For example, a notification for something they chose to follow is likely to be tolerated. A notification for something they did not choose to follow will be more likely to be seen as annoying notification spam.
2. Make it really easy for a user to stop notifications in a fine-grained way, or to receive them less frequently. Ideally, they could do this directly after clicking-through the notification (or on the notification itself, if possible). This gives users a way to keep your service from breaching their tolerance threshold, and may therefore prevent them from leaving your service altogether.
This is a really helpful insight. Thank you.
I turn it off for most everything that doesn't include my messenger (Telegram). And even there, it's only set to notify me of private messages. Anything else can wait and has no urgency to it.
I noticed HN doesn't have a notification. I got into the habit of checking for activity by clicking `threads` too. I'm expecting to do the same on my application, but not sure if people will be able to get it.
What do you think about this?