unity-design team mailing list archive

[Jim Rorie <jfrorie@xxxxxxxxx>]

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