unity-design team mailing list archive

[Mario Vukelic <mario.vukelic@xxxxxxxxxxx>]

On Tue, 2010-04-27 at 17:22 -0400, Martin Owens wrote:
> 
> 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? 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. 

(Perceived) honesty is important, and it may be even more jarring if the
design team's communication stresses the importance of feedback and a
willingness to consider it, if the actual reality of the development
cycle rightfully or not appears to counteract that.

In my experience as a an Ubuntu user with an interest in UI design, much
of the ire I see on the various discussion boards seems to stem from the
fact that during most of the cycle the design team's changes are
invisible if you don't follow this list or http://design.canonical.com
(both of which I found only recently despite my interest). The
blueprints, which are better known, usually do not offer much insight
into the planned UI changes. The experience is that as an interested
user you are running the development version for months during the
alphas with great expectations but nothing much to see UI-wise, and
suddenly sweeping and often problematic changes land late in the cycle.

This, I think, gives the impression that the design team is not really
interested in user discussion/feedback. It also seems to me that this
way of doing things gives very little time for users to get used to the
changes, form a considered opinion and  give feedback. It also gives
developers little time to consider the feedback or identify problems in
other ways, and to implement appropriate iterations to fix them.

To give a recent example, I was open to the question of having the
window buttons on the left, but it's only now - a few days before
release - that I feel I have used them enough to get somewhat used to
them and really decide if I like them or not.

On the other hand it's understandable, if you stop to think about it
(often neglected on discussion boards), that the development cycle is
actually used for development, and it's impossible to include some
changes very early in the cycle for the simple fact that they are not
done yet. There would also be the danger that earlier inclusion would
just drag out the public discussions and with time let them deteriorate
into senseless trolling even more. 

Maybe it would help to provide explanations, links to feedback options,
etc. along with the changes. Currently users need to seek out the
information on their own - and often the first thing they read is an
inaccurate Slashdot summary that spawns a misguided discussion based on
wrong assumptions. The information could be given during the upgrade
process. E.g., I have installed apt-listchanges to email me news, but
there scarcely are any, and certainly not about the design changes. Same
if you use the GUI update-manager.