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

[Björn Balazs]

Am Donnerstag, 30. Januar 2014, 14:12:23 schrieb 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 ;)

Perfect. We could even try to figure out 'classes' of KDE applications and 
suggest which personas could be used by them. This would be the same for other 
shared artefacts.

> > 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.


We have used parts of it in different projects - it has not been applied 
though to such a project like KDE and also not as a whole. There is also no 
complete description of it available yet, as we did most of this for closed-
source projects. So yes, this is an idea that is in my mind for not much more 
than a year perhaps and from the real-world tests we were able to do, I am 
quite optimistic that it has an advantage compared to other state-of-the-art 
methodologies.

Your point concerning an external reference is valid though. But as the first 
part of the HIG which we are talking about here is only used by UX experts, we 
can understand the whole thing as 'work in progress' anyhow. The idea has to 
be shared by the currently active us, and then the documentation could also be 
an output of the project, so 'new' UX people can easily adopt to it. 

The metaphor of a theatre stage has the advantage over other methodologies, 
that non-UX-experts will have the chance to quite easily understand how the 
artefacts are related to each other and how they can be applied. It is not 
fundamentally different from any other methodology that puts a strong focus on 
Person and Situation - it is just a bit more structured and hence easier to 
apply.

I still would not expect any project without proper UX support to fully comply 
with the 1st part of the HIG though. But that is independent of the 
methodology chosen...

_____________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines