Don’t steal focus / use notifications to announce new updates

[kornelski]

Using notification popup provided by the OS may be a better way to notify about updates, especially for background apps which currently steal focus.

Last time I investigated that the problem was users can configure notifications as "Banners" or "Alerts", and I didn't see an API to check which one user has selected. This meant that we couldn't rely on using notification's buttons (to have an Install button like the macOS itself), since they're only visible in Alert mode.

[zorgiepoo]

See #806 for relevant discussion.

I'm not that keen on notifications. I believe they can add supplemental/additional value but they shouldn't try to act in a "user must see" kind of way, because they can be customized by the user or turned off. Additionally, notifications are most useful when the app is not active, but as a user I don't want to see or persist a notification for an inactive app that needs updating.

As far as stealing focus goes, one background application I use, karabiner elements, I'm pretty sure only checks for updates on launch (normally when I'm logging into the system). I've been pretty happy with that.

The other way to tackle the problem is to recognize that the UI workflow for certain applications is in need of improvement (see #901, #127, and my fork)

[ksuther]

I did a tiny amount of digging into this to see if there was a way to prefer using NSUserNotification to alert about an update before falling back to the standard update window.

There's no public API to be able to determine if the Sparkle notification stays visible, but there are some private methods that would make this possible (this was as of a few months ago, I haven't checked on 10.12):

-[NSUserNotificationCenter _presentedAlerts] and -[NSUserNotification _persistent] can be used to check if a notification that is presented actually appears and stays visible for the user. So you'd have to do something like the following:

• Present a NSUserNotification
• Wait a few seconds and check if the notification is active and persistent
• If it is, then the user has notifications enabled for the app and the style is set to Alerts (so it won't disappear after a few seconds)
• If not, either defer showing the update (if the app isn't active) or show the standard update window

[zorgiepoo]

It makes sense those methods are private. If one is trying to detect if a notification is being delivered to the users screen (or try to force them to be delivered), then they are using the notification system incorrectly. Because they are supposed to be supplemental and not a primary way of notifying of updates for us.

For foreground apps at least, I can see notifications being annoying. I know users that ignore and don't even dismiss system update notifications.

[ksuther]

Agreed, but I think you'd still need to know if the notification was delivered in order to not show both a notification and the standard update window. Notifications definitely aren't necessarily a win for foreground-only apps, but they could be helpful for apps that are background-only or background-frequently.

The system and App Store update notification borders on a dark pattern to me, as since there's no simple way to dismiss it without trigger some sort of unwanted action. So definitely agreed with you there.

[zorgiepoo]

Agreed, but I think you'd still need to know if the notification was delivered in order to not show both a notification and the standard update window

I thought the notification API handled that, and that there was some default behavior of not delivering notifications if an app was the active app.

[ksuther]

Mac NSUserNotifications are always presented when delivered (assuming they aren't disabled). Maybe you were thinking on iOS?

[zorgiepoo]

A quick google search shows otherwise.

[ksuther]

Aha, you're right. I've had that set to YES for so long that I forgot it even existed.

[jkbullard]

userNotificationCenter:shouldPresentNotification is for 10.8 & higher only, though [1], not 10.7. [1] https://developer.apple.com/reference/foundation/nsusernotificationcenterdelegate/1409032-usernotificationcenter?language=objc

…

On Fri, Dec 23, 2016 at 4:10 PM, Kent Sutherland ***@***.***> wrote: Aha, you're right. I've had that set to YES for so long that I forgot it even existed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#924 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHxKQYtkLYm531M7XR6vPNtHMvltd3dks5rLDjEgaJpZM4K48Bh> .

[glyph]

I'd really appreciate it if Sparkle could start doing this instead of ever popping up a window.

Several Sparkle-related applications have stolen focus from a video game in the last month or so, and in competitive / online games this is extremely irritating. The platform supplies "do not disturb" to tell other things not to disturb me, but sparkle remains stubbornly immune to it. I guess this is what #1064 is also about, but not every focus-sensitive application is necessarily fullscreen (in particular certain games may not register as being fullscreen because for various reasons they use big fake-fullscreen windows instead).

[zorgiepoo]

Someone would need to look up how user notifications API works these days (can we detect if notifications are on screen, register a handler, cancel them, maybe pin them, etc). NSUserNotification has long been deprecated so in some way it’s good we never adopted it. It’s not viable for us to detect if DND is enabled too (already been explored). I agree focus stealing from a non active app is a problem which is specific to backgrounded applications, so we should explore a better default for them.

It’s possible support may require opt in support from the developers (e.g. for like asking user permission for setting up notifications or even the apps having to handle notifications themselves altogether).

On other flip side a reason apps today aren’t more considerate here is because the backgrounded apps haven’t customized their scheduler behavior for this (e.g. notify only on launch or specific ideal times)

For apps that are not backgrounded I don’t think I want system wide notifications — that would seem more intrusive to me than current behavior. I could be wrong though and maybe worth re-considering.

[glyph]

If there were a central way to manage updates, then that would present an easier way to control when and how these updates appear. See #1011 and the duplicate #2090 that I filed when I had the exact same idea five years later for some discussion of the complexities here.

[zorgiepoo]

That’s not a solution to this problem. That’s an unrelated feature request that even if present all users wouldn’ t use. Products for that already exist.

I have a rough plan for addressing this which involves generic gentle reminders for sparkles built in standard UI (something similar @gnachman contributed to 1.x which didn’t get ported over) and not stealing focus except at launch or explicit user initiation, as well as deprecations/warnings for backgrounded apps not providing gentle reminders. And some essential written documentation / samples to verify the proposal can work in practice and make it easier for others to adopt.

For non-background apps, I think we could also do better by default. Perhaps wait for a few minutes (or an hour) to see if we can present the update when the app becomes re-activated, or show an alert if the system has been idle for a few minutes.

I don't think Sparkle should provide User Notification support directly. I played around with the User Notification framework and it's awfully lightweight, not very flexible (can't change alert style or provide authorization reason), easy to dismiss/ignore (including button options and initial authorization), and may not be easily suitable for a framework vendor to "control"

[zorgiepoo]

Implementation for not stealing focus by default and allowing apps to implement custom gentle reminders is now in 2.2 Continued discussion if needed #2158