Notifications: uselessness of

[Dylan McCall]

> >>> I also find it very arficicial and unconvincing to distinguish between a
> >>> bubble that contains actions and an open alert window as two completely
> >>> different things. One of them contains text, a button to invoke an
> >>> action, and another button (x) to close it. The other contains text, a
> >>> button to invoke an action, and another button (x) to close it. The only
> >>> difference being that the first has a shape of a speech bubble and is
> >>> yellow and the other looks like an app window. What if we decide that
> >>> all app windows should be yellow and look like speech bubbles? Is it
> >>> going to magically turn them into notifications? Really, when there is
> >>> no *functional and behavioural* difference, they are effectively the
> >>> same thing.
> >>>
> >>
> >> This doesn't make a lot of sense. If they're the same thing then why
> >> are you changing it? Obviously there is difference in function and
> >> behavior or else you wouldn't be gitting rid of one in favor of the
> >> other. Put another why, if they are no *functional and behavioral*
> >> differences then why are you bothering to change it?
> >>
> >>
> >
> > Right, I'll try to explain again. The bubble does essentially the same thing
> > as the window, and behaves similarly. *Apart* from the fact, that you have
> > to click on *the icon that the bubble points to*, rather than on a bubble.
> > That's tricky! Not only that - the icon itself is enigmatic, and scary! Yes
> > it is, it may not seem scary to you, but we want *everyone* to be able to
> > use Ubuntu and update their system regularly, not just you... That's why,
> > again, we want to make life easier for people.
> 
> Who is it scary to? Who thinks an icon is scary but a flashing window
> list item isn't? Who thinks an icon is scary but windows mysteriously
> popping up isnt? We all want to make people's lives easier I think
> (there may be a few exceptions ;-)  ). I'm starting to get a little
> irritated by people in the Dx Team essentially saying that they know
> what users want/need/feel and the rest of don't and are just going on
> our own personal preferences and experiences. I don't think that's
> really what you're trying to say but it's really coming off that way I
> think to a lot of developers.
> 
> >>> The only issue regarding the U-M that has been raised and I agree with
> >>> is the fact that the window is big and clunky and uses a lot of RAM. We
> >>> will be investigating a possibility of replacing it with a simple,
> >>> lightweight alert window with short text and 3 buttons: [install now],
> >>> [details...] and [later] (exact wording TBC). I'm really struggling to
> >>> see how this alert box appearing in the background would be more
> >>> distracting and annoying than the yellow ugliness :)
> >>>
> >>
> >> That's really the only issue you think has been raised? And again, the
> >> "yellow ugliness" bit. It's like not liking the color of the house so
> >> you decide to remodel the whole thing.

Allow me to try explaining this from my excessively wordy perspective :)
As a developer, I am sure you are aware of concepts such as cruft and
duplicated functionality. I am sure you know how much those two things
suck and should be annihilated wherever possible, yet they run rampant
in every established computer desktop operating system.

Desktop Linux (traditionally...) likes having the window manager take
care of managing windows, because in theory that application should be
able to do a decent job. It has all sorts of window hints of use there
(urgency I believe being one of them); icons, process ids, parents...
all sorts of stuff gets attached to a window. GIMP uses Utility windows
so that its toolbox gets raised alongside the document. A clever window
manager can make that look nice. An awesome window manager might decide
to make the distinction more visible, for example by making those
utility windows dockable with the main window.

Now allow me to describe a typical dialog box: A window, rendered with a
GUI toolkit of the application developer's choice. Hints appropriate to
dialog boxes are set, the window is usually a child of something else.
Thanks to the GUI toolkit in use (eg: GTK) it is really easy to add
responses and content, for example with gtk.Dialog.add_button in PyGTK.
The icon can be anything. It can choose not to steal focus, it can
choose to be placed on top, it can sometimes be minimized, it can
request a specific position on the screen. Being a normal window, the
normal behaviour is to stay on screen until the close button is clicked.
The dialog can be accessed via window switchers and is accessible with
the keyboard.

Then there is the classic notification bubble. Hints, timers, responses,
content and an icon, each with slightly less functionality than what the
application's native tookit allows. Windows are presented at either a
position the notification daemon likes or somewhere specific requested
by an application. A notification typically stays on screen, above all
windows, continually. It must be dismissed with a click.
Remind you of something?

So now we have two kinds of dialogs: The ones that work like normal
windows, and the ones that appear on the corner of the screen and can be
closed a tad more easily. To a programmer, the difference is the API. To
a user, the two are functionally identical. This reminds me of the mess
that currently exists with notification area vs. window list vs. panel
applet. All three of those are bad ideas because they are functionally
very limited. To a user they present the same things in different places
and they make the same things happen. It's just that different
applications arbitrarily choose different APIs.

"But libnotify is just an easy way to make dialogs"
I would totally accept that, but it's not actually designed like that.
If it were, there would not be a notification daemon being sent messages
over dbus and the classic notification daemon would not call itself a
notification daemon. No, what happened here is the same thing that
happens all over the desktop: The notification stuff was completely
over-engineered and developers gleaned onto its deficiencies like
lunatics, entirely For The Sake Of fancy bubbles because using it for
fancy bubbles is easier than implementing them from scratch.

There are really three issues here:

      * Libnotify provides a GetCapabilities function and applications
        ignore it. A shame. I have the suspicion that Intrepid's dark
        theme during development helped drive interest in solving
        problems where apps just look horrible under such conditions.
        (Still beyond me how perfectly good developers can mess up GTK
        so tremendously; it's ridiculously easy to use). This is doing
        the same thing: Driving interest in applications using Libnotify
        properly. Granted, a notification daemon can fall back more
        gracefully whe it receives things it can't understand, but if an
        application gets capabilities ahead of time it can decide what
        kind of summary text to apply.
      * The classic notification daemon encourages functionality that
        overlaps existing components of the desktop. **Notify-osd is
        fixing this one.
      * The window manager and GUI toolkit fails at presenting low
        priority dialogs tastefully. For example, dialogs overlap their
        parent windows by default (only modal ones should do that to
        highlight their modality), and dialogs generally take up WAY too
        much space. That is ultimately WHY libnotify is used to do them;
        it's a miniature window manager / GUI toolkit to replace
        deficiencies in the one we have... instead of just fixing them.

Personally, if I was in charge, I would have fixed the window manager
part first to make the change to a simpler (more notification oriented)
notification daemon a bit easier down the line. However, I think this
way could work as well.



Bye,
Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090227/5ca2ff10/attachment-0001.pgp