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

Mon Feb 3 09:16:28 UTC 2014

Am Sonntag, 2. Februar 2014, 20:18:49 schrieb Thomas Pfeiffer:
> On Thursday 30 January 2014 21:26:12 Björn Balazs wrote:
> > 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.
> 
> I'm not sure whether we should do that, or whether we should leave it to the
> projects to decide which user group they want to target. For example if
> there is a persona for a student who uses KDE software at school, that
> persona may be the first that comes to mind for educational applications,
> but would be likely to use e.g. office or creative applications as well.
> Then each office or creative application should decide whether they want to
> target that persona or not, or they could decide to create an alternative
> GUI specifically for the student persona.
> For me, that would reflect our actual userbase better: There is no userbase
> specific to a certain class of applications. There are users with certain
> background or which use our software in certain contexts, but I assume many
> of them use more than one class of applications (though some groups may
> indeed use only one class of applications, or maybe even just a single
> application and no other KDE applications).

You know people are lazy :) - So I would never say: Use only these personas - 
but rather try to offer a set of personas, project can choose from if they 
like. If they do not find a suitable persona for their project, they can 
create their own, just using the other personas as templates (and then adding 
their persona to the pool of personas, so others can re-use them again).

Summing it up: I would love to keep to ammount of personas as small as 
possible - I think this would even help to reach more consistency :)

> > > > 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...
> 
> Hm okay, to summarize your suggestion: We don't advertise the first part of
> the HIG to the rest of the community much for now, see how well things work
> when we ourselves apply them, and then advertise it to new UX people?
> Yes, that may work. I just don't want developers to think we're using
> unproven methods on them.

Agreed.

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