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


Hi everyone,
We have a list of principles [1] for justifying our design decisions.
However, not all of the principles have precise definitions, which could
lead to trouble down the road.

Take a look at ux-control: "Users should always feel like they are in
control of their software."
While the intention is good, it opens the door to arguments like "I won't
feel in control of LibreOffice if I can't change the toolbar background,"
which are very hard to argue against, since you can't disprove what the
person's feeling. These arguments ultimately result in feature creep, so
it's something we should avoid.
Rather than basing the definition on any user's feelings, how about saying
that the user doesn't feel in control when the software automates against
his will. That's a bit more precise and weeds out the above feature creep,
but still leaves the interpretation of the user's will open.
We could go further and define "acting against the user's will" as
something that a) hurts the user (e.g. sends personal/sensitive data online
without asking) or b) prevents him from carrying out a task that fits under
the scope of the software. (I originally added in "hurts his data", but
that's covered under "error prevention".)

ux-consistency: "Software should be internally consistent with itself and
externally consistent with similar interfaces to leverage the user's
existing knowledge."
Again, it sounds good, but it can be used to justify copying usability
mistakes of other software and thus can go against some of the other
principles. Tacking on "unless this would be detrimental usability"
remedies that, but it's a shortcut that doesn't really say much.
How about saying that software should be consistent unless this breaks any
of the other principle? An exception would be if an element that breaks one
of our principles is used consistently throughout a desktop. For
example, Windows 8's toolbars and sidebars go against ux-discoverability,
but we can rely on the user knowing how to use these bars, because
otherwise he wouldn't be able to use any of the core applications that come
with Windows 8.
How about we add a clause, then, for elements of a desktop that break our
principles, but the knowledge of which is required for the usage of that
desktop's core applications?
What would be the best way to reword the principle?

[1] http://wiki.documentfoundation.org/Design/Principles

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