Design ethos

> Hi everyone,
> Could we agree to use the Firefox UX principles [1] as the basis for our
> design ethos?
> I'd like to get this approved on the upcoming IRC chat.
> If you have any issues with it, please speak up.
>
> [1] http://uxmag.com/articles/quantifying-usability
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> 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
>
>

> On Wed, Jun 6, 2012 at 6:50 PM, Björn Balazs <[hidden email]> 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 see a possible solution - and hey, surprise - this again has to do with
> > researching and understanding users: I think we should try to define
> > conditions user under which certain rules apply. Conditions could be
> > something
> > like "If the user is likely to be in a stressful situation, prefer to the
> > use
> > of a wizard"
> >
> > As I stated before, I'm a bit hesitant about user research -- not because
>
> I don't believe it can't be useful, but because we have to be careful to do
> it correctly, as otherwise it can be quite detrimental to our design. If
> done badly, user research can be used to justify just about any design.
>
> I continue researching user design. Windows seems to do a lot of it [1],
> but I'm not sure how much it helps them, given that they're dropping
> everything they know for Metro, which firmly stands against the overcrowded
> ribbons their research has gained them. Mozilla seems to first design, then
> test, much like we do now, but then it has some guidelines that help it
> shape its design [2]. elementary does some basic user research (if it can
> be called that) on Google+ [3]. Gnome design team doesn't do any, which is
> a bit surprising, as, IMHO, that's one of the best open-source design
> communities out there.
>
> I would definitely be interested to hear about your own personal experience
> with user research and how it has lead to design decisions (with concrete
> examples, if possible).
>
> Plus every open-source project that cares about design listens to its
> users, of course, and the advantage of open development is that people can
> see the changes before the product is released, so design bugs can be
> caught before release. We've seen this just recently, with two people
> reaching out to us, one on G+ and one on the IRC, complaining about the
> usability of the new About dialog, which Astron has fixed.
>
> This is just my experience, perhaps I did misunderstand your intention here.
> > What do you think?
>
> I feel like Mozilla's design principles have worked for them and that they
> would be a good starting point for our own principles.
> As for user research, I see it as a means to an end. It's definitely
> something that will help us refine our principles and form our HIG, but we
> should be careful, as user research can be quite misleading. We should
> ensure that our principles and our HIG can be followed under all
> circumstances -- exceptions should never be the rule.
>
> [1] http://www.youtube.com/watch?v=532j9sfBcbQ
> [2] https://www.youtube.com/watch?v=hMDBwa4huUY&feature=player_embedded
> [3] https://plus.google.com/114635553671833442612/posts

> 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 Wed, Jun 6, 2012 at 6:50 PM, Björn Balazs <[hidden email]> 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)
>

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

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

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

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

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

> "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 Wed, Jun 6, 2012 at 6:50 PM, Björn Balazs <[hidden email]> 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?

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

> 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 <[hidden email]> 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.
>
> It's preferential to design for the best usability. If there are two

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

> Hi Christoph,
>
> On Sun, Jun 10, 2012 at 2:38 PM, Christoph Noack <[hidden email]>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".

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

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

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

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

> 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 <[hidden email]
> >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).

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

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

> > 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.
>
> I disagree. You should never have to "misinterpret" your own HIG. If you

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

> > 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 <[hidden email]
> > >
> > >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#Ad
> > vanced_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.

> Hi Björn, Mirek, all!
>
> Am Dienstag, den 12.06.2012, 15:34 +0200 schrieb Björn Balazs:
> > Hi all,
> >
> > thanks for picking up this really important discussion. Christoph I
> think the
> > examples you gave are really great.
> >
> > I think we really should ask ourselves: "What is the problem? What do we
> want
> > to reach?" instead of generally argueing for or against the suggested
> (and
> > obviously proven) approach from Mozilla.
>
> Yes, thanks for the reminder ... and thanks for the pre-formulated
> proposals.
>
> > I think there have been two possible goals deriving out of this
> discussion so
> > far:
> >
> > 1. Educate developers in terms of making them aware of the importance of
> > Usability / UX
>
> >From my experience during the last months, this is less needed at the
> moment. Why? To me ...
>      * the core developers do ping us regularly
>      * they provide means to basically follow their development (e.g.
>        daily builds, commit messages, ... provided for QA, Design and
>        others)
>      * the suggest new developers to get our feedback on their ideas
>
> So, unless we are able to handle _all_ their requests quite fast and
> accurately, there is no need to further promote this topic. Instead, we
> should try to answer all the (open) requests on e.g. the ux-advise list
> - or help with classifying / resolving Design related bugzilla issues. I
> mean ... before asking for more requests we might not be able to handle
> properly.
>
> (Well, I know that I've missed to invest time there as well.)
>
> > 2. Provide a structure to us designers to produce consitent UIs and
> workflows.
>
> That is the one I'd focus on (referring to the "consistent UI") ... and
> there is plenty to do.
>
> Any other opinions?
>

> > > I think we really should ask ourselves: "What is the problem? What do we
> > want
> > > to reach?" instead of generally argueing for or against the suggested
> > (and
> > > obviously proven) approach from Mozilla.
> >
> > Yes, thanks for the reminder ... and thanks for the pre-formulated
> > proposals.
> >
> > > I think there have been two possible goals deriving out of this
> > discussion so
> > > far:
> > >
> > > 1. Educate developers in terms of making them aware of the importance of
> > > Usability / UX
> >
> > >From my experience during the last months, this is less needed at the
> > moment. Why? To me ...
> >      * the core developers do ping us regularly
> >      * they provide means to basically follow their development (e.g.
> >        daily builds, commit messages, ... provided for QA, Design and
> >        others)
> >      * the suggest new developers to get our feedback on their ideas
> >
> > So, unless we are able to handle _all_ their requests quite fast and
> > accurately, there is no need to further promote this topic. Instead, we
> > should try to answer all the (open) requests on e.g. the ux-advise list
> > - or help with classifying / resolving Design related bugzilla issues. I
> > mean ... before asking for more requests we might not be able to handle
> > properly.
> >
> > (Well, I know that I've missed to invest time there as well.)
> >
> > > 2. Provide a structure to us designers to produce consitent UIs and
> > workflows.
> >
> > That is the one I'd focus on (referring to the "consistent UI") ... and
> > there is plenty to do.
> >
> > Any other opinions?
> >
>
> I mostly agree with this.
> However, the point of the principles is not only to produce consistent UIs
> and workflows, but also to be able to evaluate and improve upon our designs
> using a standard set of guidelines.
> If we discover faults or unnecessary vagueness within the principles, which
> we no doubt will, we should adjust the principles accordingly.