Design ethos

classic Classic list List threaded Threaded
15 messages Options
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

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

Björn Balazs Björn Balazs
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

Mirek, all,

thanks for pointing to this interesting article. I tried to find out what you
mean by 'design ethos' and found a mail [1] from you from that started the
topic and the wikipage you created [2].

Unfortunately I think I do not really understand the goal you want to achieve.
For my understanding it is extremely hard to define general design guidelines.

I pick two examples you provide:

I can agree to "Polished - every little thing counts" - no doubt about that.
But that is very general... What does apply for a design from that? How can I
evaluate a design on this?

In opposite "Contextual - [...] Don't show actions that the user can't take
[...]" is at least ambivalent. True: never show stupid or misleading options.
Wrong: never hide e.g. menu elements simply because they are not applicable at
the moment (remember those attempts in M$ Office? Horrible times!)

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.

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"

This is just my experience, perhaps I did misunderstand your intention here.
What do you think?

Cheers,
Björn



[1] http://listarchives.libreoffice.org/global/design/msg04372.html
[2] https://wiki.documentfoundation.org/Design/Ethos

Am Mittwoch, 6. Juni 2012, 17:49:19 schrieb Mirek M.:
> 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
--
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

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

Kévin PEIGNOT-3 Kévin PEIGNOT-3
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

In reply to this post by mirek2
Hi all

Quick speach to say it seems me a good idea. I'm sorry I don't have time to
say more these weeks but I think they are  good principles.

Kévin

2012/6/6 Mirek M. <[hidden email]>

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

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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

In reply to this post by Björn Balazs
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.

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

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

Björn Balazs Björn Balazs
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

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. But you could also stretch this rule further: It
should actually say, use an appropriate language, because if you use any word
(not only implementation level terminology) that users do not understand, they
are lost. But what is this level? Answer can only be given by research.


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


=> If you consider all the "nemesises" mentioned in the rules you can easily
see, that you can never apply all rules. So when do you turn to which side?

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.

Have to go now, but I hope I made my point a bit clearer. I really appreaceate
all efforts to make the design of LO consistent and good in terms of UX. But
we should be aware of the trap of simplifing complicated things too much. Will
take on the ball about user research (and the rest of your mail) next days.

Thanks again for your efforts!

Björn


> > 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
--
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

Hi Björn,

On Wed, Jun 6, 2012 at 8:45 PM, Björn Balazs <[hidden email]> wrote:

> 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 the contrary. These are simple principles that should guide all designs,
whether they come from developers or designers, and would be the basis
under which all designs would be judged. (Much like basic arithmetic is
applicable for both first-graders and adult mathematicians.)
On top of these principles, though, we'd have a HIG for specific
situations, such as desktop integration (e.g. requiring a "Close" button on
dialogs, as Gnome 3 and Mac OS feature modal dialogs without title bars).

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

Easy. The "Save" icon should be active if there is anything to save and
inactive if there is nothing to save. As we have determined that it is
useful to be able to save view settings, the "Save" icon should become
active even if only the view settings change. (I don't think it makes sense
to disable the icon if we think saving view settings is genuinely
useful.) And, in that respect, the Save icon would indicate saved status,
as it is meant to.

