Let applications be applications
One thing that kept bothering me in the GNOME UI Hackfest was how little data applications export out to the desktop. As I was in the shell group we were discussing various things that we wanted to do and John Mccann kept having to remind me not to worry about the implementation as I would get frustrated that we simply didn't have the data. I want to fix this. I want to have the data in a structured way.
What I've come to realize is that we need to let applications be applications, let panels be panels and let applets be applets. With the notification area specification we created a way for applications to break through this barrier and put a little segment of the application into the panel. While this sounds great, and it has created a quick way to prototype some interesting ideas, it's also created a complete mess in our panels. There is no consistency of action nor in look for that section of the panel. I like to call the notification area the "bag of crap." While it's created a way for applications to innovate, it's drastically stalled innovation for panels and shells.
What I'd like to put forward is the idea of little flags that applications can hold up to say what they're thinking or doing, which I'm going to call indicators. The application can then represent in a structured way that it's got something of interest to the desktop as a whole, and then the desktop can represent that to the user. How ever it likes. It's not the application's responsibility to figure out how to do this, or if it needs to be done in a single place or multiple, or anything other than raising the flag. While I think that this might frustrate application developers at first in that they don't have control over the display of this information, I think that long term it will empower them in that they don't have to fiddle with this type of interaction any more.
First off I want to build something simple (start small, think big), the messaging indicator, which will mostly consist of a GNOME panel applet. It will do simple things like represent IMs and e-mail and not a lot more, but the real goal is starting to get applications like Evolution and Pidgin to export this information. Once we're there, then we can start to look at new ways to use it. I love the idea of having the Evolution icon having the number of unread messages a la Apple or Gwibber also putting messages in the messaging indicator. Those are all next steps, but I think important ones in starting to explore how we can get data out of the applications and to the users in usable and attractive ways.
posted on Mon, 05 Jan 2009 at 23:52 | permanent link | 6 Comments
Those little flags, are they like notifications but more permanent? It's not a bad idea. You could write small applets or widgets for each of the apps or for a generic system (eg a media player widget which has mepris support and thus supports any media player). But having a generic way of showing the status of something, yeah, it's a decent idea. Could probably be part of notifications spec - after all, the receiver could choose to display it anyway it wants.
My biggest issue with this is that perhaps this is no longer relevant to me.
You list Pidgin and Evolution as the two primary example applications to make use of the new notifications, however, I don't use either of them any more.
Everyone at home is on gmail, and if they want to chat, they use meebo.com. With applications becoming browser-based, how can we integrate them with profoundly useful things like desktop notifications?
Will it be the responsibility of the delivery protocols to access them? Can Java, Air, Flash, HTTP, js, AJAX make use of these specs sufficiently?
Correct me if I'm wrong, but this looks like a call for better model-view separation. Would dbus notifications from apps help here (model events), leaving the panel / shell UI to handle them as they see fit (view rendering).
I think the basic idea is great! Having a uniform way of showing notifications is very much a big issue although dbus kinda tries to cope with that. I do agree with Odysseus about the web relation though. I think it is not only about desktop notification anymore, I personally use Google services for most of my day to day things as well as things like facebook and other public web related services.
Web2.0 was al about renewing the web and make it more social, I personally think the next step in desktop development will be a switch to a more social and web focussed way of using the desktop. Maybe the desktop can't do this on it's own, but needs help from applications, maybe there could be a kind of plugin system for the notification area where you can plugin little programs for checking web services.
Just letting my thoughts run free, but maybe you can use some of it for your idea. It sounds to me like more than just a model-view adjustment.
"Those are all next steps, but I think important ones in starting to explore how we can get data out of the applications and to the users in usable and attractive ways."
What about gobject-introspection? Should not all applications export their data through introspection? Then it would be the resposability of any other tool to present the data to the user the way the user expects.
I would take this one step further in that the application should not even deploy a GUI, it should simply be a "server" and some other tool would be the responsable to make-up, to theme, the data and interface the way the user wants.
Did you see Mark Shuttleworth's blog entry about notifications and the notification area? Check it out: http://www.markshuttleworth.com/archives/253
I think the guys at Ubuntu may take some work out of your hands.