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

Re: [Ayatana] Reducing Resistance to Change



On 27 April 2010 16:22, Martin Owens wrote:
> Some of that good dialectic goes on here in this mailing list, but
> that's not communicated much outside where it would do good to calm
> people. I believe some of the problems stem from language of outside
> publishings, e.g: "We've made this choice because we believe it's better
> for normal users, there are no options and if your an advanced user,
> we're not really thinking of you when we made this choice so please
> don't ask for us to add options." (hyperbole, but you get the point)

In the cases I've witnessed, the hyperbole works more like "we've
broken the current workflow for some real existing users in benefit of
some hypothetical newcomers that could or could not use the new
feature. And we don't provide a way for advanced users to restore
their previously used workflow because, well, options are always bad".
You won't overcome this perception with better language, because users
in this situation have a valid concern that won't go away with an
explanation.

I'm the first one to defend a simplified design for entry-level to
average users even if it doesn't support expert features. But this
kind of design should be only for new features and never, ever be put
in place of a previous design already in use. This is the golden rule
of computing - if ain't broke, don't fix it.


> A few of my community circles react to Design Team news with a *sigh*
> and "Oh god what have they done now". The teams reputation is low and
> it's over shadowing the really great work that's going on. How can I
> convince people to trust decisions or even get involved if they don't
> trust that the discussions are fair, balanced and considered?

You can't. You can only hope that your project is followed by those
who are willing to trust you, and ignored by those who don't. This way
nobody will feel betrayed.

People have resistance to change because they see it as a threat. In
order to overcome it, be sure you're actually not threatening anybody.
It doesn't suffice explaining your reasons for change, you must also
be sure you understand the needs of everyone that can be affected by
the change to assure you aren't treating them in a negative manner.

The best course of action IMHO is to set it crystal clear who are the
intended audience for your designs, so those outside the target can
learn to avoid it or at least understand they shouldn't complain for
not being addressed.

Of course, that's really difficult or impossible if your target
audience is 'everybody'. If that's the case, you should never favor
one kind of users in spite of the others. But doing that will severely
limit your options available. If you want to create more radical
redesigns, then limit the range of users intended to benefit from
them. *This* is where better communication would help, letting people
know when and why the design decisions excluded their needs thus
helping them step aside.


> So I'd
> like to be able to build up social relations so that we're not just on
> par with other teams, but surpass their ability to bring people in and
> form their world view into solid multi-consideration design.


Ubuntu set the stakes high with the "Linux for human beings" motto.
The awesome initial work has brought in many users, but that only
makes it harder to accommodate all them. Are you willing to compromise
the design decisions and adapt to those multiple considerations, or
are you going to push one "pure" solution for its expected benefit in
some specific cases? It's hard to balance both ways, and in many cases
one will need to be preferred over the other. Neither option is a
priori better than the other one, but people should know in advance
which one is the editorial line.


All these are my personal views on the subject, so feel free to
disagree with anything in my advice.