[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] 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 above.

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.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature