unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Alex Launi wrote:
>
>     For apps in main, specifically IM and email, we would probably
>     take a fairly tight view of "what should create the dot".
>
>
> This is great for apps in main, but we can't forget about universe
> just because it's not main. If apps in universe are abusing the
> indicator it will still undermine it, and although it's not
> *supported*, I don't think our users will really take that into
> careful consideration.

Yes, I agree. We can get it right in main, in Universe we are dependent
on the level of interest and support for the idea from Ubuntu developers
and upstreams. That's why I think these discussions are important; they
help to test the ideas and build the level of community support for the
initiative. So thank you.

>     For example:
>      - 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"
>
>
> This is interesting but isn't this too much user interaction? To have
> to manually state "I want email from these people" means I have to go
> add all of the people whose email I think I need immediately, which is
> more often than not, not the people I get frequent email from.
Now we are getting to the very interesting part of the discussion :-)

I strongly believe that a feature like this is only interesting if the
work that someone has to do to take advantage of it pays dividends in
many different ways, in many different places. If I have to go into my
email configuration and specify an email address that's "important" so
that it "gives me the green dot", that's a LOT of work. On its own, the
payoff (a green dot on new email from that address) isn't really worth
it. ESPECIALLY if "I get frequent email from" these same people - in
that case, I may as well just use the green dot to indicate ANY new
mail, since there's a good chance it comes from one of those people.

But what if flagging a contact as "important" was used in MANY different
applications? That gets more interesting. For example, what if the IM
and email apps shared an addressbook, AND they shared the "important"
flag, so that marking someone as important changed the way both apps
behaved. Suddenly it's more useful to garden that data.

I think we would benefit greatly from asking ourselves the question "how
can we make the work that people do more valuable by re-using that work
across the system".

For example, we are looking at increasing the perceived value of the
"status" flag that is set in the top right of the screen. Currently,
that's only used by your IM client. But it might also be used elsewhere,
for example, "Busy" could suppress non-critical notifications. Finding,
and defining, these cross-application experiences is a major goal for us
in this initiative.

So, any good ideas in this regard?

For the moment, until we have shared addressbooks across mail and IM and
other apps, I'm -1 on trying to identify contacts as "important" because
I think the feature will not be compelling, discoverable or widely used.

>     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.
>
>
> I'm not sure this is realistic (as I stated above), but you were spot
> on with notifications, and I'm interested to see how we solve this
> problem, if not by a hierarchical priority based system.
Thank you for your trust - let's keep discussing the priority idea.

For the moment, I think the messaging menu will stay binary ("no queue"
vs "stuff to do"). But we definitely have a priority / urgency goal for
Karmic in notifications. We are turning on a debug behaviour for
notify-osd so that urgency will be visible on notifications (it will be
turned off again before the release) to help us identify which apps use
urgency well and which abuse it. And we'll be testing various algorithms
to use the notification urgency for message duration, queuing priority,
and discarding in the case of an overfull queue. So there's lots of
thinking to be done on the general subject of event / message urgency,
and perhaps that will bring us back to the messaging menu with a
different perspective.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature