[ge-talk] Notification Server?

[Waldemar Kornewald]

Hi Niels,

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

I don't believe that only those writing very bad apps will get it
wrong. There are just so many details to think about that even an
overall great app can fail in the area of notifications.

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

Your first two examples are basically completely independent of the
API we provide. They're custom solutions and only developers who
invest a lot of design work into their apps will get things like these
right.

I'm also not sure if we can explain good use of notifications in a
short paragraph. A blown-up HIG where we explain every little concept
is just unusable. But maybe we can get the basics right. I do agree
that we should explain in our HIG what the ideal solution is.

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

With this grouping I just intended to force developers to provide easy
to understand notifications. I've seen pretty much everything. Apps
like HydraIRC provide complicated custom notification prefs which are
nearly never needed, but often lack very basic pre-defined
notifications. My hope is that by encouraging groupings I can force
the dev to think about what is really needed. But now that I think
about it anew, this won't work... :-/

Anyway, the pop-up is probably the central tool that ensures a
consistent look and consistent behavior, so we should indeed at least
provide that in R1.1. :)
I think you've convinced me. We can't really enforce good behavior if
the dev doesn't intend to create a well-designed app. The HIG should
be our primary tool to encourage good design.

Bye,
Waldemar Kornewald