[kde-guidelines] Styleguide, Section 1 (Vision, Persona, Scenario)

[Thomas Pfeiffer]

On 30.01.2014 11:04, Björn Balazs wrote:
> Thanks for adding the sections! Great work!
>
> Concerning the examples:
>
> For personas, I think we should try to find KDE wide personas and projects
> should be encouraged to pick the best fitting ones. But as for vision and
> scenario, they should also be allowed to create their own. We should somehow
> create a pool of real world examples for each artefact. So if KTP wants to
> actually work on these artefacts the results need to be easily accessible,
> just like those from any other project...

Given that I hosted the session about the creation KDE-wide personas at 
last year's Akademy, I think my position on those is clear ;)

> Also I would like to question the choice of artefacts. I like to use the
> metaphor of a stage play. When we want to find UX solutions, we need to
> understand some sample scenes of the interaction. Each scene (I would call
> this scenario) has some roles (persona) and there is a stage with some stuff
> on it (I like to call it situationa). The narrator will tell us about the
> feelings of the actor(s) (I like to call this animata) and what they want to
> achieve (the destinata) when they enter the stage (aka start the interaction
> with the to-be-designed tool)...
>
> Personas, Situationas and Animata can well be shared between the different KDE
> projects. Destinatas need to be defined individually (and hence the
> scenarios).
>
> The vision is sitting on top of it all :)
>
> What do you guys think?

I like the theater/stage metaphor, but has it ever been used in this 
context (including the proposed terminology) before? If not, I think the 
method should be described in detail somewhere else beforehand, as I'm 
not sure if HIGs are the right place to introduce a completely new 
method. If you invented the concept and haven't had the chance to try it 
out yet, KDE could of course be a test candidate, but I strongly prefer 
to have HIGs based on tried and true knowledge, so I'd then prefer to 
test how well the stage metaphor works with a few KDE projects, then 
publish it if it's successful and then put it into the HIG.
If others have used that metaphor with that terminology before, than we 
can just link to a document describing it and it's fine with me to use 
it in the HIG.