unity-design team mailing list archive

[Victor <vm.kalbskopf@xxxxxxxxx>]

I quote Mark from earlier in this list:

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.


We can now see the "repercussions" of this principal.

The problem is that there is no perfect solution, whether for
technical/design reasons or user opinion.
When users file bugs because they do not like the default behaviour of
notify-osd then the "tough, get used to it" attitude sounds allot like Apple
speaking.

The users need to be given the chance to change how notify-osd works. You
could make it really difficult to change the default settings, but they
should at least be available.

Like Martin Owens, I don't really care about when and where I get notified,
but a lot of people do, and they don't agree.

2009/10/21 Martin Owens <doctormo@xxxxxxxxx>

> Hello Mark,
>
> On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
> > First, we get much better collaboration and communication,
>
> Do we? The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate people who want to
> collaborate. There are people who will give up their personal visions
> for yours without lots of hard data, but most of those are called
> employees...
>
> > and much better testing, if everyone is looking at the same
> > experience.
>
> Testing and experience can be brought about by standardisation of
> configuration at testing time.
>
> > We found this with Ubuntu itself - we reduced the default application
> > install set to a single app for each major function
>
> The key here is 'distribution default'. I will congratulate you on the
> decision to prevent choice paralysis in normal users, insisting upon a
> single application per function at distribution time is the right
> choice. But this is development, this is upstream, that logic may not be
> relevant. I notice that you don't insist upon one application per
> function available in the repositories or launchpad PPAs.
>
> > One of the great failings of the community approach is that it
> > attracts folks who like to customise the environment to the point
> > where it is "perfect for them", at which point they stop caring about
> > the environment that the typical user sees.
>
> Why is the consumer grade user more important to design development than
> creative experimental people? This fight against the creative ecosystem
> can only be destructive. I believe it will drive people away, hurt
> upstreams, a number of side streams and limited sections of downstream.
>
> But I have no data on that, that's just from my own principles of
> inclusion and experience in trying to do the hard job of bringing
> together conflicting ideas.
>
> > In Ayatana, we'll take an opinionated stance, and we'll apply some
> > common principles to the design process,
>
> This principle isn't common, it's something I haven't seen in any other
> projects, even the ones that I would aspire to with regards to design
> and vision.
>
> > and we'll live with the results.
>
> Can you tell me what the metrics that you'll be using to see the
> results?
>
> > I have no interest whatsoever in making it possible for anybody to
> > have any environment they want - we already have that.
>
> Hmm, I can't actually believe you would say that. It sounds so,
> authoritarian. To dictate what is in the best interest of the masses and
> removing the choices of those who aren't believers in the one true
> vision.
>
> It certainly doesn't sound like "I am because of my community", it
> sounds like "I am because of what Mark likes to see". Scary in a way.
>
> > I'm interested in driving forwards to build a default out of the box
> > experience which is as good as we can make it for the new, consumer
> > user.
>
> So am I, Fixing Bug #1 is top priority. End users (not just customers)
> are where my empathy has always been.
>
> > Most people on this list are NOT a new, consumer user, so I'm afraid
> > you will have to work hard to think from that perspective if you want
> > your ideas to resonate here.
>
> I have no technical or design problems with notify-osd, it's perfect for
> me and for the hoards of people I teach Ubuntu to every week on the
> ground. The discussions I've read here have been boring in a way,
> because notifications aren't that interesting to me. Oh look,
> information pops up; ok, move on to more important designs.
>
> The problem I have is with the stated principles. I can't agree that
> limiting choice in development is worthwhile. I think it's a confusion
> between being a distribution downstream, where that is useful, and being
> a project community upstream, where the same principle is a mistake.
>
> If representatives of Fedora or Debian were to come here and provide
> upstream patches to express the options they wanted to include in their
> distributions default configuration; Would the project accept them with
> the stated principle?
>
> Principled Regards, Martin Owens
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> More help   : https://help.launchpad.net/ListHelp
>