632619 - notifications lib needs more useful fallback

Status: RESOLVED WORKSFORME

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Fred Wenzel [:wenzel]]

Somewhat recently, the notifications lib will not throw an exception anymore when Growl is unavailable. Unfortunately, this makes it impossible to detect when, well, Growl is unavailable. Instead, Mac users without Growl silently receive a pretty bad UX unless they know how to open the error console and look for messages.

Two possible fixes come to mind:
a) make it detectable if there was an alert service available, by exporting a boolean. Then the devs can decide what they want to do in case there's no Growl.
b) Use a Firefox notification box ("gray bar") like I do here:
https://github.com/fwenzel/copy-shorturl/blob/a6ed22d

I would personally prefer b) since it gives users a decent experience whether or not their OS has a notification service available, but I could live with a).

As it stands I unfortunately had to stop using notify() which makes me sad.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

(automatic reprioritization of 1.0 bugs)

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Option B sounds like the better one, since it makes the APi work even if the user doesn't have the optional third-party notification service on which the API currently relies.

Comment 3

[Fred Wenzel [:wenzel]]

Agreed. If you remove the bar automatically after a few secs, it works essentially like growl.

Here's a new link to the code, since the URL in comment 0 rotted away:
https://github.com/fwenzel/copy-shorturl/blob/a6ed22d/lib/simple-notify.js

Comment 4

[Jeff Griffiths]

I like this workaround, particularly because it doesn't involve inventing anything or a hassle for a developer. 

I would like to capture a use case it doesn't work for, where the Firefox window is not visible at all but the extension code has issued a notification. If growl et al is installed, the user sees a notification but if we fall back to Firefox's notification box, the user doesn't see anything.

A good example of an app that uses notifications like this is the Tweetdeck app for Chrome, which uses Chrome's notifications to notify the user of new tweets regardless of whether the chrome window is visible or not.

Comment 5

[Drew Willcoxon :adw]

Jeff's right, the best notifications service, or at least its ultimate failsafe, would Just Work Well, regardless of what platform the user is on.  The current failsafe of console.log() Just Works, but not Well.  And although it works better than console.log(), the notification box approach sometimes doesn't work at all.  Ideally a nice failsafe (or primary implementation) would be built in to the Mozilla platform, where I can't imagine that this problem hasn't come up before.

But I'm of two minds:  I don't think it's reasonable to make the guarantee that every user will potentially see notifications.  Even if notifications worked perfectly, the user ought to be able to say, "I don't want to be bothered with notification bubbles ever, or for this or that app, or for this or that add-on."  As a matter of design, you should therefore not rely on notifications for primary UI.  If for some reason you do, you should explain to your users what the requirements are.  Most of your users will meet them anyway.  The ones who don't aren't seeing any other Firefox notifications either.

I'm working on a patch that fails to the notification box, and then ultimately fails to console.log().  Another possible approach is to open a panel in the corner of the screen, which I presume is possible even if no chrome window is open.

Comment 6

[Drew Willcoxon :adw]

Oh, another approach would be to pop up a doorhanger from the add-on icon at the left side of the location bar, like how a doorhanger pops up when you've successfully installed an add-on.  That would be in opposition to the notifications box approach.

Comment 7

[Jeff Griffiths]

Drew: agree that users should be able to control this, and addons devs will have to write code with the expectation that the user will just shut off or in some other way configure notifications such that the behaviour is not default.

My main concern is cases where notifications work differently based on a number of variables ( whether Growl is installed or not, etc ). If we provide a fallback when Growl doesn't exist, that fallback needs to work well for all the use cases that Growl covers. 

If you want consistency over potential features, then it might be best for notifications to work in exactly the same way, for example use Firefox's notification box or door hanger UI *by default* and consider some pref to turn on native OS notifications if the user wants that.

Comment 8

[Drew Willcoxon :adw]

I think the paramount concern is a good UX by default.  I'd rather try the best UX first and fall back to other best-effort options rather than a consistent worse UX, or a UX inconsistent with other apps on the user's system, although I recognize that puts a burden on developers who have to explain the fallbacks to their users.  The best UX is nsIAlertService, which uses the well known desktop notifications services for each platform.  I expect that most users will be covered by these, and that we're only talking about a small minority who'll see the fallbacks, but that's just a hunch.

The aforementioned burden of explaining fallbacks to users could be replaced by the smaller burden of saying, "Install the service that everybody else on your platform uses, what's the matter with you!"  i.e., if it were nsIAlertsService or nothing, which is starting to sound good to me.

