unity-design team mailing list archive
-
unity-design team
-
Mailing list archive
-
Message #00983
Web application notifications vs. Notify OSD
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Last month I had an e-mail exchange with a developer of Chromium, who is
implementing out-of-page notifications for Web sites as an experimental
extension to existing Web APIs (apparently with the intention of
proposing them to the W3C later).
His difficulty is that his extension assumes that notifications are
interactive, whereas Ubuntu's native notification bubbles are not.
With his permission, I've attached our discussion here.
- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktywmoACgkQ6PUxNfU6ecrDzwCdHsRKVtB2bTblaPBSQBBc8GXH
cHgAoJY8DeP5N+yrClile+IcXOrWol8C
=69OI
-----END PGP SIGNATURE-----
--- Begin Message ---
(Just a guess at the email address for Matthew Paul Thomas, hope I got
it right.)
Hi,
I'm a developer on Google Chrome (aka Chromium) for Linux. Lately
we've been discussing a new web API that lets web pages display
notifications as well (a common use case is for gmail to tell you
about new messages; you can read more about it here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html
).
It would, of course, be awesome if we could integrate these with the
other "system" notifications, but there are a couple of hiccups that
mean the broader Chrome team (who don't especially care about Linux;
or maybe more accurately, care about it proportional to its market
share) is skeptical we can.
In particular, issues like these:
1) Web notifications can be HTML, including using images or links. My
thought is we could special-case the 95% of usages which hopefully
will be plain text.
2) Web notifications (which I believe you first must opt into on a
per-site basis) have a mechanism on Windows to turn them off
interactively via the popup. We think we could maybe forgo this on
Linux if the other details work out.
You might reasonably ask if we can change how notifications are
specced to work around these issues, but the counterargument is that
it's a bit backwards to let system limitations drive the design,
especially when those are Linux-specific limitations (on Windows and
OS X there isn't really a standard system for this sort of thing).
Failing that (it does seem like a general impedance mismatch) do you
have any thoughts about how we could make web notifications not be too
heinous when used on a Ubuntu system? As it stands it looks like
we'll show them in the lower right corner, which at least means
they'll not be overlapping with the other notifications...
Here's a screenshot of a work in progress (note that it was written by
someone who doesn't have much Linux experience; Chrome policy is that
if you do a feature, you do it for all platforms, so my intent is to
let him land something that kinda works and then have people like me
who understand X better do some polishing): http://imgur.com/dF4vP.png
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Evan
Thanks for getting in touch about this. I'd like to forward your message
(and this reply) to the Ayatana mailing list
<https://lists.launchpad.net/ayatana/>, where Ubuntu notification
issues are discussed publicly. Let me know if that's okay.
Evan Martin wrote on 08/01/10 03:16:
>...
> I'm a developer on Google Chrome (aka Chromium) for Linux. Lately
> we've been discussing a new web API that lets web pages display
> notifications as well (a common use case is for gmail to tell you
> about new messages; you can read more about it here:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html
> ).
I gave the Ubuntu perspective on Web notifications on the same mailing
list earlier the same month.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018769.html
> It would, of course, be awesome if we could integrate these with the
> other "system" notifications, but there are a couple of hiccups that
> mean the broader Chrome team (who don't especially care about Linux;
> or maybe more accurately, care about it proportional to its market
> share) is skeptical we can.
>
> In particular, issues like these:
> 1) Web notifications can be HTML, including using images or links.
> My thought is we could special-case the 95% of usages which hopefully
> will be plain text.
Do you mean use libnotify to show the 95% that are plain text, and have
a different presentation for the others? That's an interesting idea.
You'd need to weigh up the weirdness of having different notifications
from the same program (Chromium/Chrome) shown in different ways, versus
the weirdness of every notification from Chrome being shown a different
way from notifications in every other Ubuntu application. I can see you
could argue that either way.
> 2) Web notifications (which I believe you first must opt into on a
> per-site basis) have a mechanism on Windows to turn them off
> interactively via the popup. We think we could maybe forgo this on
> Linux if the other details work out.
Fair enough.
> You might reasonably ask if we can change how notifications are
> specced to work around these issues,
That is why I posted that reply to the whatwg@ list last year, yes. :-)
> but the counterargument is that
> it's a bit backwards to let system limitations drive the design,
> especially when those are Linux-specific limitations (on Windows and
> OS X there isn't really a standard system for this sort of thing).
We decided that (1) avoiding accidental clicks on interactive parts of
unexpected notifications, and (2) avoiding the need to wait for (or
manually close) a bubble before dealing with stuff behind it, were
valuable things to achieve. More valuable than allowing interactive
notification bubbles, because applications can already use banners,
dialogs, or floating windows if they want interactivity.
> Failing that (it does seem like a general impedance mismatch) do you
> have any thoughts about how we could make web notifications not be too
> heinous when used on a Ubuntu system? As it stands it looks like
> we'll show them in the lower right corner, which at least means
> they'll not be overlapping with the other notifications...
One possibility would be to present notifications in a banner (like the
"Chromium didn't shut down correctly" banner that I see after every
Ubuntu login;-) attached to the relevant page. The downside is that Web
developers probably wouldn't think that sufficient for minimized or
background pages.
Another possibility would be to use a floating window
(_NET_WM_WINDOW_TYPE_UTILITY, I think it is) to collect Web
notifications -- opening or resizing it when notifications arrive, and
resizing or closing it when notifications expire. This would have the
advantage of having a native title bar (so users can drag it to another
corner, if they prefer future notifications to appear there) and a
native close button. The downside is that it would reintroduce the two
problems that we eliminated with our native notification system. (And if
you implement your specification as-is you'll have those same two
problems on Windows and Mac too, albeit that Windows users already
suffer from them.)
Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktHJxkACgkQ6PUxNfU6ecq6hgCgqNcoICEaNh9GcDwGNbgp6n/w
UOEAoL8gjDG26lTOv9GxqQiJYQPqENLY
=Dohd
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
On Fri, Jan 8, 2010 at 4:37 AM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:
> Thanks for getting in touch about this. I'd like to forward your message
> (and this reply) to the Ayatana mailing list
> <https://lists.launchpad.net/ayatana/>, where Ubuntu notification
> issues are discussed publicly. Let me know if that's okay.
Sure, go ahead. I'm not sure there's a lot of fruitful conclusions to
draw, though...
> We decided that (1) avoiding accidental clicks on interactive parts of
> unexpected notifications, and (2) avoiding the need to wait for (or
> manually close) a bubble before dealing with stuff behind it, were
> valuable things to achieve. More valuable than allowing interactive
> notification bubbles, because applications can already use banners,
> dialogs, or floating windows if they want interactivity.
Yes, those goals seem completely reasonable to me. It is a downer
that it probably means we won't be able to integrate with it, though.
> One possibility would be to present notifications in a banner (like the
> "Chromium didn't shut down correctly" banner that I see after every
> Ubuntu login;-) attached to the relevant page.
You're saying you're running a binary containing arbitrary additional
patches that we don't support and then not reporting crashes? Sounds
like an Ubuntu user. :P
(But seriously, I would be interested to learn more about that problem.)
> The downside is that Web
> developers probably wouldn't think that sufficient for minimized or
> background pages.
Right; web developers can already display banners within the web
frame, so the purpose of this API is for notifications that belong
outside.
> Another possibility would be to use a floating window
> (_NET_WM_WINDOW_TYPE_UTILITY, I think it is) to collect Web
> notifications -- opening or resizing it when notifications arrive, and
> resizing or closing it when notifications expire. This would have the
> advantage of having a native title bar (so users can drag it to another
> corner, if they prefer future notifications to appear there) and a
> native close button. The downside is that it would reintroduce the two
> problems that we eliminated with our native notification system. (And if
> you implement your specification as-is you'll have those same two
> problems on Windows and Mac too, albeit that Windows users already
> suffer from them.)
I guess our best option at this point is to try out what we've got and
see how horrible it is. It may be the case that only two web apps
ever make use of this API, or that it is shot down by the HTML5
specification process. At least history will note we tried! ;)
--- End Message ---
Follow ups
