Please - DON'T use long descriptive texts on buttons

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Please - DON'T use long descriptive texts on buttons

André Schnabel
Hi and sorry for crossposting ...

the issue happnes with almost every release and it is really a pain for
localization teams (causes us to file issues, needs rework of Ui at a
very late time and causes discussions when we are close to a release).
After all ..it is annoying for everione of us.

What's the issue? Descriptive texts on command buttons.
At the moment I have this in sfx2/source/doc/doc.src

If a document is loaded which is based on a template, for which the
styles have changed, the information "The template '$(ARG1)' on which
this document is based, has been modified. Do you want to update style
based formattings according to the modified template?" is given.

The buttons then are:
"Update styles" and "Keep old styles". This would (correctly) translate to
"Formatvorlagen aktualisieren" and "Alte Formatvorlagen beibehalten"
(slighly more text than in english - and will produce quite ugly UI).

So - why have these strings been choosen, even if a simple "Yes" and
"No" would have perfectly done the job?

If you think, the issue is not that important - I know some companies
who have a very simple method to teach a developer, how important that  
is. Each developer who introduces such strings (and each UX member who
accepts such a change) should donate 5 EUR to the project + 1 EUR for
each localization team that cannot correctly translate such strings.


Btw - the same thing happens on all UI elements. But Buttons are more
sensitive, as for labels and other stuff, we normaly have more space -
but not for Buttons.

André


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
Hi André,

I understand your concern, but I don't think that setting a "don't  
put long descriptive texts on buttons" law (or design principle) is a  
good solution.

I think that the origin of the issue is a lack of communication  
between the contributors. For the example that you give, I remember  
that the wording has been discussed in the UX discussion mailing list:

http://ux.openoffice.org/servlets/ReadMsg?listName=discuss&msgNo=1197

[Unfortunately, the wording finally accepted (including buttons  
labels) has not been discussed here (I have a lot to say about it.)]

In the aforementioned thread you can see that we explain why (we  
think that) such wording is better than another. These informations  
could be useful for translators, but are lost in the process. On the  
other hand, if translators were involved in the discussion, they  
could warn us about the kind of issues you talked about.

When the change is subject to a specification, there are in the iTeam  
members of the UX team and translators, so the communication is OK.  
Unfortunately every change in the UI does not necessitate such an  
iTeam. I don't know well the process of accepting patches for issues,  
but maybe we could require that every modification of the UI strings  
is accepted by a translator?

Le 18 janv. 09 à 13:08, André Schnabel a écrit :

> So - why have these strings been choosen, even if a simple "Yes"  
> and "No" would have perfectly done the job?

Because "Yes" and "No" would not have perfectly done the job. This is  
a well known issue in the UX field: people tend not to read the  
description of a warning and rather focus on the buttons labels,  
which should be as self-describing than possible. With a "Yes/No"  
solution, the user will 1/ Read the dialog title, 2/ read the buttons  
labels 3/ Realize that he does not understand the warning and can not  
select an action among the proposed ones, 4/ read the description of  
the warning, and finally 5/ choose a button to click. With well  
labeled buttons, steps 3/ and 4/ can be avoided in most cases.

> If you think, the issue is not that important - I know some  
> companies who have a very simple method to teach a developer, how  
> important that is. Each developer who introduces such strings (and  
> each UX member who accepts such a change) should donate 5 EUR to  
> the project + 1 EUR for each localization team that cannot  
> correctly translate such strings.

This is a "punish bad behavior" solution. I prefer solutions trying  
to detect sub-efficient processes and reorganize it, taking into  
account each actor's ability and interest.

> Btw - the same thing happens on all UI elements. But Buttons are  
> more sensitive, as for labels and other stuff, we normaly have more  
> space - but not for Buttons.

Best Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Christoph Noack
Hi André,

it seems that I will be one of the first who will donate ... for some
good reasons that Clément already talked about. By the way, I will keep
his complete answer, because it seems to be sent to ux-discuss only.

So please, scroll on... :-)

Am Sonntag, den 18.01.2009, 16:32 +0100 schrieb Clément Pillias:

> Hi André,
>
> I understand your concern, but I don't think that setting a "don't  
> put long descriptive texts on buttons" law (or design principle) is a  
> good solution.
>
> I think that the origin of the issue is a lack of communication  
> between the contributors. For the example that you give, I remember  
> that the wording has been discussed in the UX discussion mailing list:
>
> http://ux.openoffice.org/servlets/ReadMsg?listName=discuss&msgNo=1197
>
> [Unfortunately, the wording finally accepted (including buttons  
> labels) has not been discussed here (I have a lot to say about it.)]
>
> In the aforementioned thread you can see that we explain why (we  
> think that) such wording is better than another. These informations  
> could be useful for translators, but are lost in the process. On the  
> other hand, if translators were involved in the discussion, they  
> could warn us about the kind of issues you talked about.
>
> When the change is subject to a specification, there are in the iTeam  
> members of the UX team and translators, so the communication is OK.  
> Unfortunately every change in the UI does not necessitate such an  
> iTeam. I don't know well the process of accepting patches for issues,  
> but maybe we could require that every modification of the UI strings  
> is accepted by a translator?
>
> Le 18 janv. 09 à 13:08, André Schnabel a écrit :
>
> > So - why have these strings been choosen, even if a simple "Yes"  
> > and "No" would have perfectly done the job?
>
> Because "Yes" and "No" would not have perfectly done the job. This is  
> a well known issue in the UX field: people tend not to read the  
> description of a warning and rather focus on the buttons labels,  
> which should be as self-describing than possible. With a "Yes/No"  
> solution, the user will 1/ Read the dialog title, 2/ read the buttons  
> labels 3/ Realize that he does not understand the warning and can not  
> select an action among the proposed ones, 4/ read the description of  
> the warning, and finally 5/ choose a button to click. With well  
> labeled buttons, steps 3/ and 4/ can be avoided in most cases.

Clément explained the importance of clear button labels very well.

In the case of dialogs, we talk about efficiency (user understands what)
and error free decisions (user knows what to decide). This is both
related to efficiency and acceptance for a office productivity suite.

The problem is made worse as (to my current knowledge):
      * OOo is very (modal) dialog driven (!)
      * OOo doesn't provide structured dialogs (see [1] for an example)
      * OOo omits meaningful dialog titles (mostly $PRODUCTNAME)
      * OOo doesn't provide icons for standard buttons

Especially for alerts and information dialogs, each of the elements will
add distinctive shape which improves their recognizability.

> > If you think, the issue is not that important - I know some  
> > companies who have a very simple method to teach a developer, how  
> > important that is. Each developer who introduces such strings (and  
> > each UX member who accepts such a change) should donate 5 EUR to  
> > the project + 1 EUR for each localization team that cannot  
> > correctly translate such strings.
>
> This is a "punish bad behavior" solution. I prefer solutions trying  
> to detect sub-efficient processes and reorganize it, taking into  
> account each actor's ability and interest.

