[ge-talk] Notification Server?

[Waldemar Kornewald]

Hi Niels,

On 5/26/07, Niels Reedijk <niels.reedijk at gmail.com> wrote:
> > 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.

I think the modal dialog could be disturbing when trying to solve
certain problems, but I agree that most of the time it might work
well.

> 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).

Hmm, I agree that if it's possible to implement this then we should
put those notification preferences in the respective app instead of a
common preferences app. OTOH, this has the disadvantage that there is
no common standard for subscribing to events. The HIG and helper
functions in the API might mostly to solve this problem.

> Now the question is: which communication problems would require
> different forms of notifications, and to what extend can and should
> these be standardized.

I think that it should be standardized, so the user can expect the
same behavior everywhere. The problem is that it must be sufficiently
customizable by the app such developers don't need to come up with
their own notification system.

> > * 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.

Unfortunately, guidelines don't work as well as an API which
"magically" makes your app comply to good rules. I'd prefer to have a
nice API and common behavior among all apps than long rants in the HIG
(and this one could be a very long rant!) and lazy developers who
still implement crappy solutions.

Do you want to say that since developers will implement crappy
solutions we shouldn't provide an easy to use mechanism for those who
design good apps? Also, if we don't provide a nice solution, who says
that the good apps will invent a consistent (between apps) mechanism?

> 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.)

Like I already said, I think that certain very critical notifications
must interrupt the user and he probably shouldn't be able to turn them
off, but in most cases they are system-level notifications. Other
notifications (app-level) should IMHO be manually activated by the
user. I guess we agree here.

My problem is how fine-grained the notifications preferences should be
and how to activate notifications in a consistent way.

App-level notifications should ideally be configured in the app
instead of a system-wide configuration dialog. This provides more
flexibility for the app developer and an obvious place for the
preferences.

IMHO, the user shouldn't select individual notifications (e.g., "User
goes online", "User sent message", ...), but instead select one single
group (e.g., "Messages and user events" or "Messages" or "No events"),
so this won't become an expert-only feature. If our API "enforces"
this (to a certain extent?) it could make the developer think more
about the notifications he offers. Activating notification should be
really simple, so this feature actually gets used by the user when he
needs it.

The UI could be a simple drop-down field which the API creates and
maintains for the developer.

Bye,
Waldemar Kornewald