Starting discussion on a new version of the notification spec
Dylan McCall
dylanmccall at gmail.com
Tue Jun 16 23:13:57 PDT 2009
A little bit loosely connected to the topic, but I'd like to point you
to something!
...That is Palm's latest baby, WebOS. Something particularly unique
about this platform, in my view, is that it has an awesome notification
system. So awesome that reviewers make an additional note for how
awesome it is, because it notifies you, then stays out of the way but
still within reach. I have never seen people care so much for a
notification system, but I can see why they do.
I would point you to the development stuff, but it continues to be
nonexistent. Still, Engadget has a nice demonstration of it in their
review here:
<http://www.engadget.com/2009/06/03/palm-pre-review-part-1-hardware-webos-user-interface/>
If your email kills that URL, as I am told can happen:
<http://tinyurl.com/pe9pob>
Watching that, I see that what happens there can be implemented here to
the same nice effect, starting from the level of the specification.
Notification bubbles need to morph into notification icons. We can't
tell application developers to do this themselves because the system
tray as a notification area is a completely broken concept. As long as
desktop environments promote that, the thing will be a jumbled,
inconsistent and oft-abused mess.
Further, we have two things with "notification" in the name:
Notification bubbles and the System Tray (otherwise referred to and
consistently used as a "Notification Area").
Lastly, we can't morph notification bubbles into notification icons as
long as the two are handled in completely different places under
completely different interfaces.
I think that app icon thing needed for KDE support could go a lot
further. That's an icon we can trust to be small. That icon is
applicable as a small form of the notification; what it shrinks into and
out of as kind of a general "this is a mail notification" or "this is a
chat notification" type of thing.
Then we can have a REAL notification area, for example in GNOME's case a
panel applet, controlled entirely by the notification daemon. It could
display notifications, then automatically turn them into icons on the
dock when they need to get smaller. Something new in the specification
would be needed to define a multi staged lifecycle, encouraging bubbles
that disappear on their own and either become icons (if they are such
notifications) or just go away.
That's about it for the specification.
When notifications become icons, actions (as they are defined now) could
be presented as a context menu. This is a huge advantage, because right
now if you look at ANY notification area it is completely unclear
whether right clicking / left clicking will disappear the notification,
give you more information, give you a context menu or shut down your
system. With this, any kind of click could just give the same menu with
a Close option somewhere on it, and any change to that convention could
occur system-wide.
As for the system tray, that's a wonderful desktop-neutral way to do
applets (small windows on the dock) that stick around for a whole
session. Great for hardware goings-on since system tray applets are
pretty much universally presented somehow. It should be considered
entirely unrelated to notifications to the point that the two systems
neither exclude nor complement each other in any way.
Bottom line? We only need one system that says "notification," and the
specification's features (as well as implementations) influence this
directly. Discuss :)
Thanks,
Dylan McCall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090616/7b8d30ab/attachment.pgp
More information about the xdg
mailing list