Maybe those companies do not provide products which should integrate
well on different platforms. Some of the platform HIGs (Human Interface
Guidelines) do require the use of "descriptive text" [2, 3]. In my
opinion, the HIG recommendations are rather related to usability than
the project's account balance ;-)

But what does "cannot translate such strings" mean? Is this related to
the lengths of the text, or it's ambiguous meaning?


> > Btw - the same thing happens on all UI elements. But Buttons are  
> > more sensitive, as for labels and other stuff, we normaly have more  
> > space - but not for Buttons.

The "have more space" seems like a rather technical issue to me. As far
as I know, OOo lacks a layout manager which automatically sets the size
for the dialog elements according their content.

So I think, there are the following options for a short-/mid-term
solution:

      * Use simple "one word button labels" as you proposed: This might
        only be a short term solution, as we tend to move the problem
        towards the end-user.

      * Provide "layout management" to size the dialogs automatically:
        This is the most technically challenging solution, but it will
        also solve many other problems (button order, ...)

      * Define different button widths in advance (e.g. 3) to cover most
        of the text lengths which may occur - a compromise. This could
        e.g. be documented in the dialog specification [4] (status
        unknown).

Okay, even the layout manager might not solve all problems at once. As
Clément already pointed out, it is essential to keep good cooperation
across all the participants.

André, I know that this mail only partially addresses the problems of
the NL teams, but I hope the ongoing decision will be backed up by some
more information from our side.

I'm looking forward to your answers.

Best regards,
Christoph


REFERENCES ------------------------------------------------------------

[1] Example for a well structured Alert-Dialog
http://library.gnome.org/devel/hig-book/stable/images/windows-alert-spacing.png.en

[2] Apple Human Interface Guidelines: Buttons
http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGControls/chapter_19_section_3.html#//apple_ref/doc/uid/TP30000359-TPXREF186

[3] Gnome Human Interface Guidelines: Alerts, Save Confirmation Alerts
http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#save-confirmation-alerts

[4] OOo Dialog specification (status unknown)
http://specs.openoffice.org/ui_in_general/dialogs/Dialogs.odt

--
Usability * Productivity * Enjoyment

OpenOffice.org User Experience Team
http://ux.openoffice.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

André Schnabel
Hi Christoph,

ok - you receive the answer that I already intented to write to Clemens,

Christoph Noack schrieb:
> it seems that I will be one of the first who will donate ... for some
> good reasons that Clément already talked about. By the way, I will keep
> his complete answer, because it seems to be sent to ux-discuss only.
>  
I'm still subscribed to the list (but I really wonder why for what
reason) ...

>> In the aforementioned thread you can see that we explain why (we  
>> think that) such wording is better than another. These informations  
>> could be useful for translators, but are lost in the process. On the  
>> other hand, if translators were involved in the discussion, they  
>> could warn us about the kind of issues you talked about.
>>    
This was the intention of my mail: a warning. All I received was
reasons, why UX team did the correct decision - but at no place there
was sometinglike "ok, we will consider your warning in our work". I fact
I feel ignored.

>> When the change is subject to a specification, there are in the iTeam  
>> members of the UX team and translators, so the communication is OK.  
>> Unfortunately every change in the UI does not necessitate such an  
>> iTeam. I don't know well the process of accepting patches for issues,  
>> but maybe we could require that every modification of the UI strings  
>> is accepted by a translator?
>>    
This is not practicable - we support > 100 translations. ~40
Translations are actively supported and try to keep up with the current
version of OOo. One translator cannot tell the effects for all
languages. There is only one common rule: try to keep messages short,
clear and consistent. Don't use senteces  or "multi word strings" where
they are not intended. Normally one single english word can be
translated to another single word of a given language. If you use
multiple words, you raise the complexity of translations dramatically,
as you now bring grammar in.
 

>>
>> Because "Yes" and "No" would not have perfectly done the job. This is  
>> a well known issue in the UX field: people tend not to read the  
>> description of a warning and rather focus on the buttons labels,  
>> which should be as self-describing than possible. With a "Yes/No"  
>> solution, the user will 1/ Read the dialog title, 2/ read the buttons  
>> labels 3/ Realize that he does not understand the warning and can not  
>> select an action among the proposed ones, 4/ read the description of  
>> the warning, and finally 5/ choose a button to click. With well  
>> labeled buttons, steps 3/ and 4/ can be avoided in most cases.
>>    
>
> Clément explained the importance of clear button labels very well.
>  

