embracing our goals together

Aaron J. Seigo aseigo at kde.org
Thu Mar 29 12:16:43 UTC 2012


hi...

listening to the various people involved in the creation of new bits of UI in 
the shell, it seems that people concentrated on or were distracted by various 
issues and "let's make a pleasing and elegant UI" got lost.

here's the hard and uncomfortable reality: when i first saw the new UI changes, 
i instantly realized i could not show it to others and be proud. it was not up 
to the standards we had shown ourselves capable of in the past. it was, in a 
word, embarrassing. 

this is not limited to the Activity Settings UI, but when looking at the 
result of the work on the Activity Settings UI and then listening to various 
people involved, here is what i noted :

* there was a lack of consensus around the implementation

* the reasons why certain things could/could not be done was not well 
understood by everyone (both technical requirements as well as UI design)

* there was a feeling of conflict between the different people involved, a 
feeling derived from the belief that different people had different goals that 
could not be harmonized

put bluntly, people focusing on UI design did not fully appreciate the 
technical hurdles and those working on the technical requirements seemed to 
view those working on UI design as obstacles in the path to implementation.


		the result was something nobody was truly happy with.


this leads to a shocking question: 

		if no one involved in the creative process was truly happy with it,
			how did it become the result of our efforts?

it would be easier to understand if someone in our team thought it was the 
best UI ever; but was anyone truly, deeply proud of that result? did anyone 
feel that "awesome!" feeling when it was finally completed? or did everyone 
feel they'd compromised somehow, producing something dominated by the 
weaknesses of the compromise rather than by the strengths of an answer the 
team came up with together?

we need to remember that we have a shared goal here:

	to make an elegant user experience that supports life's activities

that trumps everything. 

					EVERYTHING.

there is no implementation principle that is more important than that, there 
is no design concept that deserves attention before that goal is understood. 

technical issues and design decisions are the tools to reach that goal, but 
they are not the goal in themselves. we each have unique tools which we bring 
to the team so that we can reach that goal together. our individual skill sets 
are not to be used in conflict, but to create a coherent direction that brings 
us to our shared goal.

that was seemingly lost in the creation of this particular UI component, and 
it showed starkly in the results.

having thought about it some more, i regret having proposed a set of 
improvements as i did. 

it would have been better if i had first asked you if you were truly happy with 
the result, and if not what you would do to improve it. once improvements had 
been found by working together, we could then have reflected on the differences 
in process that got us from "nobody is 100% happy with it" to "something that 
is elegant"

i squandered that opportunity in my desire to "simply fix it", but we still 
have an opportunity to reflect and learn.

i invite each of us to think a little on how it came to be that lines were 
drawn between "the UI designers" and "the people doing the implementation", 
how undesired compromise overcame elegance.

this is not an invitation to blame others. instead, let each of us consider 
our own contribution: how did i chose to interact with others? what 
opportunities for consensus were missed? how did communication between 
requirements and design broke down?

and remember: the problem is not the result. the result can be improved on 
through iterative input and effort.

the problem is the process. we know how it can work, because we've done it 
many times already with really good results. 

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20120329/71660fc2/attachment.sig>


More information about the Active mailing list