Re: [libreoffice-design] Design ethos

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

So yes, these characteristics might guide us - but you cannot apply
these to serve as strict rules. You may see this in other places as
well, e.g.:
a) Ten Usability Heuristics
http://www.useit.com/papers/heuristic/heuristic_list.html

b) ISO 9241-110 Dialogue Principles
http://en.wikipedia.org/wiki/ISO_9241#ISO_9241-110

By the way, the linked descriptions fit a bit better from my
point-of-view.

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

I'm keeping the text above, since it fits quite well to my answer ...

[...]

But since we talked about principles - there are some other open
questions. Answering these questions might (at the very moment) help a
lot to provide a consistent experience to our users.

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

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

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

To me, these are the more urgent issues - although none of the questions
can answered "black or white". But answering those (and some answers
might need real user or marketing involvement) would shape the
(currently unnecessary huge) design space ...

By the way, some similar questions documented here:
http://wiki.documentfoundation.org/Design/Kick-Off/WhatWeNeed#Knowledge_and_Requirements


What do you think - where to start?

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