Imho plain theory and close to nonsense. Just reading "Keep old styles"
and "Update Styles" does not mean anything, as long as you do not read
the question.
E.g.: what styles? What are styles at all? Why should I update styles?
What styles would be updated (styles in my document, styles in the
template .. oh soory, I don#t know about templates at all).
So clicking the "complex text icons" is not much better than just
clicking "Yes" or "No".

You are right: user often don't read messages. But why? Because
meaningless messages pop up to often and the joices you can do have no  
visible effect (no matter what you choose).

> In the case of dialogs, we talk about efficiency (user understands what)
> and error free decisions (user knows what to decide). This is both
> related to efficiency and acceptance for a office productivity suite.
>  
as said above - If you would like to stick with the current ecample the
user would not understad what she is deciding about and therefore not be
able to choose the correct answer just by readin the button texts.

> The problem is made worse as (to my current knowledge):
>       * OOo is very (modal) dialog driven (!)
>  

Correct - please work on that in project renaissance but for the moment
this is a fact, that we need to accept. Esp. if we desing modal dialogs.

>       * OOo doesn't provide structured dialogs (see [1] for an example)
>  
What teh hell has this to do wit the lentgh of Button texts?


>       * OOo omits meaningful dialog titles (mostly $PRODUCTNAME)
I did not speak about dialog tiles here. If this was an issue with the
dialog that has been chande - this could have been changed within the
same issue.


>       * OOo doesn't provide icons for standard buttons
>  

As said above - pleas focus on that in renaissance. But for the moment
accept, what we have.

> Maybe those companies do not provide products which should integrate
> well on different platforms. Some of the platform HIGs (Human Interface
> Guidelines) do require the use of "descriptive text" [2, 3]. In my
> opinion, the HIG recommendations are rather related to usability than
> the project's account balance ;-)
>
> But what does "cannot translate such strings" mean? Is this related to
> the lengths of the text, or it's ambiguous meaning?
>
>  

Ok: please tell what buton you would like to click:
[Formatvorlagen a..] or [Alte Formatvorl...]
for non-german speaking people:
[...e Styles] or [...d Styles]


Would you get the meaning of the buttons, even if you read the according
question?

Without raising an stopper issue, l10n teams have almost no chance to
request the correct size of buttons or UI elements.

So no matter what HIGs suggest or what is written in tons of books -
descriptive texts will fail for many translations at the moment.
The only way for l10n teams is to ignore UX suggestions and shorten
translations.

>  
>>> Btw - the same thing happens on all UI elements. But Buttons are  
>>> more sensitive, as for labels and other stuff, we normaly have more  
>>> space - but not for Buttons.
>>>      
>
> The "have more space" seems like a rather technical issue to me. As far
> as I know, OOo lacks a layout manager which automatically sets the size
> for the dialog elements according their content.
>  

Correct ... but this is what we have. And please do not desing perfect
dialogs that cannot be implemented.


> So I think, there are the following options for a short-/mid-term
> solution:
>
>       * Use simple "one word button labels" as you proposed: This might
>         only be a short term solution, as we tend to move the problem
>         towards the end-user.
>  

This is the omly solution at the moment, because


>       * Provide "layout management" to size the dialogs automatically:
>         This is the most technically challenging solution, but it will
>         also solve many other problems (button order, ...)
>  

we do not have this yet (and I won't expect this to work before 3.3)
>       * Define different button widths in advance (e.g. 3) to cover most
>         of the text lengths which may occur - a compromise. This could
>         e.g. be documented in the dialog specification [4] (status
>         unknown).
>  

You should ask this the framework teams. But afaik this cannot be done.
There is only one button width for all languages.
There is only a workaround: you can tweack some config files, so that
the width of all UI elements for a language is increased by a given
factor. But this is nonsense to increase all dialog's width just beacuse
UX team thinks, that we need longer strings for a handfull of new dialogs.

André

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Stefan Weigel
In reply to this post by Clément Pillias
Clément Pillias schrieb:

> Because "Yes" and "No" would not have perfectly done the job. This is a
> well known issue in the UX field: people tend not to read the
> description of a warning and rather focus on the buttons labels, which
> should be as self-describing than possible.

I doubt that. From an ergonomical point of view, I bet it´s more
productive to use a small set of similar buttons (Yes, No, Ok,
Cancel) consistently in dialogs all over the application. With that
you keep a consistent main structure of dialogs to which the user is
accustomed to. You shouldn´t compel the user to compile a different
logic of question for each different dialog.

Stefan

--
www.datenpilot.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Christoph Noack
In reply to this post by André Schnabel
Hi André,

thank you for your mail. I'm unsure if this mail might also raise some
technical questions, so I keep the cross-posting to l10n and dev@sw...

Am Sonntag, den 18.01.2009, 20:45 +0100 schrieb André Schnabel:
[...]

> >> In the aforementioned thread you can see that we explain why (we  
> >> think that) such wording is better than another. These informations  
> >> could be useful for translators, but are lost in the process. On the  
> >> other hand, if translators were involved in the discussion, they  
> >> could warn us about the kind of issues you talked about.
> >>    
> This was the intention of my mail: a warning. All I received was
> reasons, why UX team did the correct decision - but at no place there
> was sometinglike "ok, we will consider your warning in our work". I fact
> I feel ignored.

I think our mails had the same intentions of a warning; that it has to
be carefully weighted if we use either simple words or descriptive
texts. Maybe I was a bit naive ... but sometimes I still hope that there
is a simple solution.

To get it right, what development version of OOo do we talk about? Is it
3.1 or is your warning about having influence on 3.2 and beyond?

> >> When the change is subject to a specification, there are in the iTeam  
> >> members of the UX team and translators, so the communication is OK.  
> >> Unfortunately every change in the UI does not necessitate such an  
> >> iTeam. I don't know well the process of accepting patches for issues,  
> >> but maybe we could require that every modification of the UI strings  
> >> is accepted by a translator?
> >>    
> This is not practicable - we support > 100 translations. ~40
> Translations are actively supported and try to keep up with the current
> version of OOo. One translator cannot tell the effects for all
> languages. There is only one common rule: try to keep messages short,
> clear and consistent. Don't use senteces  or "multi word strings" where
> they are not intended. Normally one single english word can be
> translated to another single word of a given language. If you use
> multiple words, you raise the complexity of translations dramatically,
> as you now bring grammar in.

That is a valid point.

> >> Because "Yes" and "No" would not have perfectly done the job. This is  
> >> a well known issue in the UX field: people tend not to read the  
> >> description of a warning and rather focus on the buttons labels,  
> >> which should be as self-describing than possible. With a "Yes/No"  
> >> solution, the user will 1/ Read the dialog title, 2/ read the buttons  
> >> labels 3/ Realize that he does not understand the warning and can not  
> >> select an action among the proposed ones, 4/ read the description of  
> >> the warning, and finally 5/ choose a button to click. With well  
> >> labeled buttons, steps 3/ and 4/ can be avoided in most cases.
> >>    
> >
> > Clément explained the importance of clear button labels very well.
> >  
>
> Imho plain theory and close to nonsense. Just reading "Keep old styles"
> and "Update Styles" does not mean anything, as long as you do not read
> the question. [...]

At this point it seems that we have a different understanding. Why? The
structured dialog for example does respect the required basis of
information for different user groups (beginners, advanced users,
experts). But I'll better stop before I lose the focus.

> > The problem is made worse as (to my current knowledge):
> >       * OOo is very (modal) dialog driven (!)
>
> Correct - please work on that in project renaissance but for the moment
> this is a fact, that we need to accept. Esp. if we desing modal dialogs.

The reason of this and the following statements was to emphasize why
even those little things improve usability, especially when the
interaction is dialog driven. Certainly I missed the opportunity to
express that more clear - sorry!

> > [...]
> > But what does "cannot translate such strings" mean? Is this related to
> > the lengths of the text, or it's ambiguous meaning?
>
> Ok: please tell what buton you would like to click:
> [Formatvorlagen a..] or [Alte Formatvorl...]
> for non-german speaking people:
> [...e Styles] or [...d Styles]

I don't understand the example. Is that the information which is shown
when translating the strings - the ones in the second line? I thought
the issue is that English text (which fits into buttons or in dialogs
developed) are translated and then don't provide enough space.

[...]

> >>> Btw - the same thing happens on all UI elements. But Buttons are  
> >>> more sensitive, as for labels and other stuff, we normaly have more  
> >>> space - but not for Buttons.
> >
> > The "have more space" seems like a rather technical issue to me. As far
> > as I know, OOo lacks a layout manager which automatically sets the size
> > for the dialog elements according their content.
>
> Correct ... but this is what we have. And please do not desing perfect
> dialogs that cannot be implemented.

I'm sure that - similar to all other OOo projects - the whole UX team
tries to do it's best to balance the given constraints and the user's
needs. The rather complex features which are developed today are a big
challenge with regard to OOo's technical capabilities (or let's say:
sometimes the effort is too high to realize desired behavior within
these capabilities).

So your input is valuable information when considering the interaction
design.

> > So I think, there are the following options for a short-/mid-term
> > solution:
> >
> >       * Use simple "one word button labels" as you proposed: This might
> >         only be a short term solution, as we tend to move the problem
> >         towards the end-user.
> >  
>
> This is the omly solution at the moment, because
>
>
> >       * Provide "layout management" to size the dialogs automatically:
> >         This is the most technically challenging solution, but it will
> >         also solve many other problems (button order, ...)
> >  
>
> we do not have this yet (and I won't expect this to work before 3.3)

At least, it seems to be on the way within a reasonable
time-frame... :-)

> >       * Define different button widths in advance (e.g. 3) to cover most
> >         of the text lengths which may occur - a compromise. This could
> >         e.g. be documented in the dialog specification [4] (status
> >         unknown).
> >  
> You should ask this the framework teams. But afaik this cannot be done.
> There is only one button width for all languages.
> [...]

Oh, then I was not clear enough. Instead of using different button
widths for each language, I thought about increasing the button width in
advance as it is already done today (The dialog "Insert Table" (Table --
Insert -- Table...) for example contains two button widths.).

It seems to me, that the today's preserved space for translation does
not fulfill the requirements by the language teams and causes problems
in one of the last steps of the development process: translation.
So do you think that it's possible to provide a "rule of thumb" (or some
examples) how large such strings could get - even in rare cases?

