← Back to team overview

unity-design team mailing list archive

Re: Message Indicator message weighting


alex.launi@xxxxxxxxx wrote:
> My suggested fix for this was to assign weights to the different
> message types in the spec, and based on the most weighty indicator,
> show a different colored dot. Currently we show green no matter what,
> for the sake of argument let's assign some colors the indicator types.
> Let's say emails are yellow, microblog messages (such as from gwibber)
> are green, and instant messages are red, now consider this scenario
> I'm sitting at my desk and one of my friends tweet. Gwibber picks it
> up and the messaging indicator logs it and gets the green dot. Some
> more tweets come in, the dot stays green and I continue working. Now I
> get an email and my dot turns yellow to let me know a message of a
> higher priority has arrived, i click the indicator to reply, and
> because I still have microblog messages waiting the dot goes back to
> green. I continue working, some more emails come in, the dot goes
> yellow but they're low priority so I ignore them. Now I get an instant
> message and my dot turns red. I click to reply to the instant message
> and it goes back to yellow to let me know I still have email waiting.

In principle this is very interesting. I like the user story you paint

In practice, we should try to understand how this could be managed in an
effective manner. In practice, people are notoriously bad at managing
graduated priorities in transient lists like this.

For example, the email system (RFC822, SMTP etc) has a mechanism to
specify the "priority" of email - bulk, high, medium, low etc. It's
universally abused - none of the mail clients that I use makes it easy
or obvious as to how one would set the priority of the email, and nobody
I know trusts the data that they receive (spam often used to be sent
high priority so I bet most spam filters nuke high priority mail).

The situation I would want to avoid is actually the one you describe,
where the "normal" situation is for people to have the "green dot" and
to wait till they get a "red dot". In essence, that would mean that the
distinction between "no dot" and "green dot" is marginal, and it would
devalue the green dot entirely.

The *experience* we want to create is that "a dot creates a sense of
urgency to act". There should definitely be some entries in the list
which DO NOT create a green dot (currently, recent buddy logins cause
the dot to appear, and they shouldn't). So, by this line of thinking, I
would prefer for the options to be  "no dot" or "green dot", and I'm
happy for apps to decide whether or not they do this (and for that to be
based on user preferences). For apps in main, specifically IM and email,
we would probably take a fairly tight view of "what should create the dot".

For example:

 - buddy logins should NOT (no specific action or message to respond to)
 - IM's should (but possibly throttle the number displayed)
 - email's should by default, but it should be easy to stop that,
     - most heavy email users KNOW they always have new email, it's not
useful to remind them of that
     - maybe it's useful to be able to say "email from these people
should create the green dot"
 - twitter - I don't know
 - etc etc etc

In summary, I think human nature is not amenable to detailed priority
management in the way you describe. I think it sounds good in theory but
in practice, doesn't work. I think we would be better off with very
tight management of "whether or not the green dot is displayed", and
should figure out how best to guide app authors in that regard. i want
to make sure that anybody who sees a green dot says "oh, I should check
that". I agree with you that having it green just because there's new
mail in my inbox devalues the sense of urgency (there's ALWAYS new email
in my inbox, it's not useful information).

So I think I can relate to the argument of the Empathy guys - that we
want to be very careful about signalling urgency - but I think that's
better done through careful stewardship of the green dot than through a
richer mechanism of priorities.


Attachment: signature.asc
Description: OpenPGP digital signature

Follow ups