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

Hi Christoph,

On Sun, Jun 10, 2012 at 11:34 PM, Christoph Noack <christoph@dogmatux.com>wrote:


Hi Mirek, all!

Thanks for your quick response! It's already a bit late, but I'd like to
answer now - tomorrow, I suppose, my day job will eat up all the given
time ;-)

Before I start: The more often I read your mail, the more I'm convinced
that some of the potential misunderstandings are caused by differences
in terminology (read: same terms mean different things to us) and
procedure with regard to HMI development. So please allow me to add some
more "my-point-of-view" ...

Am Sonntag, den 10.06.2012, 19:53 +0200 schrieb Mirek M.:

Hi Christoph,

On Sun, Jun 10, 2012 at 2:38 PM, Christoph Noack <christoph@dogmatux.com
wrote:


Hi Björn, hi Mirek!

I had to make up my mind concerning this thread and also the article
that was originally referred to. So here is what I'm thinking about ...

Am Mittwoch, den 06.06.2012, 20:45 +0200 schrieb Björn Balazs:

Am Mittwoch, 6. Juni 2012, 19:46:09 schrieb Mirek M.:

[...]

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


I understand it the same way - and I found another thing a bit strange.
The article is called "Quantifying Usability" although it deals with
"heuristic evaluations". The aim of those evaluations is usually to
detect interaction design issues - but not to let users rate / quantify
those issues (having statistically relevant information). So, where is
the "quantification"?

In the given case, interaction experts (not users) do tag the issues
using their level of experience and (domain) knowledge. So finally, you
can generate a nice statistic of known issues within your system -

maybe

that also helps within the project to address the most important (here:
highest number) of issues in advance.

But that doesn't solve the issue what it really means if a dialog
violates e.g. "ux-minimalism" - you need to know the users
characteristics and their tasks. So for a complex product like
LibreOffice (assuming that its okay that it supports a variety of
tasks), some users may find a dialog overwhelming whilst other users

may

miss lots of information. The question is - which main target group

will

make use of this dialog ...



The minimalism principle states that "interfaces should be as simple as
possible", where "simple" is meant as not complicated, not as "as
featureless as possible".


That sounds great, indeed. But when designing products one is usually
faced to the problem that it's impossible to add (meaningful) features
without any increase of the complexity of the product. Although one user
group want to have these features (because it boosts their efficiency),
other users might find the resulting user interface "not simple".

So, as Bjoern already pointed out, balancing what's "simple" and what is
"not featureless" requires a deep understanding of our users' needs. And
these needs vary a lot ... depending on their knowledge and their tasks.

I've documented a related issue some years ago (Myths about UX):

http://wiki.services.openoffice.org/wiki/User_Experience/Myths_about_UX#Advanced_functionality_doesn.27t_hurt_-_newcomers_just_won.27t_use_it.21


As an example, compare Firefox's separate search box and address bar and
Chrome's omnibox. In Firefox, you can search using both the address bar

and

the omnibox, which is unnecessary redundancy. In this case, Chrome is

more

minimalistic, yet it doesn't skimp on any features found within Firefox.


It does sound like Chrome is superior to Firefox, right?

But how do we know that the Chrome decision is the right one? Maybe ...
     * Maybe the majority of people expects to have a separate search
       field - like in other programs, too (Adobe Acrobat).



User expectations should be covered by ux-affordance
and ux-discovery (relevant visual cues), ux-visual-hierarchy (visual
weight), ux-natural-mapping, and, if it doesn't hurt the usability of the
software, ux-consistency.

     * Or user tests showed that people are unable to discover the

       search functionality - so they always enter "www.google.com" and
       then start searching. (So ux-minimalism hurts ux-discovery as
       also Mr. Nielson points out in the article you've referred to).



ux-discovery asks for visual cues, which Chrome includes (the "Search"
spyglass symbol) and Firefox neglects to.
ux-minimalism asks to avoid unnecessary duplication, which Chrome's omnibar
follows and Firefox's address bar doesn't (as it has two UI elements that
can be used for searching the web, presented next to each other).
ux-minimalism doesn't hurt ux-discovery -- on the contrary, they work hand
in hand.



     * Maybe the Firefox decision is an intermediate solution until
       they could "convert" all users to use only the Awesome Bar for
       all web related tasks.



Wouldn't the best tactic for converting users to use only this bar for
searching be presenting this bar as the one and only place for searching?





I can provide further guesses, but the basic message is - defining

whether the goal of "ux-minimalism" is achieved needs to consider real
user needs.



Yes, we should always consider user needs and test our designs.
However, the principle that UIs should not be duplicative still stands: if
there are several GUIs for accomplishing the same task, we should always
ask ourselves if we can't boil it down to one.



Chrome has a huge advantage here - these guys aren't market leaders, so
doing experiments with regard to HMI design and features is much easier
to them (I suppose a majority of users are "early adopters").



According to Statcounter, Chrome is the most popular browser in the world.
IE has also not been afraid to radically change its UI.




So yes, these characteristics might guide us - but you cannot apply
these to serve as strict rules.



I take a scientific approach to this issue. Just like with any branch of
science, it must be possible to define clear, logical principles for UI
design, and it's certainly worth the effort to try. Yes, different users
have different needs, but with good principles, that can be taken into
account as well. We also need to separate "needs" from
"wishes"/"preferences" -- a feature is needed in a piece of software when
its lack would significantly impair the usability of the software. The
usability of the software should be measured according to its primary
purpose.

For example, giving the user the option to choose Writer's Splash screen

is

a preference, since the lack of this option would not impair the user's
ability to create documents, which is Writer's primary purpose.


Concerning the last statement - yes, but who defines the primary
purpose? What is a document? Should Writer offer the user to add basic
shapes, or should they insert them via Draw? Should Writer offer simple
calculations in tables - or should these be copied from Calc? These
features could be removed without affecting the primary purpose. But
this wouldn't be tolerated by a large part of the user base - so their
input tells us what they need. The statements in the original UX article
don't help here.



You could argue that Writer doesn't need to allow the user to type. The
user could simply type the content in a text editor and then just paste it
to the document.
If we say that the primary purpose of Writer is to create (all kinds of)
documents, then Writer should be able to handle all of the tasks associated
with it, including text entry, shape drawing, and table manipulation.
Removing shape drawing would certainly hurt the user's ability of creating
the document he wants to create. Removing the option to set the icon pack,
on the other hand, wouldn't (as long as we support an additional HC pack,
which some users really do need). The user would be able to create the
document he wants no matter what icon pack he used (as long as the pack
used symbolism that corresponded to the function, of course).



