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 d...@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: [email protected] For additional commands, e-mail: [email protected]