Currently, I know only [1] which deals with the length of texts. But it
seems less helpful for the i-Teams being in the (English) development
phase. If we would have a "more precise rule", then this information
should be made available (e.g. adding it to [1] or to the dialog spec I
talked in my previous mail).

For me, it seems a viable alternative to be a bit more generous with
space until we get the layout manager. It might cause larger dialogs
(and longer mouse movement, covering more background, ...) but it is far
easier to re-size the dialogs afterwards instead of re-designing the
texts.

What do you think?


Best regards,
Christoph

[1] OpenOffice.org User Interface Text Style Guide: Aware
http://specs.openoffice.org/collaterals/guides/text-style-guide.html#Aware
--
Usability * Productivity * Enjoyment

OpenOffice.org User Experience Team
http://ux.openoffice.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

André Schnabel
Hi,


Christoph Noack schrieb:
>
> Am Sonntag, den 18.01.2009, 20:45 +0100 schrieb André Schnabel:
> [...]
>
> To get it right, what development version of OOo do we talk about? Is it
> 3.1 or is your warning about having influence on 3.2 and beyond?

The current example was for 3.1 but this is a general problem (as long
as we have no layout manager).

>
> Oh, then I was not clear enough. Instead of using different button
> widths for each language, I thought about increasing the button width in
> advance as it is already done today (The dialog "Insert Table" (Table --
> Insert -- Table...) for example contains two button widths.).

This works - but not if the original text becomes to long.

> So do you think that it's possible to provide a "rule of thumb" (or some
> examples) how large such strings could get - even in rare cases?
>
> Currently, I know only [1] which deals with the length of texts.

This is a quite good rule (translated text might be up to three times
the english text).

> But it
> seems less helpful for the i-Teams being in the (English) development
> phase. If we would have a "more precise rule", then this information
> should be made available (e.g. adding it to [1] or to the dialog spec I
> talked in my previous mail).

There is no more precise rule (unless you like to derive something from
our translation database [2]).
As we do not have a precise rule, we should reduce the risk of either
wasting space or causing troubles for translations. The way to reduce
this risk is simple: keep strings (esp. for buttons) short.

Simple example for the thumb rule:
- For the translation of "Yes" you should reserve space for 6 more
characters. This would look like

                [   Yes   ]

- For "Keep old styles" you should preserve space for 30 characters
more. This would look like

    [               Keep old styles               ]

Isn't this a nice button? :)

And - once again, imagine we did not preserve enough space, we might end
up with a button like this:
                [p old Sty]


>
> For me, it seems a viable alternative to be a bit more generous with
> space until we get the layout manager. It might cause larger dialogs
> (and longer mouse movement, covering more background, ...) but it is far
> easier to re-size the dialogs afterwards instead of re-designing the
> texts.
>
> What do you think?

Given the example above my answer should be obvious.
Btw ... if we once get a layout manager we have tons of texts to
redesign anyway. Just for consistency reasons we would need to review
almost all the texts. Using "new style texts" here and there from now on
would not really help to reduce the work. Actually it would introduce
inconsistencies what is also a bad experience for the user.


Just some other thoughts to this problem - and why it is a problem at all.
Given our current release schedule, localized builds with updated UI
translations are available very late. [3]
l10n teams have only about 2 weeks to review all the translated elements
(what is a very short time, given the fact that you first need to finde
the UI elements before you can verify them).
If problems are found, the only way for UI teams is to raise a stopper
issue, as UI freeze has been passed at this time - and even regular code
freeze has been passed.
This is a problem in the l10n-process and we work to improve this - but
this is, what we have for the moment.

After all - people, using the English version of OOo are a minority.
They are the biggest minority for sure - but for more than 50% of our
users is a risk to be affected by broken translations.

best,
Andre

>
> [1] OpenOffice.org User Interface Text Style Guide: Aware
> http://specs.openoffice.org/collaterals/guides/text-style-guide.html#Aware

[2] OOo translations in Pootle
http://pootle.sunvirtuallab.com/languages/
[3] OOo 3.1 release data
http://wiki.services.openoffice.org/wiki/OOoRelease31

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Frank Loehmann
In reply to this post by André Schnabel
Hi André,

André Schnabel wrote:

> Hi Christoph,
>
> ok - you receive the answer that I already intented to write to Clemens,
>
> Christoph Noack schrieb:
>> it seems that I will be one of the first who will donate ... for some
>> good reasons that Clément already talked about. By the way, I will keep
>> his complete answer, because it seems to be sent to ux-discuss only.
>>  
> I'm still subscribed to the list (but I really wonder why for what
> reason) ...
If you do not care about the UX team, please feel free to unsubscribe
yourself.

>
>>> In the aforementioned thread you can see that we explain why (we  
>>> think that) such wording is better than another. These informations  
>>> could be useful for translators, but are lost in the process. On
>>> the  other hand, if translators were involved in the discussion,
>>> they  could warn us about the kind of issues you talked about.
>>>    
> This was the intention of my mail: a warning. All I received was
> reasons, why UX team did the correct decision - but at no place there
> was sometinglike "ok, we will consider your warning in our work". I
> fact I feel ignored.
What do you expect, if you send an e-mail to a project mailing list,
blaming others to be a team of fools because of using more than Yes/No
buttons? If you were really interested in getting attention to your L10N
problem, you should have been more diplomatic and could have asked why
this important for UX and if this could be avoided until we (OOo) have a
technical solution in place to cover different GUI layouts. We are using
descriptive strings on larger buttons for quite a while know, but nobody
ever raised an issue that this results in a big problems for others.

