Community
Participate
Working Groups
In the context of bug 494499, it seems to me that users do not really feel that they have the choice when simply asked Yes or No. The mostly feel encouraged to click Yes and so not take the time to read details and make a decision. IMO, the Yes/No questions should be avoided. Instead I would suggest to either put the explicit actions on buttons (which seems consistent with the UI metaphor of a button: doing something) such as "Switch to Debug Perspective" and "Remain on current perspective", or in case the label doesn't fit buttons, to encourage usage of Radio on the dialog to clearly show the mataphor of a choice. A benefit of Radio is that there is more room to add specific details about each choice. Could this be introduced as a UI Guideline for Eclipse IDE?
The Eclipse UI guidelines are built on top of the available guidelines from the main OSes we support. Yes/No dialogs are commonly used and should not be deprecated. I agree, that in some cases having concrete buttons might be better, but in general it would result in large buttons and dialogs.
+1 for the idea. Maybe not "deprecate Yes/No dialogs" but "prefer named button actions" or something like this. I opened Bug 501239 to "test" this suggestion.
(In reply to Dani Megert from comment #1) > The Eclipse UI guidelines are built on top of the available guidelines from > the main OSes we support. Yes/No dialogs are commonly used and should not be > deprecated. By deprecate, I did not mean strongly deprecate such as making it candidate for removal. I was more something about a UI rule such as """ Consider and prefer named buttons over Yes/No --------------------------------------------- Yes/No dialogs require users to fully read the content of the dialog to get the context. For some simple operations, user may be able to take a decision without processing the dialog text and by only being proposed the 2 solutions. So whenever you have a Yes/No dialog, you need to consider one of the following alternatives: * Named push buttons (if label can be short and descriptive enough) * OK Dialog with 2 radios, each combo explainng what's going to happen in case of selection. """
It's true that my focus goes immediately on the buttons and I don't really read the text above. Thus often I blindly click "Yes" or "No" assuming I "know" this message dialog. And often, my assumption is wrong, so I trigger an undesired action. However, I don't like long button labels. For the perspective switch example, I suggest that having the button labels like "Switch" and "Remain" is enough. If in the very first second these labels do not speak enough for me then I will look above and I will see the message title saying "Switch to Debug Perspective".
Created attachment 264158 [details] Eclipse overwrite dialog -1 for this idea. I appreciate the predictability of these dialogs (if they're implemented as expected). The order of Yes and No is predictable for a given OS. The button texts are predictable and short. Often I aleady know in advance that a particular Yes/No dialog will come up. And if the question in it is worded such that the Yes answer is equivalent to "continue" and is the default button, then I can simply hit Enter to go on. I attached a typical example (which I had yesterday and which reminded me of this bug), the file overwrite question dialog. It would really be no enhancement to turn the button labels into something longer, more descriptive. I think that Gimp avoids Yes/No dialogs and I've always hated that. Each time I have to look at all the buttons. And notice how the actual question text does not become shorter, either. I'll attach two examples in a minute.
Created attachment 264159 [details] Gimp overwrite dialog
Created attachment 264160 [details] Gimp "Save before closing?" dialog
Eike, the Gimp dialogs you attached are significantly better than the Eclipse one. In fact, the Eclipse one is a great example of unusable dialog. Because: - The title says nothing about the action about to be performed. - The buttons are confusing. What does "Yes to All" mean? What does "Cancel" mean? How is it different to "No"? - You have to read the whole body text to understand that it is about overwriting an existing file. You used to it, because you see it for long years. But for the average user it is a confusion.
(In reply to Eike Stepper from comment #5) > I think that Gimp avoids Yes/No dialogs and I've always hated that. Each > time I have to look at all the buttons. And notice how the actual question > text does not become shorter, either. I'll attach two examples in a minute. With the Gimp dialog, you only read the buttons and then what's bold. It's IMHO faster and easier to take a decision using Gimp dialogs than Eclipse ones - except for us who've been using Eclipse IDE daily for years like after 20 years of marriage so we understand it well even if it doesn't say things clearly. Technically, the idea is only to relabel Yes/No buttons in relevant cases; the adopter should NOT create new buttons, but just call getButton(IDialogConstants.OK).setLabel("Save") and getButton(IDialogConstants.CANCEL).setLabel("Discard"). Then consistency with OS, and predictability of which button has focus, which one does something and which one doesn't is still there. The Overwrite dialog you've shown works for you because you're used to such dialogs, but in reality, there are multiple horrible things: * Title is "Question" * The "Yes to All" and "No to All" dialog don't give any context. What's "All"? * Seeing this dialog without knowing (or remembering) the context, I just have the impression that the "Yes To All" and "No To All" buttons make no sense here
(In reply to Mickael Istria from comment #9) > With the Gimp dialog, you only read the buttons and then what's bold. I may be old-fashioned, but on unfamiliar dialogs I always read top-down and left-right. Note that Gimp's dialog shows an equivalent amount of description text including a typical Yes/No question. But then there are no Yes/No buttons to answer the question. > The Overwrite dialog you've shown works for you because you're used to such > dialogs, Exactly. That's why I'd prefer them to stay that way ;-) And by now there's not much evidence that the majority of users would feel better with relabeled Yes/No buttons. > but in reality, there are multiple horrible things: > * Title is "Question" Yes, no doubt. Funny that Gimp's overwrite dialog has a similar issue; no caption at all ;-) > * The "Yes to All" and "No to All" dialog don't give any context. What's > "All"? I think that's "just" kind of a bug in that dialog. If there's just one file that already exists there should really be no "Xyz All" buttons at all. If there are multiple existing files it appears that a sequence of dialogs is popped up one after the other. That is questionable UX IMHO. The "All" buttons only make sense when you know this weird behavior already. A single dialog with a checkbox list might be better here in the first place. > * Seeing this dialog without knowing (or remembering) the context, I just > have the impression that the "Yes To All" and "No To All" buttons make no > sense here Totally agreed, see above.
From https://msdn.microsoft.com/en-us/library/dn742478.aspx : "Prefer specific responses over Yes and No buttons. While there's nothing wrong with using Yes and No, specific responses can be understood more quickly, resulting in efficient decision making." From the crowd http://ux.stackexchange.com/questions/9946/should-i-use-yes-no-or-ok-cancel-on-my-message-box: "Never use 'Yes' or 'OK' when you could use a verb instead." Another from the crowd http://ux.stackexchange.com/questions/35210/should-all-button-text-start-with-a-verb , with a reference to http://www.uxbooth.com/articles/the-grammar-of-interactivity/ From a public administration: http://www.labor.ny.gov/ux/design-action-button-label.html References to the practice of putting verbs in button label are very numerous.
Ok, that's probably some evidence then ;-)
Anything left here? In platform we updated already lots of buttons. We also did this for EGit.
I don't know whether this kind of things are in the scope of architecture council. While this in indeed a cross-project discussion for IDE related project, it's of no interest for some other projects, so it's probably not in the scope of Architecture Council anyway. So let's move it to Platform. Moreover, I think the effort made by Platform do have the good effect of leading by example. This rule has applied on Platform and downstream projects will progressively mimic it. I don't think it's necessary to document that rule, because most people don't read documentation anyway. So overall, I have the impression that this issue can be considered as fixed.
(In reply to Mickael Istria from comment #14) > I don't know whether this kind of things are in the scope of architecture > council. Mickael, I think you submitted it to AC as a tracking item for the UI Best Practices Working Group, which is part of the AC. It's good that the Platform changed a lot of labels. However, nothing has been updated in the UI guidelines. If there is no interest in updating them we should probably remove them from the global AC agenda and make them an Eclipse IDE specific item. Thoughts?