Looking at the full section, it seems that two things are combined that
should (in my point-of-view) be considered separately to make
discussions a bit easier. A most simple take ...
     * in the first step, the functionality of the software is defined
     * in the next step, these features are brought to live via the
       user interface

So it is about "what" (the theoretical usefulness) and "how" (usability,
the ease-of-use).

As far as I understand, the article you've mentioned rather refers to
the "how". Drastically said it does not mention whether a piece of
functionality makes sense. This is the "what" - you seem to refer to by
mentioning "features".



Yes.



So, could you give me a hint, what you want to get covered?



I'll try my best at formulating my answer, but I may amend it later on if I
think of something more fitting.
What do I want covered in Writer?
Well, everything needed for editing a document (i.e. a "DOC", "ODT",
"DOCX", or "PDF" file, containing text, tables, shapes, images, and/or
other objects, with this content separated into 2D pages with a finite
width and height) -- that means editing tools for all the supported
objects, features that allow all populations to use the software (language
support, accessibility options, various input types), grammar checking (the
quality of the document would be worse off without it), navigation/search,
import/export of as many document filetypes as possible, and the simplest
visual representation of these within the interface.
Then there are features that may significantly speed up document
creation/editing for specific purposes, such as templates and wizards.
Given that there is an infinite amount of situations these could be
tailored to, it makes no sense to bundle as many as possible, and therefore
the software should integrate with an online repository of these as well.
Templates/wizards that are useful in a variety of situations may get
bundled by default as long as there is net benefit and and it does not have
a significant toll on the software's usability.

Almost forgot about privacy features: a piece of software should always
allow for the greatest security/privacy of the user, and, if a feature
requires private information, the user needs to be given an express choice
of whether to allow or disable the feature (that's part of "ux-control").




Wishes are best handled by extensions.


Yes - with one exception. Wishes are sometimes immensely important for
providing unique selling points (although selling sounds strange for
FLOSS software, its about given people a reason to choose your
product).



If a feature is presented as an extension rather than a core part of the
product, it is still a selling point.
I also can't think of a major selling point for a document editor that
would be a "wish" rather than a need.



For example: One of the killer features (still) is the "One click PDF
export". Thats just a combination of other features and not part of the
"main purpose" - but something that helped to spread news about
OOo/LibO.



PDF export is part of the main purpose, PDF being one of the most popular
document formats in the world.



The issue: One rarely knows in advance what's considered a killer
feature ;-)

[... snip ...]


Some examples:
     * Given equal tasks - do we aim for consistency within the
       different LibreOffice applications, or do we want to optimize it
       for each application (affects: suitability for learning and self
       descriptiveness VS. suitability for the task)
       Example: drawing behavior



I don't quite understand this example. Doesn't drawing behavior concern

the

same task, have the same purpose, no matter what LibreOffice module the
user is in?


Being able to do drawings is the "what" - the realization affecting its
behavior the "how". Writer handles drawing shapes differently from Draw.
And Draw starts to become different to Impress. Why? Because the main
task of Impress is creating presentations (usually based on existing
material) - it may contain "drawing elements". Draw is primarily used
for doing the drawings.




So its basically the same task, but sometimes less frequently done than
other features are used. This is reflected in the "how".

Again, I don't see how this effects the behavior of a feature. An ellipse

drawing tool should work the same way in all applications, in a way that
makes drawing the ellipse most simple, no matter how frequently the tool is
used.
Could you give me a specific example of how the drawing behavior of Draw
and Writer differ, and how it is more beneficial than if the behavior was
the same?


