unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Sorry for taking ages to catch up on this thread. I've snipped a long
piece where Jim describes the MI as a generic "respond to notifications"
mechanism.

Jim Rorie wrote:
> Pros: This would provide interactivity through lib notify and quiet a chief
> complaint.  Users would not be challenged to respond to notifications
> within a certain time frame. It would not add more clutter as this
> interface already exists.  It would use a known paradigm for receiving
> messages that you use daily to check email or IM's, thus the user
> should be comfortable with it.  
>
> Cons: It might be extra steps to go through the MI instead of directly
> to the application.  A new interactive MI responder must be built. 
> Adding system messages might be bending the MI purpose a little.
>   

To the extent that the things which need responding to really are
messages, this is appropriate. 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).

In general, the indicator space (top right of the panel) *is* an
appropriate space for persistent status and actionable items. in other
words, if there is something in "ayatana space" (your "peripheral
vision", the space away from the focused application and task but which
you need to be conscious of) then it's appropriate for it to show up in
the indicators. That's why the MI is an indicator, and it's the first of
several "category indicators" that attempt to provide generic places for
categories of actions/things/information.

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 :-)

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

Mark

Attachment: signature.asc
Description: OpenPGP digital signature