Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.