[...]

Best regards,

Frank

--
Sun Microsystems GmbH                Frank Loehmann
Nagelsweg 55                         User Experience StarOffice
20097 Hamburg                        Phone: (+49 40)23646 882
Germany                              Fax:   (+49 40)23646 550
http://www.sun.de                    mailto:[hidden email]

OpenOffice.org User Experience Team
http://ux.openoffice.org

Sitz der Gesellschaft: Sun Microsystems GmbH,Sonnenallee 1,
D-85551 Kirchheim-Heimstetten, Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

André Schnabel
Hi,

-------- Original-Nachricht --------
>  We are using
> descriptive strings on larger buttons for quite a while know, but nobody
> ever raised an issue that this results in a big problems for others.

Hmm - as quoted by Christoph:

[1] OpenOffice.org User Interface Text Style Guide: Aware
http://specs.openoffice.org/collaterals/guides/text-style-guide.html#Aware

The issue is known and documented. The suggestion is that "the UI designer must leave enough room on the screen to allow space for the longest translation. " The longer the english original text is, the more room needs to be left. For UI items that have one line only this is very hard, if the English text is to long.

If you speak about issues as in Issue Zilla, I gould go and collect a list if you like me to.

André


--
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by André Schnabel
Hi André,

Le 18 janv. 09 à 20:45, André Schnabel a écrit :

>
>>> In the aforementioned thread you can see that we explain why (we  
>>> think that) such wording is better than another. These  
>>> informations  could be useful for translators, but are lost in  
>>> the process. On the  other hand, if translators were involved in  
>>> the discussion, they  could warn us about the kind of issues you  
>>> talked about.
>>>
> This was the intention of my mail: a warning. All I received was  
> reasons, why UX team did the correct decision - but at no place  
> there was sometinglike "ok, we will consider your warning in our  
> work". I fact I feel ignored.

I'm sorry if you felt ignored, because my intention was the opposite.  
I think that your warning has been received, but you don't seem to  
have received the warning that we sent to you in response :( I don't  
think our attitude was something like "we did the correct decision  
because…", but rather to warn you that your vision of dialogs design  
was oversimplified.

I talked about a lack of communication, in the hope that the  
communication would get better in the future.

>>> I don't know well the process of accepting patches for issues,  
>>> but maybe we could require that every modification of the UI  
>>> strings is accepted by a translator?
>>>
> This is not practicable - we support > 100 translations. ~40  
> Translations are actively supported and try to keep up with the  
> current version of OOo. One translator cannot tell the effects for  
> all languages. There is only one common rule: try to keep messages  
> short, clear and consistent. Don't use senteces  or "multi word  
> strings" where they are not intended. Normally one single english  
> word can be translated to another single word of a given language.  
> If you use multiple words, you raise the complexity of translations  
> dramatically, as you now bring grammar in.

My idea was not to "tell the effects for all languages" but rather to  
raise warnings if (s)he feel that there will be potential issues in  
translations, before the beginning of the translation effort. So that  
the UX team (and other implied contributors) could change the  
proposed solution. Simply saying "rejected: there is a high risk that  
the text won't fit in the button for some translations" does not need  
to "tell the effects for all languages".

It's of course better if the UX team is conscious of these  
limitations, but we already have a lot of things to keep in mind when  
designing an interface (localization is not the only source of  
limitations,) so we can't do all the work by ourselves.

> Imho plain theory and close to nonsense.

Funny, because warning dialogs are maybe the most investigated  
objects in UX experiments. So this is really practical knowledge.

> Just reading "Keep old styles" and "Update Styles" does not mean  
> anything, as long as you do not read the question.

It has more meaning than "Yes" and "No". Especially the second time  
you see the dialog and recognize it: you don't have to read the text  
again. But with a Yes/No alternative, there is a higher chance that  
you don't remember the question, and ask yourself if "Yes" mean "Yes,  
I want to update the styles" or "Yes, I want to keep old formatting"…

> E.g.: what styles? What are styles at all? Why should I update  
> styles? What styles would be updated (styles in my document, styles  
> in the template .. oh soory, I don#t know about templates at all).
> So clicking the "complex text icons" is not much better than just  
> clicking "Yes" or "No".

It's never worse, and it is better for a lot of people.

> You are right: user often don't read messages. But why? Because  
> meaningless messages pop up to often and the joices you can do have  
> no  visible effect (no matter what you choose).

+1, but that's another effort (Renaissance?)

>> In the case of dialogs, we talk about efficiency (user understands  
>> what) and error free decisions (user knows what to decide). This  
>> is both related to efficiency and acceptance for a office  
>> productivity suite.
>>
> as said above - If you would like to stick with the current ecample  
> the user would not understad what she is deciding about and  
> therefore not be able to choose the correct answer just by readin  
> the button texts.

You have only one particular usage and user in mind.

> Ok: please tell what buton you would like to click:
> [Formatvorlagen a..] or [Alte Formatvorl...]
> for non-german speaking people:
> [...e Styles] or [...d Styles]

Same problem in french: "Mettre à jour les styles" and "Conserver les  
anciens styles". It seems that in this case, the english text is  
particularly short relatively to other languages.

> Would you get the meaning of the buttons, even if you read the  
> according question?
>
> Without raising an stopper issue, l10n teams have almost no chance  
> to request the correct size of buttons or UI elements.
>
> So no matter what HIGs suggest or what is written in tons of books  
> - descriptive texts will fail for many translations at the moment.
> The only way for l10n teams is to ignore UX suggestions and shorten  
> translations.

Well, you should shorten texts without ignoring UX suggestions.

UX suggestions only tells that "Keep old styles" is the better choice  
if possible. But there are other less-optimal choices:
- "Keep old version"
- "Don't modify"
- "Don't change"
- "Keep old"
- …
- "No"

The translator should choose the best choice fitting in the allowed  
space. But if you only have a single text you have no choice, so this  
is maybe were a reinforced communication between UX and NL could  
improve the process?

Best regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Stefan Weigel
Hi Stefan,

Le 18 janv. 09 à 22:30, Stefan Weigel a écrit :

> Clément Pillias schrieb:
>
>> Because "Yes" and "No" would not have perfectly done the job. This  
>> is a well known issue in the UX field: people tend not to read the  
>> description of a warning and rather focus on the buttons labels,  
>> which should be as self-describing than possible.
>
> I doubt that. From an ergonomical point of view, I bet it´s more  
> productive to use a small set of similar buttons (Yes, No, Ok,  
> Cancel) consistently in dialogs all over the application.

Standard buttons already exists and are used when appropriate, but  
this is not always appropriate ;)

> With that you keep a consistent main structure of dialogs to which  
> the user is accustomed to.

Buttons labels are not part of the structure, but part of the  
content, that's what experiments have shown. The structure (size of  
dialogs, layout, fonts, etc.) is already standardized.