Comment 9

[Drew Willcoxon :adw]

The more I think about this the more I think there are only two satisfactory solutions: 1) Add support to the Mozilla platform for infallible notifications that are at least as slick as the native notifications for each platform, or 2) rely on nsIAlertsService and fall back to nothing, which is pretty much the current behavior.

A third way would be to deliberately broaden the scope of the notifications API from desktop notifications to notifications that can appear in different places and in multiple forms, or shift the scope to notifications that arise only from browser chrome.

So I think this bug should either be wontfixed or morphed to more specifically describe the desired UX.

Comment 10

[Fred Wenzel [:wenzel]]

In general, I agree, though I think this shouldn't just be wontfixed. At the moment, the notifications API in the SDK is broken because I can fire notifications and have no way of telling if this actually worked. If Growl is not present, nothing at all happens, making the notifications API very, very poor right now.

If you don't want to fall back to anything, at the very least raise an exception when there's no notifications interface available on the user's box. This way the developer can choose to do something else instead (as I do in the code in comment 3), or silence it and not care that no notification will be shown.

The current behavior of quietly ignoring the lack of a notification engine is the worst possible option, both for the devs and the users.

Comment 11

[Drew Willcoxon :adw]

True, I'm fine with flagging the failure, either by raising an exception or returning false or by some other means.  I'd like to hear what Myk thinks.

However, you're wrong that the lack of such a flag means the API is broken or poor.  As I said in comment 5, even if notifications worked perfectly there's no guarantee that all your users will see them, and you therefore should not rely on notifications for primary or otherwise critical UI.  And pestering the user with some ad hoc notification if require("notifications").notify() fails is just bad form, if that's what you're considering.

Comment 12

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #10)
> If you don't want to fall back to anything, at the very least raise an
> exception when there's no notifications interface available on the user's
> box. This way the developer can choose to do something else instead (as I do
> in the code in comment 3), or silence it and not care that no notification
> will be shown.

The SDK's high-level APIs are designed on the principle that the API should being doing as much hard work on developers' behalves as possible, pushing the burden of detecting and dealing with such failures down the stack.

Making the API implement an alternative notification mechanism when Growl is not available would be more in keeping with that principle than reporting the failure so each developer can implement their own notifications.


(In reply to comment #9)
> The more I think about this the more I think there are only two satisfactory
> solutions: 1) Add support to the Mozilla platform for infallible
> notifications that are at least as slick as the native notifications for
> each platform, or 2) rely on nsIAlertsService and fall back to nothing,
> which is pretty much the current behavior.

I wouldn't hold a fix for this bug to quite so high a standard.  Worse is better, the perfect is the enemy of the good, etc.  The most common failure case by far is the one that originally prompted this bug, and addressing it with a notification bar or doorhanger would be a significant improvement, even if that solution doesn't address every case.


(In reply to comment #11)
> However, you're wrong that the lack of such a flag means the API is broken
> or poor.  As I said in comment 5, even if notifications worked perfectly
> there's no guarantee that all your users will see them, and you therefore
> should not rely on notifications for primary or otherwise critical UI.

Indeed.  The docs <https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/packages/addon-kit/docs/notifications.html> call these "transient" notifications, which suggests this but doesn't come right out and say it.  Regardless of how we fix this bug, we should make the docs more explicit about how these notifications work, their limitations, and what you should and shouldn't use them for.

(Also orthogonal to this bug, we should think about implementing a mechanism for issuing permanent notifications that stick around until cleared via a UX like the notifications toolbar item that faaborg has mocked up and some folks were prototyping a few months ago.)

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 14

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Just wanted to mention that I've looked into box notifications option which Fred used as a fallback and it looks like it's a tab specific so it's not an option here.

https://developer.mozilla.org/en/Code_snippets/Alerts_and_Notifications

Comment 15

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Maybe something along the lines of a door-hanger / panel as a fallback?

Comment 16

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Can we involve UX into this ?

Comment 17

[Jordan Santell [:jsantell] [@jsantell]]

Matteo, do you know if this is still an issue for notifications?

Comment 18

[Jeff Griffiths (:canuckistani) (:⚡︎)]

we now use the html5 notifications platform implementation across all platforms nicely, so this is now worksforme.

Comment 19

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Jeff Griffiths (:canuckistani) from comment #18)

> we now use the html5 notifications platform implementation across all
> platforms nicely, so this is now worksforme.

BTW, there are still some problems about this implementation (see bug 986624), but has nothing to do with SDK directly.