Community
Participate
Working Groups
I20060307-1315 The animated error message that appeared e.g. in the New Java Class wizard has a number of problems: 1) Warnings are not animated, but errors are. This is inconsistent. 2) Errors only appear delayed. Everywhere else, messages are shown immediately, and that is good. 3) The animation is distracting and does not fit the style of Eclipse. Our users appreciate immediate feedback and are not keen on waiting until an ad-like popup appears. 4) The original message is still shown when an error appears. If the original message took 2 lines (see e.g. New JUnit Test Case wizard), the error is shown partially above it, cutting parts of the message. Also, existing implementors of TitleAreaDialogs expect that the description is not shown when they set an error message. This is a breaking change. 5) The implementation gets confused with simple steps: - select a source package and open the New Java Class Wizard - type "my", select the whole type name, type "My" => "Type name is empty." error is still shown, although the field was never empty. In summary, my vote is to turn this change back for 3.2.
(In reply to comment #0) > I20060307-1315 > > The animated error message that appeared e.g. in the New Java Class wizard has > a number of problems: > > 1) Warnings are not animated, but errors are. This is inconsistent. You are correct, the warnings should follow the same standard as the error messages. We are looking at updating this behaviour. > > 2) Errors only appear delayed. Everywhere else, messages are shown immediately, > and that is good. The initial delay is to allow for error correction before commencing the animation, however, I agree that the current delay is too long and should be reduced. > > 3) The animation is distracting and does not fit the style of Eclipse. Our > users appreciate immediate feedback and are not keen on waiting until an > ad-like popup appears. The goal of the animated error as opposed to the current grey box is to create a slight distraction to alert the user of a problem on the page; the older style grey box was often ignored. Also, with a shorter delay time the feedback will appear sooner. > > 4) The original message is still shown when an error appears. If the original > message took 2 lines (see e.g. New JUnit Test Case wizard), the error is shown > partially above it, cutting parts of the message. > > Also, existing implementors of TitleAreaDialogs expect that the description is > not shown when they set an error message. This is a breaking change. I would not say that this is a breaking change but rather a change in style. The message area is designed to be seperate from the page description to identify some exceptional case, it is not designed to replace the text underneath. Is there a case where it would be required that the error message completely cover the page description? > > 5) The implementation gets confused with simple steps: > - select a source package and open the New Java Class Wizard > - type "my", select the whole type name, type "My" > => "Type name is empty." error is still shown, although the field was never > empty. This has been fixed in builds > 20060308 > > In summary, my vote is to turn this change back for 3.2. >
*** Bug 131523 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > > 4) The original message is still shown when an error appears. If the > > original > > message took 2 lines (see e.g. New JUnit Test Case wizard), the error is > > shown > > partially above it, cutting parts of the message. > > > > Also, existing implementors of TitleAreaDialogs expect that the description > > is > > not shown when they set an error message. This is a breaking change. > > I would not say that this is a breaking change but rather a change in style. > The message area is designed to be seperate from the page description to > identify some exceptional case, it is not designed to replace the text > underneath. Is there a case where it would be required that the error message > completely cover the page description? The screenshot (attachement 36137) attached to bug 131523 shows an example of an error message partially overlapping the message area. The slide-in should never partially cover up the message; this simply looks bad.
(In reply to comment #1) > > Also, existing implementors of TitleAreaDialogs expect that the description > > is not shown when they set an error message. This is a breaking change. > > I would not say that this is a breaking change but rather a change in style. > The message area is designed to be seperate from the page description to > identify some exceptional case, it is not designed to replace the text > underneath. Is there a case where it would be required that the error message > completely cover the page description? Javadoc of TitleAreaDialog tells about a "common area for displaying a description, a message, or an error message". Javadoc of setErrorMessage(..) says: "Display the given error message. The currently displayed message is saved and will be redisplayed when the error message is set to <code>null</code>.". => Showing both messages does not fulfill the API contract. I have not checked all existing subtypes of TitleAreaDialog to check which ones rely on the fact that the messages are replaced... . And as already mentioned: cutting messages is ugly.
Thanks for all the input: It appears that this is the list of outstanding comments: 1) Description and Error at the same time - the error is intended to overlay the title area without disorienting users (i.e. the title is still there and you just need to respond to this error and proceed - what in particular is wrong with being able to see all or part of the title 2) JavaDoc breaking change for TitleAreaDialog class comment - looking at the comments and the javadoc again I don't see how this javadoc is saying necessarily that you will ONLY see one of error/description and message. It explains there is a common area where they will be displayed. - is there a case where a description should not be shown when an error is showing? 3) JavaDoc breaking change for setErrorMessage - this javadoc says the current message will be redisplayed when the error is set to <code>null</code> and this in indeed the case. It does not mention that it will be hidden. Just indicates that you need to call setErrorMessage with null to get back to what you had before displaying the error. 4) Cutting messages is ugly - should we use the elipses and short the error text like the preferences pages do? 5) Description is partially covered by error message - see #1 this is inteneded behaviour, would you like to see the error message area larger?
(In reply to comment #5) > 5) Description is partially covered by error message > - see #1 this is inteneded behaviour, would you like to see the error > message area larger? I guess yes - IMO, the error message should cover the entire message area.
> 1) Description and Error at the same time I don't know all wizards that have been written so far, so I don't know whether somebody interpreted the javadoc as I did. The class doc says: "a common area for displaying a description, a message, *or* an error message". I interpret the "or" as exclusive or, but you could also read it as |. > - should we use the elipses and short the error text like the preferences > pages do? Nope, please don't copy UI bugs ;-). However, I agree with Tom that cutting parts of the message just looks bad (see his screenshot in bug 131523). > 5) Description is partially covered by error message > - see #1 this is inteneded behaviour, would you like to see the error > message area larger? Yes, if you can't rule out the possibility of partially cutting the message, the error should be made so large that it covers the whole message. Other outstandig issues in I20060322-1335: a) 1) from comment 1: warnings and errors handled differently b) 2) and 3) from comment 1: speed is still too slow. I have to wait until I can read the message. If animation is really wanted, you should display the error message immediately and then e.g. animate the error icon, or fade the background color from white to a light red and back to white, or put a movie of a wizard making a sad face and waving about with his arms in the upper right corner. c) [new] The error message does not use the dialog font.
> a) 1) from comment 1: warnings and errors handled differently Seems to be aligned for I20060327-0010. For an example where the warning message is cut (rather than the normal message), select a java project, open the New Java Class Wizard, and type a lowercase letter. The warning message shown is "Type name is discouraged. By convention, Java type names usually start with a" [cut here].
The majority of the outstanding issue are addressed by build I20060328. The message area is now larger to accomodate the longer strings (i.e the new class dialog warning if a lowercase letter is used to begin the class name). Also, the message area text is now tied into the dialog font. This means that the titles should no longer be partially covered in the New wizard dialogs.
Created attachment 37084 [details] screenshot of warning touching title I checked I20060328-0010 and can shorten the issues list to: - Overlay message comes up a bit too high. It can touch the title (screenshot). - Bug 133533 - Animating text is a bad UI, since it forces the user to wait (main issue of this bug).
*** Bug 135058 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The goal of the animated error as opposed to the current grey box is to create > a slight distraction to alert the user of a problem on the page; the older > style grey box was often ignored. Also, with a shorter delay time the feedback > will appear sooner. I see that as much more than a "slight distraction". I don't think the old grey box would be ignored as long as the Finish button is disabled. So, why not put the error message closer to the Finish button? If you look at the usecase on Bug 135058, you'll see how annoying the animation can be.
Another case of major ugliness: open Breakpoint Properties dialog -> an error shows up for a second and then slides away -> checking "Enable Condition" checkbox gives an error message that partly covers the page tile "Common" I can only repeat my request to remove this prematurely released feature for 3.2.
(In reply to comment #13) > Another case of major ugliness: open Breakpoint Properties dialog > -> an error shows up for a second and then slides away > -> checking "Enable Condition" checkbox gives an error message that partly > covers the page tile "Common" > This is a separate issue. This problem is the result of the page being set with an error to begin with and then having the error set to null as the page is displayed. This was an issue with the style error messages as well, it just wasn't as apparent.
Filed bug 135658 for the Breakpoint Properties dialog's error flash. The issues with user distraction & slowdown and the partly covered title remain.
Bug: The animation cannot be disabled by Window > Preferences > General > Appearance > Enable Animations
(In reply to comment #16) > Bug: The animation cannot be disabled by Window > Preferences > General > > Appearance > Enable Animations > Mike, could you please open a new bug for this issue.
(In reply to comment #17) > Mike, could you please open a new bug for this issue. https://bugs.eclipse.org/bugs/show_bug.cgi?id=136133 Shaun, can you direct me to the best place where to add a unit test for this, please?
The following changes have been made in HEAD: - The animation will happen the first time an error or warning is introduced and then the message area will merely be displayed or hidden when subsequent errors or warnings occur. - The border margins have been increased to fully cover the description and to avoid partially covering the page title. - The ellipsis have been removed from the preferences dialog in favour of a larger message area. - The animation will be active by default but can be disabled in the preferences page (General > Appearance > Enable Animations). Thanks everyone for your comments and help in polishing off this new message area. I am going to close this bug as Resolved/Fixed; if there are any new issues, please open another bug report.
