Best or expected behaviour for a notification when app is in front

Hi,

When my app has finished searching for files, it notifies the user how many items have been found. At this point, the app may be frontmost or not.

Currently, I handle the not-frontmost way by showing a native OS notification, using the NSUserNotificationCenterMBS class. So far, so good.

If the app is active, the notification won’t show at all. I’ve not found a way to force it to show, and it’s perhaps a missing feature of the NSUserNotification framework. So, for the moment, I check whether the app is frontmost and, if yes, show a regular message box and, if no, show a notification.

But I’m concerned as to whether this is the right or expected approach. Does it sound reasonable?

The contents of this post are an opinion.

It’s for the users. An app showing notifications when its the frontmost, actively being used app would be obnoxious.

It’s the wrong approach because you’re counteracting and circumventing the behavior everyone knows and expects. It does not sound reasonable to me.

2 Likes

Thanks for your answer.

How would you tell the user how many files have been handled, then? I’m finding that showing the count in a label in the main window is ugly, especially since the result is not to be displayed (only the count of handled items).

I’m noticing you didn’t answered to the possibility of showing a message box when the app is frontmost. Would also be wrong?

Using a MessageBox because Notification Center is suppressing frontmost app notifications is what I meant by “counteracting and circumventing the behavior everyone knows and expects.”

This is going to end up being specific to your design. A label with the progress sounds quite reasonable to me, but I have no idea what your app looks like. If you’d like to DM me screenshots and the way your app is used I might be able to make a suggestion (you can also make a public post if you’re comfortable with that).

If your app can do other things while it’s looking for files, this could make the UI a challenge. You’ll need to balance the visibility of the progress label with just how important it is overall. Another thing that might affect how this information gets displayed or conveyed is if waiting for the search to complete is required for certain features.

1 Like

Nice and quick for debugging, but the force the user to dismiss it. I havea scrolling area for log messages so I would put it there.

1 Like

No problem in following the discussion on this thread.
Here’s how the main window looks like (when idle):


And working:

When it finishes working, the window just comes back to the enabled state. That’s where I’d like to tell the user about the result.

I can’t show the progress, as the app searches in folders selected by the user and I don’t know the content beforehand. I can only show when it’s finished.

The window stays disabled as long as the search runs. The user may open a new window to make another search, but that’s not interfering with the first one.
The steps are always “search for all items” and then “apply actions to them”.

Granted. I’m yet to find the best way.

An extra window floating? Possibly. But when the app is in the background, the window would have to be global floating, which defeats the purpose of using the notification.

Thanks for your answers.

To be fair, I use several apps that use notifications like this. BBEdit uses is when you do a long multi-file find & replace. Transmit shows notifications when large files are uploaded.

2 Likes

Do these notifications come through when they’re frontmost? The flags we’d need to use to override the suppress-frontmost behavior would probably help OP more than my thoughts on the UI design.

Do you have a window (or does the window switch to a view) that shows affected files at all? Personally, I would want to know affected files before I apply actions. Less optimally, an after-action “here are the affected files” window. I think this window/view might help clarify the start or completion of the task.

I might make the “Search In” button less wide, to fit the words “Search In” only. If the label doesn’t change to anything longer you don’t need to eat that space. Same goes for Start / Execute, it only needs to be the text plus a little padding.

With this additional space from shrinking the buttons, you could put a ProgressWheel to the left of the “Search In” button, and a right-aligned label next to that for a label like “Working…” or “Searching…”

I think some kind of final result window or dialog would help. If you don’t want to create a results / affected files window, I think your proposed MessageDialog solution could suffice as a compromise.

I use NSUserNotificationCenterMBS quite a bit, it’s an excellent way to inform users of non-critical information without them having to interact with the UI and dismiss a dialog. It works when my app is in the front. Perhaps there is some setting in System Preferences → Notifications that affects this behavior? I see nothing obvious, but I’ll mention that on my Mac all the options are enabled, and I have selected Banners as the display mechanism.

Only if the user wants it (it’s a possible action, but not enforced by default).

Makes sense. When I get time to rewrite the app, I’ll consider this.

This is optionally available by adding an extra action (show in list), which is the default action; but it’s not mandatory, to not clutter the screen if unwanted.

Good remarks, thanks. Actually, the app is 99% used in French, so the space is less wasted usually, but I agree when I see the English screenshots.

Have you noticed the progress wheel at the top-right corner, by the way?
Your thought leads me to think the existing wheel is too subtle…

Except when the app is in the background. In a previous version of this app, the MessageBox was always shown at the end of the search. So when the action was “Launch” (then my app went in the background), the icon would bounce in the Dock, just to show a result. That was annoying and the reason why I switched to the native notification (which, as already stated, makes nothing when the app is in the background).

Thanks for your welcomed suggestions.

Weird.
In the NSUserNotificationCenterMBS documentation, I found this:

The NSUserNotificationCenterDelegateMBS class provides more information about the delivered user notification and allows forcing the display of a user notification even if the application is frontmost.

So it looks like it shouldn’t be the default. And I can’t reproduce your experience for the moment.

Thanks for telling.

I like the little status bar at the bottom that Notepad++ for example uses:
image

2 Likes

Hah, no I didn’t notice that! It might be too far out of the way, or it might be that when I design these things I put the ProgressWheel near the buttons and that might be the only place that I had looked. I don’t have anything to suggest which location is better, but adding a label and moving it closer to the buttons seems like a way to increase visibility to me.

In my mind the logic is that the users mouse is over the button to perform the action, so placing the progress indicator near the button makes it easy to notice (the user is already looking there).

I did not understand this was the issue. I was under the impression the notification was showing while in background, but not foreground. If you’re not getting notifications at all there may be something else wrong. I believe you have to add something to Info.plist regarding display style to make use of them, but it’s been so long I don’t have specifics for you.

I’ll make that change, thanks.

Perhaps by the fact that I’m a “keyboard” guy, I don’t even look at the button when I hit “enter” :wink:. Of course, the standards aren’t about how I do things. And a new label shown while the search runs will be obvious to see.

You understood well. In the message you’re quoting, I’ve mistakenly inverted the words, sorry (it’s starting to be late here). I should’ve written:

(which, as already stated, makes nothing when the app is in the foreground).

Another possibility to consider, thanks.
(in my opinion, a statusbar is rare in Mac apps, though).

Actually, I see NSUserNotificationCenterDelegateMBS is deprecated, and Christian recommends you use UNUserNotificationCenterMBS. My code actually uses this when the Mac is running 10.14 or later. Maybe changing to the newer API will help?

Just so that you know why you’re seeing the behavior you are: Setting your notification types to “Banner” is why they all always show and don’t go away. That is not the default behavior.

@Tim_Parnell
I don’t know if you’re addressing me, but my notifications are set to Banner and they do go away. According to the explanation in System Preferences: “Banners appear in the upper-right corner and go away automatically. Alters stay on screen until dismissed.”

Oop! I had the terms inverted.

By default, if your app is in the front the notifications should not show.

I’ve been testing behaviors here, and I’ve found that I can’t get any of my notifications to show up as they happen. Something might be borked in my configuration (which I thought I left the default), so I’m going to have to bow out of figuring out what the default notification behavior is.

IIRC, I tried (because I saw the deprecation) but couldn’t make it working, so I kept the deprecated version. Not sure I’ll waste more time in trying once more.
But thanks for the tip.

Perhaps related to Mac OS’ security? Is your test app signed? (not sure it’s mandatory :man_shrugging:)