Re: [libreoffice-design] Design ethos

Hi Mirek,

Am Mittwoch, 6. Juni 2012, 19:46:09 schrieb Mirek M.:
> Hi Björn,
> The principles I put on the whiteboard was just me spitballing. The initial
> idea was that the community would suggest design principles and we'd refine
> them until we got something well-defined and something that we could all
> agree on.
> The new proposal is to take Mozilla's design principles as our basic
> guidelines, as those have worked well for them, and work off of those. As I
> believe that is a better approach, I'll simply address your concerns with
> that.

Ok, I understand that now. It usually is a good idea to build upon proven 
things. We will use those to demonstrate the problems. Just as a forword - 
despite of what I write now, it might be ok to use these principles - it 
simply depends on the goal we have. Let me quote from the article: 

"Developers encountering these keywords likely won't have any additional 
interface design training, so it is important that each heuristic is very 
clearly defined with specific examples and detailed explanations. 
Additionally, allowing developers to view all of the bugs in the software 
marked as the same type of issue, both current and resolved, serves as an 
effective way for them to further learn about the heuristic."

Therefor I understand these principles as guidelines for developers to become 
aware of UX, perhaps learn a tiny bit. Opposite I do understand something like 
the design ethos as rules for us - experienced designers and UX professionals. 
So, I think the sugested rules are good for teaching developers, but I think 
this is not what we want to do - ?questionmark?

> On Wed, Jun 6, 2012 at 6:50 PM, Björn Balazs <b@lazs.de> wrote:
> > I think this is a general problem with general guidelines as they are
> > outlined
> > in the mentioned article as well. Either they are so abstract that nobody
> > would reject them - but then it is also hard to derive any consequence out
> > of
> > them --- Or they are specific but exceptions are the rule.
>
> With the ideal design principles, exceptions would never be allowed.
> Mozilla's principles may not be perfect, but they're quite good and we
> could fix their bugs as we encounter them.
> Could you point out specific points that you don't feel good about?

No problem:

ux-feedback
    Interfaces should provide feedback about their current status. Users 
should never wonder what state the system is in. [Source: Nielsen]

-> How would you solve the save-icon discussion of the last weeks with this 
rule? (BTW: the rule is absolutely right, but hard to derive consequences out 
of it)


ux-implementation-level
    Interfaces should not be organized around the underlying implementation 
and technology in ways that are illogical, or require the user to have access 
to additional information that is not found in the interface itself. [Source: 
Nielsen, Cooper]

-> I do not even understand this one.


ux-jargon
    Users should not be required to understand any form of implementation 
level terminology. (This principle is a special case of ux-implementation-
level). [Source: Nielsen]

-> This rule is true most of the times, but what about developers as users, if 
we are developing an application for developers? They might be interested in 
this kind of terminology. But you could also stretch this rule further: It 
should actually say, use an appropriate language, because if you use any word 
(not only implementation level terminology) that users do not understand, they 
are lost. But what is this level? Answer can only be given by research.


ux-control
    Users should always feel like they are in control of their software. (This 
principle is often the nemesis of ux-interruption, especially in cases where 
developers assume users want more control than they actually want). [Source: 
Nielsen]

-> How do you meassure the "feeling"? How about actually having control? Is 
that needed as well?


ux-minimalism
    Interfaces should be as simple as possible, both visually and 
interactively. Interfaces should avoid redundancy. (This principle is often 
the nemesis of ux-discovery since removing or hiding items deep into the 
interface forces the user to rely more on memory than recognition). [Source: 
Nielsen]

-> So no shadows? No gradients? Nothing that helps to make the app feel 
natural? I would agree with, do not put in unneeded clutter - but again, what 
is needed? What is "simple as possible".


=> If you consider all the "nemesises" mentioned in the rules you can easily 
see, that you can never apply all rules. So when do you turn to which side?

An experience I have made with usability testing, esp. with expert tests and 
even in more detail with NIelsens heuristic evaluation which these rules are 
based upon is: If a customer fixes all bugs you found with the first expert 
testing, you can simply priotorize other heuristics higher the next time you 
test and he can do it all again.

So my experience is: They are too general, it is too optional which rules are 
prioritized. They might be useful to educate developers, but they are too 
abstract to lead us experts.

Have to go now, but I hope I made my point a bit clearer. I really appreaceate 
all efforts to make the design of LO consistent and good in terms of UX. But 
we should be aware of the trap of simplifing complicated things too much. Will 
take on the ball about user research (and the rest of your mail) next days. 

Thanks again for your efforts!

Björn


> > I see a possible solution - and hey, surprise - this again has to do with
> > researching and understanding users: I think we should try to define
> > conditions user under which certain rules apply. Conditions could be
> > something
> > like "If the user is likely to be in a stressful situation, prefer to the
> > use
> > of a wizard"
> >
> > As I stated before, I'm a bit hesitant about user research -- not because
>
> I don't believe it can't be useful, but because we have to be careful to do
> it correctly, as otherwise it can be quite detrimental to our design. If
> done badly, user research can be used to justify just about any design.
>
> I continue researching user design. Windows seems to do a lot of it [1],
> but I'm not sure how much it helps them, given that they're dropping
> everything they know for Metro, which firmly stands against the overcrowded
> ribbons their research has gained them. Mozilla seems to first design, then
> test, much like we do now, but then it has some guidelines that help it
> shape its design [2]. elementary does some basic user research (if it can
> be called that) on Google+ [3]. Gnome design team doesn't do any, which is
> a bit surprising, as, IMHO, that's one of the best open-source design
> communities out there.
>
> I would definitely be interested to hear about your own personal experience
> with user research and how it has lead to design decisions (with concrete
> examples, if possible).
>
> Plus every open-source project that cares about design listens to its
> users, of course, and the advantage of open development is that people can
> see the changes before the product is released, so design bugs can be
> caught before release. We've seen this just recently, with two people
> reaching out to us, one on G+ and one on the IRC, complaining about the
> usability of the new About dialog, which Astron has fixed.
>
> This is just my experience, perhaps I did misunderstand your intention here.
> > What do you think?
>
> I feel like Mozilla's design principles have worked for them and that they
> would be a good starting point for our own principles.
> As for user research, I see it as a means to an end. It's definitely
> something that will help us refine our principles and form our HIG, but we
> should be careful, as user research can be quite misleading. We should
> ensure that our principles and our HIG can be followed under all
> circumstances -- exceptions should never be the rule.
>
> [1] http://www.youtube.com/watch?v=532j9sfBcbQ
> [2] https://www.youtube.com/watch?v=hMDBwa4huUY&feature=player_embedded
> [3] https://plus.google.com/114635553671833442612/posts
-- 
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted