On Fri, 2009-10-09 at 18:39 +0100, Mark Shuttleworth wrote: > To the extent that the things which need responding to really are > messages, this is appropriate. What do you feel would be an example of something that wasn't appropriate? My thinking of questionable examples: App crashes. Dialog to send bug report (Seems too heavyweight ) System restart required (Too important?) Pidgin is exiting, etc (Vanity message, ok for normal, bad for interactive) My thinking of good examples: Your download is complete: Pick it up [Here] Your print Job failed. Go [Here] to resend to printer. Updates are available. Go [Here] to install. Perhaps the dividing line should be that the system MI would only handle messages that don't REQUIRE interactivity? I can ignore all the previous three examples, but the first two, not so much. Perhaps the interactivity should be limited to a click only. No decisions. Leave that level of interactivity to the callback associated with the message. > I don't think it would be tasteful to wedge things into the MI which > are not messages (but I expect people will nonetheless do so, and such > things should by policy NOT set the "draw attention" indication). I think part of this could be resolved by only setting the indicator if the application submitted a callback for action. i.e. You can't create a notification that just says "respond to me" and tell it to require interaction. There has to be an action associated with the messaging request that does something. They could still put an inane callback, but at least they'd think about it first. (Maybe) Probably ought to modify the default lib-notify messagebox to show that there is interactivity available. Something subtle. > There was a proposal on this list a while back for a "System > Indicator", which I found interesting. The bluetooth bus menu from > MacOS (and on Ubuntu and other FLOS's) is a bit of a hack - it could > be better integrated into a system indicator. Gosh, there may even be > cause fo bringing back the updates notification, as a call-to-action > on the system indicator :-) Personally, I miss that little orange star. It was a gentle reminder of open source progress. The pop-down is a little thuggish. :) > > So my response is: > > - the MI is appropriate for *message* actions that may be > consequences of notifications > - other indicators can be created to deal with *general categories* > of actions and information > - if we do this job well, we can get rid of bad, individual app > indicators What I'm thinking is that with centralization, you have control and consistency. It allows a single interface to manipulate your entire messaging state. I think there was discussion about disabling notifications in certain conditions. A really good idea. But what if you aren't communicating through Presentation? Say you're making an adhoc diagram in Inkscape using group input. Or trying to demonstrate an app. You need a one stop shop for turning off everything. But without the interactive piece, applications will go rogue. Firefox is a screaming example: I was giving a presentation the other day and firefox was downloading a data file in the background. Something for work(Really). HOWEVER, when it was complete, the download manager popped up during the presentation with something in it's history I downloaded last night. Fortunately it wasn't something embarrassing, but it could have been. The blackberry handles this nicely. Programs register in the O/S and the BB decides what you see and don't. When you don't want to be disturbed, it doesn't happen. Through an interactive MI, a global DND would be possible for compliant applications. And with a more robust messaging interface supporting interactivity, you have the carrot to get them to comply. Jim
Attachment:
smime.p7s
Description: S/MIME cryptographic signature