unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

Steve Dodier wrote:
> 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.
>   
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.

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