If we also want to indicate whether the document's contents were edited
(above the dialog that asks the user whether he'd like to save the edits he
made to the document, which doesn't apply to view options), we could have a
special "Save view edits" icon for when only view options were edited and
contents were left intact.

(I'll post this to that thread now.)

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

I agree that the wording of this one is confusing. As I understand it, the
UI shouldn't be based on the underlying code in a way that's illogical to
the user.
You can see the relevant bugs at
https://mevootserv.appspot.com/bugzilla.mozilla.org/buglist.cgi?keywords=ux-implementation-level
For example, if you take
https://mevootserv.appspot.com/bugzilla.mozilla.org/show_bug.cgi?id=615306,
the behavior of the back button is based on some code that tells the
browser to go back to the previous site, which isn't always friendly to the
user, as it doesn't take into account redirects which take the user right
back to the site he was at -- something the user didn't want if he clicked
the back button.

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


It, of course, doesn't apply to UIs meant exclusively for experts that are
familiar with this jargon (so it is OK to have medical jargon in an
extension meant exclusively for doctors).
As I understood it, the main purpose of the principles was to avoid showing
pieces of the software's code in the interface (such as with those
stereotypical unhelpful error messages), though the interpretation has been
clearly extended to use of language in general (
https://mevootserv.appspot.com/bugzilla.mozilla.org/buglist.cgi?keywords=ux-jargon
).

But you could also stretch this rule further: It
> should actually say, use an appropriate language, because if you use any
> word
> (not only implementation level terminology) that users do not understand,
> they
> are lost. But what is this level? Answer can only be given by research.


What would this research look like?
To be honest, when it comes to generic language, I believe that if a user
cares enough to report a bug about it, then it should probably be fixed.
Perhaps we should have a more user-friendly front-end for submitting
terminology bugs? (bugzilla may be too complex for the general population)

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

I agree that this principle needs some tweaking.
My interpretation: the software should not make decisions for the user
unless it is obvious that the user wants the software to make that
decision. For example, LibreOffice should not automatically set itself as
the default office suite -- it should ask the user first. On the other
hand, it should go with memory defaults, as the user is unlikely to want to
set those first.

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

We should define "minimalism" as reducing complexity. Using animations or
adding color to a UI can reduce its complexity.
"No shadows" and "no gradients" sounds good to me -- it works quite well
for Microsoft's Metro UI and, to a lesser extent, Android's Holo. In these
matters, though, the platform's HIG takes precedence. (That doesn't go
against the principle -- the most simple representation of a button is the
one used by the platform; otherwise it's not immediately apparent that it
is a button and takes longer for the user to interpret, thereby adding to
the UI's complexity.)

Yes, the interpretation of this principle can be a bit subjective, but it's
not as dire as it sounds. By simply presenting reasons for why a UI element
is necessary/unnecessary, you can easily reach a logical conclusion.

>
> => If you consider all the "nemesises" mentioned in the rules you can
> easily
> see, that you can never apply all rules. So when do you turn to which side?
>

I beg to differ -- I believe most of our subjectivity issues can be solved
by simple logic.
We'll adjust our principles as we find issues.

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

This is something that we need to address with the principles. An equal
weight has to be given to all of them and they shouldn't go against each
other.

>
> Have to go now, but I hope I made my point a bit clearer. I really
> appreaceate
> all efforts to make the design of LO consistent and good in terms of UX.
> But
> we should be aware of the trap of simplifing complicated things too much.


I'll quote Einstein here:
"It can scarcely be denied that the supreme goal of all theory is to make
the irreducible basic elements as simple and as few as possible without
having to surrender the adequate representation of a single datum of
experience."


> Will
> take on the ball about user research (and the rest of your mail) next days.
>

Great! I'm looking forward to it.

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

Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

In reply to this post by Björn Balazs
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 <[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.
       
      * ...

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 [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
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

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

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

Wishes are best handled by extensions.

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

These are more vague than Mozilla's (especially the latter), and therefore
more subjective and less useful.
Mozilla's principles are based on the former.

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

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


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

     * ...

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

I'd still like to start with design principles, work from there. :)

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

Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[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).
      * 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 [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
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

Hi Christoph,

On Sun, Jun 10, 2012 at 11:34 PM, Christoph Noack <[hidden email]>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 <[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).


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

Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

Hi all,

just a quick note: the log for yesterday's meeting is now up
https://wiki.documentfoundation.org/Design/Meetings/2012-06-10
& we quickly touched upon the issues discussed here (see the parts
from 18:59–19:05 and 19:58–pretty much the end).

Also, I'm happy to announce that we might have hit another record
length for our chats...

Astron.

--
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
Björn Balazs Björn Balazs
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

In reply to this post by mirek2
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.

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

2. Provide a structure to us designers to produce consitent UIs and workflows.

Am I right with these two possible goals? Would you like to add any?

Cheers,
Björn


Am Montag, 11. Juni 2012, 17:55:34 schrieb Mirek M.:
> Hi Christoph,
>
> On Sun, Jun 10, 2012 at 11:34 PM, Christoph Noack
<[hidden email]>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 <[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.
--
www.OpenUsability.org
www.OpenSource-Usability-Labs.com

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

Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

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?

Cheers,
Christoph


--
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
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

Hi everyone,

On Wed, Jun 13, 2012 at 11:40 PM, Christoph Noack <[hidden email]>wrote:

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

I hope that it's alright if I integrate the principles into our workflow
(with a simple "Designs will be checked against our design principles."
line).

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

Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

Re: Design ethos

Hi Mirek, all!

Am Donnerstag, den 14.06.2012, 00:06 +0200 schrieb Mirek M.:
> On Wed, Jun 13, 2012 at 11:40 PM, Christoph Noack <[hidden email]>wrote:
> > Am Dienstag, den 12.06.2012, 15:34 +0200 schrieb Björn Balazs:
...

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

I do fully agree.

To me, the most important part is to consider that all the principles
are valid at the same time - although being sometimes contradictory. So
the actual design problem "varies" the importance / influence of each of
the principles. Consequently, these aren't strict rules, but ... as you
said ... guidelines.

> I hope that it's alright if I integrate the principles into our workflow
> (with a simple "Designs will be checked against our design principles."
> line).

I'm basically fine with it - how about "Design proposals will be
evaluated according our design principles."

More proposals ...

How about renaming the "Ethos" page [1] to "Design Principles" (seems
simpler to me, since the page itself talks about principles).

And, I'm not sure if we really need the tags. How about renaming them to
make them more "human readable" (e.g. "ux-discovery" -> "Discovery
Principle").

(If you give me a "go", then I'll update the page accordingly".


Are there additional thoughts with regard to Björn's question?


Thanks to you both for this first step ...

Cheers,
Christoph

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


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