Canonical Ltd, Canon Law :p

Good point about the resources. Most of the braintrust of this thinking is captured through participation in our ayatana and now unity-design mailing lists, but we could use a canonical statement of the goals, values and patterns.

Android (and now iPhone) have implemented a nice notification system and no reason why desktops should not implement it.

What is the right tool for the Job?

How does Ayatana/Canonical advocate a UX problem be broken down to solve self-contained problems and identify (integrated) problems?

Why aren’t there links to interaction design, user interface design, usability resources as part of Ayatana (https://wiki.ubuntu.com/Ayatana) Like there are with programming related resources so that people who get involved in Ayatana can educate themselves on the process and the system of reasoning so that more understanding can be developed and the learning curve to useful contributions is climbable?

There’s no conflict between unix philosophy and UX. I wrote an app for my mac that does one thing well: It observes apps I’m not using frequently and hides them. It *also* has various types of notifications that pop up in the right corner of my screen under specific circumstances. However, it does these using Growl, which is another app that does one thing and does it well — it manages the display of these things.

Applying all of the UX improvements that Mark suggested to my application is easy and can be done without my application’s participation in this. The guys building growl simply work to make the best notification manager they can and I defer to them.

It becomes frustrating when, for example, my IRC client wants to display notifications in the upper right corner in a way slightly differently to and incompatible with the common notification system I’ve chosen. Now I have two things trying to do one thing. One of them has its entire purpose wrapped up in doing this well for all applications and gives me granular central management, widget control, forwarding, etc… The other is an IRC client which also manages its own UI widget things. It will never do as well.

When I read the first few lines, I was worried you were suggesting tighter integration of disparate code bases in order to achieve better UX. That’s never been a good idea.

Instead, the lasting solutions tend to be those where there’s a good interface between separate programs by which they can communicate. That does not mean that those programs don’t need to be adjusted to honor the interface, but the work is usually reasonably small.

As an age-old example, the humble pipe character comes to mind. Piping output from one program into another means both make use of an interface. Each program may come with a command line flag to suppress superfluous output, in order to make the integration via the interface a bit easier.

This is good. This is the stuff of which lasting solutions are built, that are readily adopted by application developers. For a more modern example (and reminiscent of the notification problem), see the success of growl.

But that’s also the technical view. The design view is that a holistic approach is required for good UX. That much I can only agree with.

That means that once the holistic design is made, you have the requirements for the interface that needs to be put in place for applications to communicate sanely. So the conflict between “the unix way” and good UX really is a false dichotomy.