[kde-guidelines] [kde-artists] We need a Vision!

[Thomas Pfeiffer]

On 13.03.2014 10:55, Björn Balazs wrote:
> Am Dienstag, 11. März 2014, 23:57:57 schrieb Aaron J. Seigo:
>> On Tuesday, March 11, 2014 14:55:13 Björn Balazs wrote:
>>> UX always serves a certain purpose. There is no universal good or bad.
>>> In order to provide consistency and hence a smooth experience for the
>>> user,
>>> the definition of what is desired and what not has to be made on a high
>>> level. We call this a Vision.
>>
>> This is sensible for specific project spheres within KDE. There can be no
>> KDE- wide vision of the type you are looking for because the scope of KDE
>> is too diverse. Jos, I think, touched on this but I'll expand a bit:
>>
>> We have libraries for which the audience is application developers.
>>
>> We have suites like Kontact and Calligra which have very specific targets of
>> their own ... and development resource limitations for which adopting an
>> external vision is likely to exceed the budget of. Many of these
>> applications look to a broad audience on multiple platforms.
>>
>> We have Plasma which is focused on providing a user platform (rather than an
>> application) and has device spectrum baked into its design (as that will be
>> critical to its survival in the next decade in ways that are simply
>> irrelevant for many/most KDE applications).
>>
>> There are other examples, but the above is enough to show that there is huge
>> diversity in:
>>
>> * capacity for taking on a vision
>> * target audience
>> * intrinsic attributes
>>
>> The vision for KDE as a whole therefore must, by necessity, be broad and
>> ultimately vague. A vision for a specific project (or set of projects)
>> within KDE can, however, be focused and targeted.
>>
>> I *highly* recommend picking a specific area such as Plasma and focusing on
>> developing a detailed vision for it.
>
> I am absolutely aware of what you say and also think that we might end up with
> a set of visions. The trigger simply is: in UX we need something we can use to
> base decisions on - so the minimal effort out of this is an UX vision if we
> cannot find a broader consensus.

I agree that this is what may likely come out of this effort, and that 
is totally fine, as long as in the end all projects have a Vision to 
adhere to, whether it's the one created by their project, by a similar 
project, by a group of projects (such as KDE Edu oder KDE Games) or by 
KDE as a whole.

>> This will also have the happy advantage of not having to find consensus
>> among dozens of teams and hundreds of contributors. Rather, you can work
>> with a small number of people and generate something that works for them.
>>
>> If that vision is successful *and* it has some generic nature to it, other
>> projects can then be encouraged to pick it up. This reflects the horizontal
>> structure within KDE. It takes time, but KDE is a very big boat and big
>> boats take time to change direction.
>
> +1. This is what I love (and sometimes hate) KDE for :)
>
>>> for the vision. During this process, we plan to also again ask users about
>>> the importance of different aspects if possible. Then we want to discuss
>>
>> You will never reach "the users" because most of our users are invisible to
>> and not in contact with us. We have regular contact a relatively small (but
>> very passionate!) group of our users online (and less regular contact with a
>> few more), but they are not representative of our overall user base and the
>> collective skill level in things like "define a vision" is very low.
>
> I have to strongly disagree here. True - at the moment it is hard to get in
> touch with a sort of representative sample of them - but it is not impossible
> to reach them. We do have contact to all users - because we are delivering
> software to them. On a longer term we need to hook onto this communication
> channel to reach even the harder to reach ones...

I agree with Björn here: Just because we currently cannot contact our 
users easily, we should not just give up and say "Well, let's just do 
what we think our users need, because we will never find out what they 
really need". As long as we do that, we design and develop based on our 
own needs and/or guesswork, neither of which is optimal.
If we cannot contact our users now, we'll have to find ways to do so. 
It's possible.

> Also true: The skill to "define a vision" is low. But that would never be the
> task I would give to a user. I would rather use indirect techniques to involve
> them. Users are always good at reporting about themselves and their
> experiences. So we could e.g. ask what they associate with KDE or how KDE
> needs to turn in order to have their mother / girlfirend / ... use it. Then a
> group of experts have to turn this into a coherent vision.

This is a general fallacy that often comes up: At some point, people 
thought they could create the ideal product by asking users what they 
want and do exactly that. That went bad in most cases, so people thought 
"Okay, that didn't work, so let's just listen to our gut feeling again". 
This is not the solution, though. The solution is to observe users and 
ask the right questions and then use your skill and expertise to derive 
their needs from these data.

Cheers,
Thomas