← Back to team overview

unity-design team mailing list archive

Re: Message Indicator message weighting

 

On Thu, May 7, 2009 at 5:26 PM, Brian Curtis <briancurtis.wx@xxxxxxxxx>wrote:

> On Thu, May 7, 2009 at 4:35 AM, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
>
> > 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".
>
> This is indeed a challenging idea.  After some thought here is the
> picture I can see in my head:
>
> I'm sitting in my desk chair and an e-mail arrives for me.  The
> indicator applet dot appears starting as yellow, signifying to me that
> I have something thats not high priority but requires an action at
> some point and I have not looked at it yet.  I click the indicator
> applet find out its not important and do nothing, after clicking out
> of the indicator applet it turns green signifying to me that theres
> something I have not performed an action on but have already looked at
> and chosen to ignore for the time being.  The yellow to green would
> apply to instant messages (gwibber, etc...) as well.
>
That's a nice solution.

I think this is one area where having a global metadata database (e.g.
Zeitgeist's database, Tracker, or any RDF store) would really pay off. Once
all emails, contacts, files, and even notifications are entered into one
central database then there are lots of interesting things that you can do
later on with that information.

For example, in GNOME Zeitgeist, we tag files based on their path. One thing
that I've been planning on doing for a long time is to track when each file
was edited. (I'd like to do it through GtkRecentManager.) If we start
getting serious about indexing items across the desktop, it's not hard to
imagine the following scenario:

Mike is sitting at his computer and working in Inkscape when several emails
arrive. In the past, Mike has clicked on the indicator icon to get rid of
the dot but has always ignored the messages themselves. Therefore, the
emails are assigned low priority and the icon only shows a green dot.

After a few minutes, Mike closes Inkscape and decides to work on his latest
project at work. He opens up a file that a colleague emailed him and begins
to edit it. The system notices that the tags on his document match the tags
on one of the emails that he received, so the indicator icon changes to a
yellow dot.

An hour later Mike receives another email and evolution automatically
inserts the email into the global database. The notifications system
receives is told that a new email arrived and automatically does a query for
similar items. It notices that the document Mike is editing was sent to him
by the same person who sent the new email. The indicator icon turns red to
reflect this, and Mike receives a relevant notification.
[End of scenario]

There are several databases out there which support the above scenario.
Zeitgeist's database can be accessed over dbus and the xesam spec offers an
enticing way to get information from any database. Ideally, I'd love to see
a platform with the following components:
1. A fast and generic rdf store (e.g. tracker.)
2. A system daemon which monitors which files are being edited and keeps
track of the current user context. (For example, see Marco Polo for OS X.
http://www.symonds.id.au/marcopolo/)
3. A high level api for inserting information into the rdf store.
4. Several guis (e.g. zeitgeist, a display built into gnome shell, the
indicator applet) which use the above components to help the user without
getting in his/her face.

Natan

Follow ups

References