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