unity-design team mailing list archive

[Martín Soto <donsoto@xxxxxxxxx>]

On Mon, Jul 6, 2009 at 6:49 AM, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:

> Second, I think we want to do some useful inference of busyness. I like the
> fullscreen idea and was a promoter of that, but I think there have been
> compelling counter-arguments on this list.
>

The problem with fullscreen is that it is too ambiguous as an information
source. As pointed out by others, fullscreen can mean that you're busy, but
it also can simply mean that you want to make better use of your screen's
real state. As you say, however, the idea has merits, so we should probably
explore it further.

I would say that notifications on top of fullscreen are generally not a
problem when the user is the only person looking at the screen. If I'm
testing my presentation or watching a movie on the train, being notified of
a new IM message is probably OK. On the other hand, if 10 people are looking
at my presentation, or my date is watching the movie with me on the
widescreen TV, I probably don't want IM texts or e-mail subjects being
pasted all around. The question is, then, can we reliably detect the fact
that video is being sent to an external projector or TV and block
notifications in that case? I realize this can be tricky, because many
people have multi-screen setups which aren't intended for presentation, but
I guess the idea is worth exploring, anyway.


> One approach might be to extend the queue-life of notifications, so that if
> one enters fullscreen mode for a minute, say, one still gets notifications
> that queued up, but if one does it for longer they start to die off in the
> queue. We certainly don't want people to get ancient notifications, or
> flooded with notifications when they come out of fullscreen. So this is a
> fruitful area of discussion.
>

This is a related, but separate problem, I think, as it happens also in
other situations, such as when the screen saver is active. Holding
notifications for a while is a good idea, so that you know if something
happened in the last few seconds/minutes before your arrival. For example,
if I just came back to the computer or finished delivering my presentation,
knowing that someone sent an IM two minutes ago is useful, because it's
still a good time to answer.

On the other hand, if the IM was 30 minutes ago, answering now may or may
not be OK, but knowing that someone wrote during the time I was away (or
busy) is still useful. How about replacing the specific message
notifications in this case by something like "You have 3 pending IM
messages"? The general idea is that when you are back to the computer or
come out of the busy mode, you'll be notified of what happened in the time
you were away. However, the level of detail must be adjusted based on the
amount of information available and on its relevance at the time the
notification is finally delivered. This means that you don't necessarily
discard older notifications completely but put them together as necessary to
not overflow the user with data.


>
>
> Third, I think we want some way for the user to influence this, but we want
> it to be systemic (i.e. ONE knob for the WHOLE system, not
> knobs-per-app-per-condition). We've talked about using the presence state
> that is exposed in the FUSA work that Ted Gould did for 8.10. I like that,
> but need to think about the real meaning of the various states we expose
> there, with regard to notifications. The last sketch I saw added a
> "Presentation" state, which was like "Available" but silenced notifications.
> I think it's wrong to use the term "Presentation" because that's only one
> use-case, but I haven't formulated that thinking clearly enough to have a
> strong counter-proposal yet.
>

I would also say the relevant mode is not strictly "Presentation" but rather
"people are looking, don't embarrass me, mom!" It's clear to me that
detecting the "don't embarrass me" situations automatically is not always
easy (yes, your boss may be looking over your shoulder...) but there are
certainly some obvious ones we can handle. The idea of detecting the active
video out goes precisely in this direction.

Cheers,

M. S.