Steve Dodier wrote:
From a style point of view, you should know that I consider every extra checkbox against the "is it worth a knuckle of my finger" test.What about console-presenter and evince / other PDF viewers ? They're used too for presentations. I don't think we can maintain an exhaustive list of applications, so maybe we should provide the user with a GUI to tell which apps shouldnt be overriden and in which circumstances (and have our own default apps there, like Evince in fullscreen, Presenter in fullscreen, etc). This GUI could also maybe offer options for how to manage notifications in different presence settings (away / slightly busy / don't disturb me at any cost or kittens will die / etc), with, again, our default settings. This way, every user who doesn't feel at ease with the default behaviour would be able to make it more accurate, and we'd cover a good percentage of use cases. There's always a temptation, when two smart and well-meaning people can't agree, to add an option so they can both get what they want. It "costs nothing" to add the checkbox, and it creates the illusion of consensus because "we can each have what we want" which makes it "easy to collaborate". This dynamic drives a lot of UI - especially in open source, where the consequence of a refusal to reach a compromise might result in the loss of a contributor. But options, choices, checkboxes actually DO cost a lot. My first job was at a newspaper, and the thing I learned there was that 90% of people will read the headline, 30% will read the first paragraph, and 1% will read the last paragraph of any article. Attention is precious. Also, I learned that the 10% of people who do not read the headline are actually skipping the WHOLE PAGE. Why? Because nothing on the page jumped out of the noise for them. Every checkbox or option or knob we add, raises the noise level, and increases the chance that the user disengages completely. Also, every checkbox or option results in additional code paths, all of which generate more bugs and require more QA and more tests in the test suite. So, while "agreeing to add an option" seems like a low-cost way to avoid having to make a decision, it's an illusory solution. Collaboration is hard, but most meaningful between people who see the world differently but find a way to accept the same thing. A checkbox is an attempt to avoid that collaboration, not a mark of it. In this initiative, I want us to take a different approach. We will strip away non-essential decisions from the user experience, at the cost of flexibility in the final product. For me, that's not a bug, it's a feature, though I accept that others feel differently. I'd like to build a community that is aligned with that goal - here on the Ayatana list. This baby community is already flourishing with suggestions and ideas and code and mockups. I really loved your presentation on cleaning up and tightening the battery level notifications, and would like to see that pattern embraced across the whole system! In many cases, an idea won't be included - whether it comes from me, or MPT, or anybody else participating. That shouldn't be a disincentive to generating more ideas or more questions. The Ayatana work will benefit most from being examined and probed and debated from multiple perspectives, but it won't benefit if we try to shoehorn them all into one experience. I'd like to think we'll celebrate the fact that we decided not to confront the user with another choice, after careful deliberation. In most cases, we will not have a mechanism to vary a decision. In *some* cases, there may be behind-the-scenes mechanisms, such as a gconf option, or text configuration file option, which is not exposed through the UI. And in very, very rare cases we will thrust our indecision on the user in the form of an option. In this case, notification suppression during busy activities, I really don't think we want to expose all the permutations and combinations. In a nightmare scenario, someone "might" want to control whether notifications from Pidgin are displayed during a fullscreen Totem session differently from fullscreen OpenOffice. And That's Just Nuts, TM. Instead, we want to be able to find some core, sensible default position. First, I think that we should define clearly, and ALWAYS display, "critical" notifications. That means we have to be confident that we can ensure that apps don't call their notifications "critical" when in fact they are not. Imminent uncontrolled system status changes, like a forced suspend on battery exhaustion, are critical. In general, the failure of a network link, is critical. But a message from Mom is likely not (yes, I do love my Mom, and a message *might* be critical, but tough). In order to see which notifications are critical, Karmic is supposed to be displaying the urgency of notifications as a debug-only label during the development cycle (to be turned off at RC). On this list, we should discuss any controversial ones, and make sure we file bugs about notifications that are using the wrong urgency. "medium and low" urgencies are harder to define. I'd look to MPT for thoughts on that. I think we'll have higher-priority notifications jump the queue, so it may be that we can naturally sort them based on the degree to which asyncronicity is a problem. For example, notification of a new email is less like to be time-critical than an IM. But I'm stretching here :-) 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. 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. 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. Mark |
Attachment:
signature.asc
Description: OpenPGP digital signature