I can't think of a specific situation in which having a UI suited to the

task would neccessarily be at odds with suitability for learning and self
descriptiveness.


Simple example? Compare the comment visualization in Writer, Calc and
Impress:
     * Writer = comment anchors and boxes
     * Calc = small red dots in the upper right of each cell, notes
       boxes hidden
     * Impress = small rectangle with the author's abbreviation, notes
       boxes hidden

Although all solutions do have their downsides, the basic design shows
the impact by the application's main purpose. Example Calc: Few space in
the cell, so the note content cannot be shown directly. Its also
impossible to show the notes on one side (like in Writer), because
showing the referenced cell (given the huge cell matrix) is not easily
done. Its also unwanted to show the notes next to the cell, since you'll
hide other cells.

The same "what", three different "hows".



Ok, thanks for the example.
In such cases, we should, of course, use logic to deduce the most
reasonable option.
I can't escape the feeling, though, that the comment behavior could be more
unified, but that's a whole other topic.




     * Given the fact of different platforms - do we want to have
       consistency across the platforms or do we want to comply to the
       platform (e.g. Human Interaction Guidelines). The former makes
       LibreOffice very predictable, although it might not fit to the
       platform. The latter heavily affects "suitability for learning"
       and - of course - design and development effort.
       Example: When (re-)designing, do we address: Linux (most
       developers), or Windows (major user base when looking at
       OOo/AOO/LibO), or Android (emerging market), or ...



This isn't a simple question of following the HIG, given that HIGs for

some

desktop environments are less than ideal (and sometimes a bit outdated),
which is evidenced by Microsoft and increasingly even Apple not following
its own guidelines. This is something we need to address with our own

HIG.

Although I also think that some HIGs are strange (Microsoft for example
recently mixed all Office and Windows Desktop stuff into one), but
sometimes you have to "mis-interpret" your own HIGs to get the best
compromise (= the best solution). An own HIG won't change that.

I disagree. You should never have to "misinterpret" your own HIG. If you

have to resort to that, then you have a badly-written HIG and you should
rewrite it.



 > >      * Given the fact of major competitors - do we want to adapt the

       LibreOffice behavior with regard to competitors? Today, many
       users / organizations want to switch to a free (costless)
       alternative without having (much) learning effort.
       Example: Some of Calc's good and consistent behavior is
       currently changed to conform to Excel's behavior (e.g.
       copy-and-paste behavior). That makes new users happy, but is
       problematic for today's users.

It's preferential to design for the best usability. If there are two

options that we determine are the most usable, both conform equally
perfectly to our principles and are equally logical, then it is
preferential to have consistent behavior with the competitor.
Otherwise, no, we shouldn't impair usability because a competitor impairs
usability.
If we choose the more usable option, it is likely that the competitor

will

copy us. Just look at how all the browsers have aped Chrome since it came
out.


Here is the paradox - do it all the own way, and you might loose a lot
of potential users before they start using the software at all. Although
usability might be better, but lots of stuff is different - and things
people like least are different things.



On the contrary.
The most exciting software tends to be different from the rest of the pack,
and the key to this differentiation is increased usability. Apple's iPhone
revolutionized the smartphone market by making smartphones much more usable
-- Windows Phone smartphones were on the market for ages, but they suffered
from a poor UI. The same with the iPad -- tablet PCs existed for a long
time before it came, yet they weren't as suited to the input mechanism.
When Chrome launched, it differentiated itself from other browsers mainly
by its increased usability, and it quickly became one of the most popular
browsers in the world while its competitors scrambled to copy the
improvements.
The least exciting software just copies its competitors with all their
faults and fails to innovate on its own.



So maybe the option (which is just another proposal having pro's and
con's) is to primarily decide for "best usability" for our own users,
but provide adaptations for a smooth transition of other users /
organizations / governments. For example, providing a shortcut switcher
to mimic MS Office, ...



Using keyboard shortcuts common in other software makes sense. Having our
own set of shortcuts wouldn't have any usability advantages for any user
base and would decrease usability for users coming from other software.
That doesn't conflict with putting usability first.

Software that puts "smooth transitioning" above usability tends to be stuck
behind the competitor -- it adopts all of the competitor's usability faults
and has some faults and deficiencies of its own, which are that much
clearer when the product can so easily be compared to the competitor.



But whatever we do - it needs to be a sane / transparent decision that
takes our whole (growing) user base into account.



Of course.



Phew, lots of thoughts ... but I hope it helped a bit to understand my
position. I hope that we can continue discussing the feasibility of the
(quoting you) "clear, logical principles for UI" we're aiming for.



Yes, I hope so. It should say "clear, logical principles for UI design",
though.

Understand that in no way am I saying that what we have is perfect -- there
is some vagueness and unclarity in the principles at
https://wiki.documentfoundation.org/Design/Ethos , but I feel like it would
be silly to throw out the baby with the bath water, reject the notion that
UI design could ever be logically formulated if what we have now isn't
perfect. No area of science is perfect, but we're continually striving to
boil down our knowledge into the most basic logical principles we can.

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