On 29/10/11 20:08, Aaron Mayse wrote:
> Actually it's not a "I don't want this," it's a "We don't have the
> time and resources to deal with problems that happen with this option
> when we make updates later on." The problem with making an interface
> that is infinitely customizable is that any time you make an update
> you have to check *every* one of those combinations to make sure
> something doesn't break or become unusable for the group of people who
> choose that particular combination of options. This takes valuable
> resources away from dealing with other problems which may be just as
> high priority and slows down the process of innovation, unless you
> drop support for these options in which case you have a minefield of
> options which randomly make the interface useless. At least that's
> what I think Shuttleworth is saying here. And it makes sense, to a
> degree, that limiting options makes supporting the few options you do
> have much easier and more efficient.

Yes, that's accurate.

> I'm not sure it necessarily applies in all the cases that we've seen
> the heavy-handed, "We won't fix this, so buzz off," response we've
> seen on many bug reports, but it does explain one of those tricky bits
> of Unity design philosophy that hasn't come through to most users.

It's not just maintenance costs. There are also design implications to
flexibility, *especially* layout flexibility. The system UI has many
components, all of which need screen real estate, and which can collide
with one another. Knowing where something is allows you to design other
pieces that fit with it. If it could move around, you have to think of
all the ways the OTHER pieces will have to adapt too.

There's also the idea of consistency. Knowing that "launching and
switching are activated on the left" lets us add many subtle transitions
and cues for users to entrench that idea. Which hopefully means that
they instinctively look for things in the right place. We can only
realistically do this if we limit the flexibility of the system. That's
why iOS has a springboard in only one place, same for Android. These are
modern interfaces, based on serious design work. Our goal is to compete
with those, so we're not that interested in matching functionality that
was in Win95, especially if we think that functionality will get dropped
in Windows 8 or 9 or 10.

If we want to put free software in the future, we have to design for the
future. Some will prefer the past. Nothing obliges them to upgrade.

> I think many of us really want to see a document that outlines the
> reasoning behind these "design decisions" that are being made without
> community input. Obviously I think a lot more of us would like to have
> some input on changing those philosophies and goals, but many would at
> least settle for knowing what they are.

There is as much community input in the design of Unity as there is in
Gnome Shell or KDE's Plasma. Every thread on the Ayatana list, or bug
report, is information. This discussion is information. Given the amount
of time I and others spend working with community members, it's
insulting to be accused of a lack of community engagement.

The philosophies and goals of our work have been described numerous
times by lots of people. Read my blog, and the Ubuntu design blog, and
various email lists.

> Or does everything have to go through Shuttleworth's Mother-May-I
> before being implemented? 

Must you turn this into a personal insult? Do you feel that elevates
your commentary? You may want to reconsider.

To address the question: no, nobody has to ask my permission to do
anything with their volunteer time. I do lead the design team, though,
and we do have the responsibility to define the experience we ship by
default in Ubuntu, so Shuttleworth does get to say "no" in the end. A
responsibility I attend to, regularly. In the absence of someone taking
that on, however, I guarantee you free software has zero chance of
competing with directed efforts like iOS and Android.

We've spent years diffusing our energy on a million pet options in our
UI, which is one of the real reasons free software has failed to make
any damn difference in the consumer market. Let's change that, and as a
consequence, I ask you to accept the authority of both the designers and
me, when it comes to final decisions that are inevitably going to have
occasional rough and unpopular edges.

Mark