Re: [libreoffice-design] Design ethos

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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


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.

Have a good night, everyone!

Cheers,
Christoph


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