> You shouldn´t compel the user to compile a different logic of  
> question for each different dialog.

It's what you do if you only use Yes/No buttons: since the possible  
actions are always the same, the user needs to focus more on the  
question asked rather than focussing on the actions (s)he wants to take.

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Stefan Weigel
Clément Pillias schrieb:

> Buttons labels are not part of the structure, but part of the content,
> that's what experiments have shown. The structure (size of dialogs,
> layout, fonts, etc.) is already standardized.

I am not talking about the geometrical structure but about the
logical structure of the dialog.

>> You shouldn´t compel the user to compile a different logic of question
>> for each different dialog.
>
> It's what you do if you only use Yes/No buttons: since the possible
> actions are always the same, the user needs to focus more on the
> question asked rather than focussing on the actions (s)he wants to take.

I think the user should indeed focus on the question. Without
understanding the question, the user is not able to choose the
correct answer, no matter if the button labels are "Yes" and "No" or
if the button labels are "Update styles" and "Keep old styles". I
don´t see any advantage in these words.

In fact, these "descriptions" destroy the straightforward logical
structure of the dialog and force the user to think once more,
before he can proceed:

The dialog is about a question, that is to be answered by yes or no.
After having understood the issue, the user in his mind comes to a
yes or no conclusion. But in order to serve these "descriptive"
buttons he must compile once more and transform his "Yes"  to
"Update styles" or his "No" to "Keep old styles".

You may be right, when you claim that some people tend not to read
the description of a warning. However, you won´t overcome this by
labelling buttons with ambiguous fragments of a description.

Stefan

--
www.datenpilot.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

David McKay
I agree with Stefan. The text of the dialog (or the last part of it) is
the question, the buttons are the possible answers.

Stefan Weigel wrote:

> Clément Pillias schrieb:
>
>> Buttons labels are not part of the structure, but part of the
>> content, that's what experiments have shown. The structure (size of
>> dialogs, layout, fonts, etc.) is already standardized.
>
> I am not talking about the geometrical structure but about the logical
> structure of the dialog.
>
>>> You shouldn´t compel the user to compile a different logic of
>>> question for each different dialog.
>>
>> It's what you do if you only use Yes/No buttons: since the possible
>> actions are always the same, the user needs to focus more on the
>> question asked rather than focussing on the actions (s)he wants to take.
>
> I think the user should indeed focus on the question. Without
> understanding the question, the user is not able to choose the correct
> answer, no matter if the button labels are "Yes" and "No" or if the
> button labels are "Update styles" and "Keep old styles". I don´t see
> any advantage in these words.
>
> In fact, these "descriptions" destroy the straightforward logical
> structure of the dialog and force the user to think once more, before
> he can proceed:
>
> The dialog is about a question, that is to be answered by yes or no.
> After having understood the issue, the user in his mind comes to a yes
> or no conclusion. But in order to serve these "descriptive" buttons he
> must compile once more and transform his "Yes"  to "Update styles" or
> his "No" to "Keep old styles".
>
> You may be right, when you claim that some people tend not to read the
> description of a warning. However, you won´t overcome this by
> labelling buttons with ambiguous fragments of a description.
>
> Stefan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Stefan Weigel

Le 19 janv. 09 à 14:59, Stefan Weigel a écrit :

> Clément Pillias schrieb:
>
>> Buttons labels are not part of the structure, but part of the  
>> content, that's what experiments have shown. The structure (size  
>> of dialogs, layout, fonts, etc.) is already standardized.
>
> I am not talking about the geometrical structure but about the  
> logical structure of the dialog.

There are basically four types of logical structures, in the order of  
decreasing generality (terminology is mine):

* Information dialogs: the dialog simply displays some information,  
and there is only an OK button. These kind of alerts are sometimes  
illustrated with an "i" information icon (or a light bulb in gnome)  
or a "no entry" icon for reporting errors (or when the requested  
action can't be performed).

* Confirmation dialogs: the dialog warns the user about something  
that will happen, and asks the user for the authorization to  
continue. These dialogs often have a title in the interrogative form,  
have an OK/Cancel set of buttons, and an exclamation mark or question  
mark icon. The OK button is often replaced by a button explicitly  
referring to the action that will be taken: "continue", "delete",  
"accept", "save", "replace", etc. The reason is that having an  
explicit description of what action will be done if the user clicks  
the button is less ambiguous, thus reducing stress and bad  
interpretations. The guidelines generally recommend to use the same  
verb as the one used in the title's question: "Are you sure you want  
to replace the existing file?" -> "Cancel/Replace".

* Actions dialogs: the dialogs asks the user to choose an operation  
among a few choices. This is the case of the dialog we are talking  
about, the choices being "keep old styles" and "update styles".  
"Cancel" may or not be included in the action list. It is a good idea  
to try to avoid this kind of dialogs, but this is another effort.

* Preference dialogs: the dialogs asks the user to set a preference  
rather than choosing an action. Example: "Do you want firefox to  
remember your password for this site?". The buttons could be labeled  
"Yes/No", but often gain to have a more precise labeling (with the  
same example: "never/not now/remember").

A common design error is to use an inappropriate type of dialog, such  
as a confirmation dialog when an information dialog could be used, or  
an action dialog when a confirmation dialog could be used, or a  
preference dialog when an action dialog could be used. It is always a  
good idea to use the more specific type of dialog possible, because  
there is an increased coherence of dialog layout with possible actions.

>>> You shouldn´t compel the user to compile a different logic of  
>>> question for each different dialog.
>> It's what you do if you only use Yes/No buttons: since the  
>> possible actions are always the same, the user needs to focus more  
>> on the question asked rather than focussing on the actions (s)he  
>> wants to take.
>
> I think the user should indeed focus on the question. Without  
> understanding the question, the user is not able to choose the  
> correct answer, no matter if the button labels are "Yes" and "No"  
> or if the button labels are "Update styles" and "Keep old styles".  
> I don´t see any advantage in these words.

I think that it is better not to have a question, if possible. Of  
course every dialog can bet designed this way, but this is often the  
worst solution.

Dialogs are rather like traffic signs: it is better to have an arrow  
labeled "Berlin" on the left and an arrow labeled "other directions"  
on the right than having a sign saying "Do you want to go to Berlin?"  
with a "Yes" left-arrow and a "No" right-arrow.

> In fact, these "descriptions" destroy the straightforward logical  
> structure of the dialog and force the user to think once more,  
> before he can proceed:

The user should not even have to think once!

> The dialog is about a question, that is to be answered by yes or  
> no. After having understood the issue, the user in his mind comes  
> to a yes or no conclusion. But in order to serve these  
> "descriptive" buttons he must compile once more and transform his  
> "Yes"  to "Update styles" or his "No" to "Keep old styles".

We could argue that the user does the opposite: first understand that  
he have to "update styles", then translating it in the answer "yes".

> You may be right, when you claim that some people tend not to read  
> the description of a warning. However, you won´t overcome this by  
> labelling buttons with ambiguous fragments of a description.

The fact is that users try to find the fastest way to close dialogs  
interrupting them in their tasks. So they read the beginning of the  
description to understand the "general idea", and look at the buttons  
to see if there is a button that serve their goals. Yes/No buttons  
force the user to read the description of the dialog up to the end of  
the question. Yes, having the full question is useful for some users,  
but a lot of them don't need it, so don't impose them, they are  
already upset because of the interruption.

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Stefan Weigel
Clément Pillias schrieb:

> * Actions dialogs: the dialogs asks the user to choose an operation
> among a few choices. This is the case of the dialog we are talking
> about, the choices being "keep old styles" and "update styles".

No. The choice is between "Yes" or "No", because the question reads
"Do you want to... ?" If the choice was between "keep old styles"
and "update styles" the question would have to read "What do you
want to... ?"

These are complete different processes for the brain. By asking a
Yes/No question and not allowing "Yes" or "No" as an answer you
break the thread. This requires additional effort for the user´s mind.

Anyway, for questions like "What do you want to... ?" I would prefer
a radio button control and OK/Cancel buttons. This allows a
consistent concept for "What"-questions, no matter if there are two,
three or ten choices. This would also prevent us from the button
size issue which André ran into.
http://wiki.services.openoffice.org/wiki/Image:DialogClement.png

As stated before, I would avoid other buttons than
OK/Cancel/Yes/No/Help. From my point of view, having different
button labels in each different dialog is bad human engineering.

> Dialogs are rather like traffic signs: it is better to have an arrow
> labeled "Berlin" on the left and an arrow labeled "other directions" on
> the right than having a sign saying "Do you want to go to Berlin?" with
> a "Yes" left-arrow and a "No" right-arrow.

The metaphor doesn't work. In your case the driver has already
decided to go to Berlin. The signpost shows him the way. Our dialog
pops up due to a special situation that needs judgement.

> The user should not even have to think once!

Cogito, ergo sum. We don´t want our users to use the software
without thinking. That wouldn´t work anyway. ;-)

