[ge-talk] Notification Server?

[Niels Reedijk]

Hi Waldemar (and Jonathan),

(to early responders, fundamental question at the bottom of this mail)

2007/5/25, Waldemar Kornewald <wkornewald at haiku-os.org>:
> Notifications aren't always bad. The problem is just that unimportant
> notifications shouldn't be too disturbing and the user should be able
> to stop a notification, so it never takes away focus, again (unlike
> Windows Update restart notifications).

My argument during the course of this thread has evolved the the idea
that as a user you should always negotiate with an application of what
you want to be notified. Because you aks to be notified of something,
there is little use in attaching an importance qualification to the
notfication, because all of them are important: you asked for it!

> There are basically two kinds of notifications that matter:
> 1. Unexpected events (HD full?, low battery, etc.), preventing the
> user from continuing his work, requiring immediate action.

I agree with Axel that your examples requir modal dialogs that suck
away the user´s attention. Though you might be able to come up with
cases that will require a different way of work.

> 2. User is waiting for an event and wants to get notified.
> => Maybe pop-up, maybe blinking icon in Deskbar?
> These should be explicit subscriptions.

Yes, and these should be negotiated between the user and the
application. Jonathan, you propose to have a common notifications
dialog. I´m truely wondering what you would put in there. In my idea
of user-tool interaction, the notifications are always a response or a
result to commands the user has given. By starting your IM
application, you grant permission for this tool to bother you. When
you configure your email application, you can determine whether it can
interrupt you when new messages have arrived.

Now imagine taking that to a common preference application. How would
that be more intuitive or consistent? You are basically forcing
applications to detach their user communiation from their core
program. That´s silly: the core task of any tool is performing a task,
and depending on the context of the task, interact with the user.
Furthermore it suffers from the ´bother the messenger´ syndrome: you
are basically telling the postoffice that you don´t want your bank
statements anymore. That´s just silly (pardon the rhetoric).

> My open question are:
> * How should the user get notified when he explicitly subscribes?
> We need different notification types, depending on the importance.

Well, let´s separate notifications from popups here. I recall the
thread initial started to implement a popup tool for consistent
popups. As I argued, I don´t see the use between different priorites.
Now the question is: which communication problems would require
different forms of notifications, and to what extend can and should
these be standardized.

> * How do we make event subscriptions easy and not annoying?
> How fine-grained should event subscriptions be?

Again, this is the business between a tool and the user. And you know
what? No matter how much you can ´fix´ for application developers by
means of implementing a default dialog and adding severities, it´s
unneccesary. Good tools will get it right anyway. And I bet that badly
written tools will have more Human Interface flaws than just this.
Face it: there will be tools that get it right, and there will be
those that get it wrong. Our job as ´Haiku´ is to provide good
guidelines and to make sure that our applications work.

> -------
> How will IMs notify the user of a new message? Temporary notifications
> wouldn't be sufficient. Permanent notifications would have to
> disappear when the user actives the message dialog. How can this be
> done?

Good question. Should the popup server watch the input server like the
screensaver kit does? In that case it knows when the user is not
there. Remember, in my theory the user requested his notifcations.
Because of that, we can assume that the user is interested in all
notfications.

> -------
> Applications should be able to associate an action with the event, so
> when the user clicks on, for example, "Marc is online" he can
> immediately write a message to him.

Good point. Also leads to the question, how much information needs to
be shown? What can an application customize? How do you interact with
the messages? How to configure them?

Note that these are questions with an easy answer, but to find truely
user friendly and intuitive solutions, we might need some out of the
box thinking and experimentation.

Anyway, there is currently one  fundamental question on which this
discussion of a post-R1 (IMO!) feature should be focussed:

In application to user communication, what kind of
interruptionalability (is that a word?) should the application have?
(My opinion, the user should be the one to choose what to be
interrupted by.)

The answer to this question will provide us with the requirements of
the notification service. Most of the design discussion in this thread
seems to be based on the idea that communication should be decided on
by the app, rather than the user (which might be the eventual
outcome). However, I urge everyone to properly think over this
assumptions first. Look at the arguments for and against. Let´s try to
work the basic concepts first. Then we can discuss which of the (some
of them excellent) ideas should be implemented.

Niels