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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala



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
Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp