Re: [libreoffice-design] Design ethos

Hi Björn,

On Wed, Jun 6, 2012 at 8:45 PM, Björn Balazs <b@lazs.de> wrote:

> 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 the contrary. These are simple principles that should guide all designs,
whether they come from developers or designers, and would be the basis
under which all designs would be judged. (Much like basic arithmetic is
applicable for both first-graders and adult mathematicians.)
On top of these principles, though, we'd have a HIG for specific
situations, such as desktop integration (e.g. requiring a "Close" button on
dialogs, as Gnome 3 and Mac OS feature modal dialogs without title bars).

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

Easy. The "Save" icon should be active if there is anything to save and
inactive if there is nothing to save. As we have determined that it is
useful to be able to save view settings, the "Save" icon should become
active even if only the view settings change. (I don't think it makes sense
to disable the icon if we think saving view settings is genuinely
useful.) And, in that respect, the Save icon would indicate saved status,
as it is meant to.

If we also want to indicate whether the document's contents were edited
(above the dialog that asks the user whether he'd like to save the edits he
made to the document, which doesn't apply to view options), we could have a
special "Save view edits" icon for when only view options were edited and
contents were left intact.

(I'll post this to that thread now.)

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

I agree that the wording of this one is confusing. As I understand it, the
UI shouldn't be based on the underlying code in a way that's illogical to
the user.
You can see the relevant bugs at
https://mevootserv.appspot.com/bugzilla.mozilla.org/buglist.cgi?keywords=ux-implementation-level
For example, if you take
https://mevootserv.appspot.com/bugzilla.mozilla.org/show_bug.cgi?id=615306,
the behavior of the back button is based on some code that tells the
browser to go back to the previous site, which isn't always friendly to the
user, as it doesn't take into account redirects which take the user right
back to the site he was at -- something the user didn't want if he clicked
the back button.

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


It, of course, doesn't apply to UIs meant exclusively for experts that are
familiar with this jargon (so it is OK to have medical jargon in an
extension meant exclusively for doctors).
As I understood it, the main purpose of the principles was to avoid showing
pieces of the software's code in the interface (such as with those
stereotypical unhelpful error messages), though the interpretation has been
clearly extended to use of language in general (
https://mevootserv.appspot.com/bugzilla.mozilla.org/buglist.cgi?keywords=ux-jargon
).

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.


What would this research look like?
To be honest, when it comes to generic language, I believe that if a user
cares enough to report a bug about it, then it should probably be fixed.
Perhaps we should have a more user-friendly front-end for submitting
terminology bugs? (bugzilla may be too complex for the general population)

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

I agree that this principle needs some tweaking.
My interpretation: the software should not make decisions for the user
unless it is obvious that the user wants the software to make that
decision. For example, LibreOffice should not automatically set itself as
the default office suite -- it should ask the user first. On the other
hand, it should go with memory defaults, as the user is unlikely to want to
set those first.

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

We should define "minimalism" as reducing complexity. Using animations or
adding color to a UI can reduce its complexity.
"No shadows" and "no gradients" sounds good to me -- it works quite well
for Microsoft's Metro UI and, to a lesser extent, Android's Holo. In these
matters, though, the platform's HIG takes precedence. (That doesn't go
against the principle -- the most simple representation of a button is the
one used by the platform; otherwise it's not immediately apparent that it
is a button and takes longer for the user to interpret, thereby adding to
the UI's complexity.)

Yes, the interpretation of this principle can be a bit subjective, but it's
not as dire as it sounds. By simply presenting reasons for why a UI element
is necessary/unnecessary, you can easily reach a logical conclusion.

> => 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?

I beg to differ -- I believe most of our subjectivity issues can be solved
by simple logic.
We'll adjust our principles as we find issues.

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

This is something that we need to address with the principles. An equal
weight has to be given to all of them and they shouldn't go against each
other.

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


I'll quote Einstein here:
"It can scarcely be denied that the supreme goal of all theory is to make
the irreducible basic elements as simple and as few as possible without
having to surrender the adequate representation of a single datum of
experience."


> Will
> take on the ball about user research (and the rest of your mail) next days.

Great! I'm looking forward to it.

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