Desktop Notification Spec update request: "progress" and "progress-label" hint

[Jan Jurzitza]

Hello all,

I think there should be a progress hint in the notification spec (as in
showing a progress bar inside notifications). Progress bars inside a
notification can be useful in many ways:

* Show file operation status (copy, upload, download)
* Show task status (steps until completion, etc)

But you could also have simple progress indicators (represented as bar,
but not updating) which can display other kinds of information:

* Background setup wizard step indicator
* "Hard drive nearly full" notification with current usage
* Internet quota warning notification with current usage

My suggestions for updating the spec would be the following:

Servers supporting progress bars should add the Server Capability
"progress". Description: Supports showing and updating progress bars.
If returned, the server must support the "progress" and "progress-label"
hints.

Add "progress" of type byte to the standard hints. Valid values would be
integers between incl. 0 and incl. 100 to represent progress. A value of
-1 should be an indeterminate progress bar. For example this would be the
state when starting a file transfer before a connection has been
established. In an ASCII notification server this could be realized using
an animated spinning \|/-

Values over 100 should be clamped to 100, values under 0 (not including
special values such as -1, possibly more in the future) should simply be
discarded and the notification server should not show a progress bar.

Additionally add "progress-label" of type string to the standard hints. If
this is set the progress bar should have a label (inside it or near it)
with the content of this string. If the string is empty the label should
be hidden. If this hint is not specified the server should decide what it
shows as default label. The server must be able to show this string in
some way, if provided.

Updating a progress bar would simply call the existing Notify method and
use the replaces_id parameter. To ensure a fluent desktop experience this
should not be called more than a few times per second. But also to make
sure that no already closed notifications are still trying to be updated
by the client.

An ongoing notification which shows an always updating status should use
the existing resident flag to ensure that it stays open. The existing
actions argument can be used to implement a cancel button by the caller
side.

Adding this to the spec would make file and network operations more
transparent and accessible. Additionally it would standardize DE specific
solutions such as KNotifications/KUI JobView in KDE.

Thanks,

Jan Jurzitza

[Matthew Paul Thomas]

Post by Jan Jurzitza
Hello all,
I think there should be a progress hint in the notification spec (as
in showing a progress bar inside notifications). Progress bars inside
* Show file operation status (copy, upload, download)
* Show task status (steps until completion, etc)
…

This would work poorly, because notification and progress feedback are
fundamentally different things. Trying to convey them with the same
element would introduce two problems.

First, a notification is tolerated floating in front of your other
windows only because it is visible for only a few seconds. But even if a
particular task usually takes only a few seconds, it might occasionally
take minutes or hours. And a notification shouldn’t obstruct your
windows for minutes or hours. (A progress dialog, on the other hand, is
happy to be layered behind your other windows once you tire of it.)

Second, when people dismissed a notification that showed progress (for
example, because it was taking minutes or hours), some people would
reasonably expect doing that to cancel the task; other people would
reasonably expect it not to. It would be ambiguous. (This is also why
progress dialogs, like other dialogs, shouldn’t have close buttons. The
only way of closing them should be an explicit “Cancel”/“Stop” button.)

Post by Jan Jurzitza
But you could also have simple progress indicators (represented as bar,
* Background setup wizard step indicator
* "Hard drive nearly full" notification with current usage
* Internet quota warning notification with current usage
…

In addition to the other problems, it is bad design to use a progress
bar as a gauge of anything that isn’t progress. Some people will
(consciously or subconsciously, depending on the context) expect it to
fill up when it’s not necessarily going to. And a well-designed theme,
which reassures people by animating progress bars, becomes distracting
when a developer misuses a progress bar as a gauge.

These are all examples of the general design rule that things that
behave differently should look different.