[ge-talk] Notification Server?

[Niels Reedijk]

Hi Waldemar,

Skipping over all the things we agree on, or things that you/I repeat
(to keep everything lean) :-)

2007/5/26, Waldemar Kornewald <wkornewald at haiku-os.org>:
> > > * 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?

As far as I'm concerned, I think the only thing that we should provide
an API for is showing a popup. And I hope it will be a very very very
lean popup ;-). Up to this point, I'm not yet convinced that there is
an actual need to provide app-side API's for configuring notifcations,
because as far as I can see, every application (or tool) has it's own
requirements on user communication.

Now what we can do, is make sure that developers understand what user
communication is about, and in which context they should use popup
notifications. I mean, there will always be developers that get it
wrong, but those are the same developers that don't have their apps
font-sensitive.

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

I don't necessarily agree that notifications should be (buried) in a
preference dialog. I feel that they should be placed where they
logically belong. Three examples:

- In case of a calendar application, I create a new appointment, and
in that window I explicitly request the application to notify me ten
minutes in advance. No need to go through a preference dialog here.
- My IM client is really intelligent, and shows me when someone gets
online. By starting the IM client I'm implicitly granting permission
for it to do so (as this is the way IM programs should work). However,
when I set my status to 'busy', I expect the program not to bother me
with any more notifications (because I don't want to be disturbed, by
anyone). Thus I'm changing the notification settings via my normal
interaction with the program.
- Finally, my superdelux MDRR (mail daemon replacement replacement)
can be configured to display notifications when messages with certain
priorities or from certain groups of contacts have arrived.. Here, in
the preference dialog of the program, I can change this setting.

Here you see, where to ask for notifications is highly specific to the
location. Sometimes it might be in the preference dialog. Consistent?
No. But I think putting things in the context where they belong is
more effective than standardizing it to counterintuitivity.

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

Again, I think the actual implementation is highly dependent on the
tool that you are using. I cannot think of any tool that will benefit
from this grouping of events. (There might be some tool though, I
don't pretend to think of every tool). In my opinion, forcing
developers to think of events in groups as a definition, will not
always be beneficial to the user interaction.

Niels