Stefan

--
www.datenpilot.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias

Le 19 janv. 09 à 19:19, Stefan Weigel a écrit :

> Clément Pillias schrieb:
>
>> * Actions dialogs: the dialogs asks the user to choose an  
>> operation among a few choices. This is the case of the dialog we  
>> are talking about, the choices being "keep old styles" and "update  
>> styles".
>
> No. The choice is between "Yes" or "No", because the question reads  
> "Do you want to... ?" If the choice was between "keep old styles"  
> and "update styles" the question would have to read "What do you  
> want to... ?"

I think that the question should be changed :) No, just kidding!

Ok, since you seem to be an expert in semantics, here is something  
for you: a push button is made to be pushed with the effect of  
starting an action (Windows UX Guidelines call them "command buttons"  
and state clearly that "With a command button, users initiate an  
immediate action" [1]). So it should be labeled with a verb  
suggesting that action. "Yes" and "No" are not verbs. "OK" neither.

> These are complete different processes for the brain. By asking a  
> Yes/No question and not allowing "Yes" or "No" as an answer you  
> break the thread. This requires additional effort for the user´s mind.

If you still believe that the user reads the text, up to the point  
that (s)he notice that it is a question rather than a declarative  
sentence, I think that you totally misunderstand how users react to  
popping dialogs. Think rather as on Internet, where people only read  
the most salient text and jump to the hyperlinks. With dialogs, users  
jump directly to the buttons and only read the text if necessary.

And this is a very efficient strategy on systems where buttons are  
well labeled. E.g., I see the "save file?" dialog ten times a day,  
but I don't remember its exact wording because its buttons are  
labeled "Cancel/Save" (I use Mac OS X), and I just need to see the  
highlighted "Save" button to know that it is the "Save File?" dialog,  
and choose to click the button or "Cancel".

But it is true that on OSes that follow a different logic in buttons  
labeling, Mac OS X labeling of buttons might confuse the user (who  
gets used to it very quickly). Since OOo's interface is not (yet) OS-
specific, I think that we should use the guidelines of the most used  
OSes. And Windows, Mac OS X and Gnome guidelines all says that it is  
better to use specific verbs instead of Yes/No (I have not verified  
for Kde). It is also true that Windows Guidelines accept Yes/No  
buttons in special cases, and that the "update template" dialog  
discussed could be understood as one of these special cases, but I  
think that it is better to follow the common guidelines.

> Anyway, for questions like "What do you want to... ?" I would  
> prefer a radio button control and OK/Cancel buttons. This allows a  
> consistent concept for "What"-questions, no matter if there are  
> two, three or ten choices. This would also prevent us from the  
> button size issue which André ran into.
> http://wiki.services.openoffice.org/wiki/Image:DialogClement.png

This is an alternative (coherent with Windows UX Guidelines), however  
there is no "cancel" option in the dialog, actually: you have to  
choose an alternative. Well maybe we should add such a button, by the  
way.

Moreover, this design necessitate another click and thus is less  
efficient.

And once again, when the choice is made in a list of actions, buttons  
offers a more logical choice. But I won't talk about affordances or  
conceptual model with you.

> As stated before, I would avoid other buttons than OK/Cancel/Yes/No/
> Help. From my point of view, having different button labels in each  
> different dialog is bad human engineering.

I still don't understand why you think so, despite all the existing  
evidences…

[1] http://msdn.microsoft.com/en-us/library/aa511453.aspx

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Stefan Weigel
Clément Pillias schrieb:

> I still don't understand why you think so

Maybe it´s a question of being right-brained or left-brained. I am
not sure.

Stefan



--
www.datenpilot.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

André Schnabel
In reply to this post by Clément Pillias
Hi Clement, *

Clément Pillias schrieb:
> I'm sorry if you felt ignored, because my intention was the opposite.
> I think that your warning has been received, but you don't seem to
> have received the warning that we sent to you in response :( I don't
> think our attitude was something like "we did the correct decision
> because…", but rather to warn you that your vision of dialogs design
> was oversimplified.
>
> I talked about a lack of communication, in the hope that the
> communication would get better in the future.

But both does not deal wih the fact, that we do not have unlimited
space. And please the subject of the mail:
"... don't use *long* descriptive texts ..."

So - altough I disaree to most of your aruentations about descriptive
texts (esp. the one that the user should not think at all) this is not
the real issue here.

My Issue is *long* descriptive text that is likely to break localized
versions at a very late time in the development cycle.
Althoug I disagree to many text descriptions, I can live with it. (And
will translate it as close as I can). But If I cannot translate
correctly without either breaking the meaning or the user interface,
this is a real problem. And at the moment this is simple reality that we
have to face.

>
> My idea was not to "tell the effects for all languages" but rather to
> raise warnings if (s)he feel that there will be potential issues in
> translations, before the beginning of the translation effort.
So the warning has been raised:
- Every String might use three times the space of the english string.
- Strings with only one or two words  are normally easy to handle.
Strings with more  words  have a higher risc to be a problem for
translation - unless the strings are displayed in a multi line control

There is no real need to check every specification for this, as this is
a general rule. Unfortunately it is hardly possible to identify
precisely, what strings  might cause problems "before the translation"
begins, becaus you actually would need to translate the strings.

> It's of course better if the UX team is conscious of these
> limitations, but we already have a lot of things to keep in mind when
> designing an interface (localization is not the only source of
> limitations,) so we can't do all the work by ourselves.
Well .. other teams failed as well. QA and development should be aware
of the problem as well and should have interfered.

>
> The translator should choose the best choice fitting in the allowed
> space. But if you only have a single text you have no choice, so this
> is maybe were a reinforced communication between UX and NL could
> improve the process?

Hmm .. this might cause some kind of "overcommunication". Waht really
needs to be improved is the visibility of specifications. "Once upon a
time" it was suggested to use [hidden email] to announce new
specifications and updates to specifications. This worked quite well for
a handfull of specs. Even if the feedback was not so high in numbers, it
was quite easy to review specification updates.

At the moment it is really hard to keep track about specification
updates. Early feedback is almost impossible. And ifyou need a
specification to check something (e.g. the context of new strings) this
might be also a hard job. E.g. I found the specs for Calc Collaboration
and File locking only by browsing the CVS repository of the specs
website (there is no link at the regular website).

Btw.:
I would recomment some people who are interested in the quality of OOo
user interface texts to test if these texts (esp. the Button labels that
are discussed here) are really as easy to understand as you claim. A
good way is to try to translate OOo Userinterface. During the
translation process you will need to review all new strings - but
without knowing the exact context. This gives a totally new view to the
strings.
E.g. the string "Table Desing Styles" . I'd guess .. if one does not
need to translate this string without knowing exactly, where this string
occures, one does not think about the exact meaning of the string - and
will not find, what is wrong with the string. (Maybe someone here is
interested in riddles).

André


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Christoph Noack
In reply to this post by Stefan Weigel
Hi everyone!

Am Montag, den 19.01.2009, 23:12 +0100 schrieb Stefan Weigel:
> Clément Pillias schrieb:
>
> > I still don't understand why you think so
> Maybe it´s a question of being right-brained or left-brained. I am
> not sure.

At least this reason sounds a lot better then keeping the "right" brain
as a "left" over ;-) Before anybody asks, this is just a word-play...


BUTTONS LABELS

But let's go back a few hours and re-consider the initial request by
André. I know him to be a very active member in the translation teams,
so I still take his initial request very seriously.

Frank, you said in a previous mail that this is the first time such an
(big) issue has been raised. How were such problems handled by Sun or
StarDivision? Did you use only short button descriptions, did you have
far less languages to support, or was there a short "feedback loop" to
the developers to resize the buttons?


On the other hand, the discussion seems to make clear, how important the
careful design of such dialogs is. So I would like to remind to announce
specifications on the specifications-announce mailing list [1] to let us
have a look on it - together. If wording may seem to be ambiguous,
translation doesn't ease the problem ;-) (This reminder is also related
to me...)


