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

Re: [Ayatana] notify-osd + fullscreen + multiple monitors



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.