YES/NO/CANCEL :-)

@Clément: You discussed the dialog button labeling on different
platforms, e.g. Windows and Gnome. I had a look at the KDE resources and
they seem to handle it similar. Unfortunately, the KDE4 HIGs [2] are
still a bit rough (they do have more than we have *g*), but the KDE3
HIGs deal explicitly with the Yes/No-Dialog [3].


[1] http://specs.openoffice.org/servlets/SummarizeList?listName=announce

[2] KDE4 Warning Messages Checklist: "When the user has the choice
between two options, descriptive labels should be used instead of yes/no
buttons."
http://wiki.openusability.org/guidelines/index.php/Checklist_Warning_Messages

[3] KDE3 UIG, Simple Dialogs, Yes/No-Questions
http://developer.kde.org/documentation/standards/kde/style/dialogs/simple.html#yesno


I really hope we will find a temporary solution for the next two minor
releases - until the right infrastructure is in place.

Bye,
Christoph


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Elizabeth Matthis
Hi All,
As I used to be the linguist who did all the German and English UI
strings up till OOo 2.0 I would like to respond to this thread.

You have my greatest sympathy, Andre! I know how difficult it is.

On 01/19/09 23:58, Christoph Noack wrote:
[...]
>
> Frank, you said in a previous mail that this is the first time such an
> (big) issue has been raised. How were such problems handled by Sun or
> StarDivision? Did you use only short button descriptions, did you have
> far less languages to support, or was there a short "feedback loop" to
> the developers to resize the buttons?
>
>  
What we used to do was look into the translation (e.g. localization)
database to find the longest word we could (in any language) and then
we'd paint the button to be long enough to fit that many letters.
Usually it worked. If we were unlucky and some translation was indeed
longer, then there were "feedback loops" to have the button redone by
the developer. Sometimes issues/bugs were written because a new
localization of OOo needed the button to be a different length and so
the bug had to be fixed asap.
> On the other hand, the discussion seems to make clear, how important the
> careful design of such dialogs is. So I would like to remind to announce
> specifications on the specifications-announce mailing list [1] to let us
> have a look on it - together. If wording may seem to be ambiguous,
> translation doesn't ease the problem ;-) (This reminder is also related
> to me...)
>
>  
Exactly, right, Christoph. The specs are the place for the button length
to be set so the developer implements it right the first time. If
languages commonly have longer wording than English, then it is
important for people from those communities to be especially diligent in
checking the specs and especially fast and clear in pointing out the
need for more space. That is at least how I see it, because that is the
handling I know from 3 years ago. I no longer work on UI strings, so I
am not involved in the process these days. I doubt it has changed so
much, though.

[...]
> I really hope we will find a temporary solution for the next two minor
> releases - until the right infrastructure is in place.
>
>  
I wish OOo had a layout manager. I do not know when there might be one
or how difficult it is to integrate. It must be very difficult or it
would have been done long ago.

Hope this helps. I'm so sorry I cannot wave a magic wand and make it
easier, Andre!
Best regards,
Elizabeth / Liz

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12