Community
Participate
Working Groups
Created attachment 90838 [details] screenshot I20080226-1155 - create an class A - search for declarations of A - delete A - go to the search view and press 'Search again' (for A) You get an error dialog. See attachment a.) The first line in bold says 'Error'. I think the word 'Error' should be avoided, it's rather a 'problem'. I also think that this is already clear from the image and the dialog title. b.) The information 'Java Search (Time of error: Not available)' is not so useful. I suggest, if there is no time of error, then better leave this away. Maybe 'Java Search' could also be embedded in a message: 'Java Search' reported a problem: Element 'A' does not exist. c.) Details shows exactly the same as written in the declaration. I suggest to no offer details, if there are no details
a. I think that replacing 'Error' with other word may be considered. However 'Error' is something what the developer wants to say (there are also other options: CANCEL, INFO, WARNING). The dialog title is always the same for single issue. b. Removing time clause if there is no timestamp is a good idea. I will investigate messages that appears on the error dialog. c. dup of bug 211664 Szymon, Martin, could you assign this bug to me and add there [StatusHandling] phrase in the beggining?
a. You can see from the dialog image and from the dialog title if this is an error , warning or info. I suggest you to have a look at other error or warning dialogs, for example: http://usability.kde.org/hig/current/windows-dialogs.php or how the dialogs looked in older Eclipse releases.
Created attachment 90876 [details] Solution proposal Martin, does this look better for you? Message 'see the details' appears if there is no additional information passed with StatusAdapter. I think I will remove during c fixing.
Created attachment 90879 [details] Patch
Created attachment 90880 [details] mylyn/context/zip
Looks better! I would use the following wording for the second sentence: See 'Details' for more information Also note that we should always use single quotes, not double quotes. This is probably a bug in the status: An internal error occurred during: 'Test Job'
Created attachment 90979 [details] Patch with changed message Details message improved. Double quotes is something that came in StatusAdapter. I will investigate it. Szymon, could you review the patch?
Created attachment 90993 [details] Screenshot with the prev dialog (In reply to comment #7) If the problem occurs in a job, we should have both the job name (with its timestamp when available) and the problem summary in the dialog. See the screenshot.
Created attachment 91132 [details] new solution proposal initial draft of what will be displayed is available on http://wiki.eclipse.org/Platform_UI_Error_Handling#New_StatusDialog
Created attachment 91133 [details] Updated patch [API changed]
comment 9: Again, I think the word 'Error' needs to be avoided. The rule is to avoid 'drastic' words. Especially as the dialog doesn't understand how it is used. 'Job 'Java Search' has encountered a problem.' I would also align the message (Element 'A' does not exist anymore) with the first line (both on the right side of the image). If there is a time of error (like in comment 8), maybe we could only show it in the details? I don't think it's that interesting to justify it on the first line (it's also very long). Adding Tod as cc.
(In reply to comment #11) > comment 9: > > Again, I think the word 'Error' needs to be avoided. The rule is to avoid > 'drastic' words. Especially as the dialog doesn't understand how it is used. > > 'Job 'Java Search' has encountered a problem.' I agree with Martin. However the job framework passes only IStatus.ERRORs to the status handling. So the message is correct. As Martin mentioned before, the icon shows what's the severity. The message can use less 'drastic' ;-) words. > > I would also align the message (Element 'A' does not exist anymore) with the > first line (both on the right side of the image). I agree. > If there is a time of error (like in comment 8), maybe we could only show it in > the details? I don't think it's that interesting to justify it on the first > line (it's also very long). Right. If there is only one error in the dialog, the details part is the right place to show the timestamp. However I would leave the timestamp in the list of problems in case of more problems in the dialog.
Created attachment 91158 [details] indented second line, error replaced with problem how about now?
Looks good! I agree with the comments in comment 12. Maybe without the empty line between the two lines? There are not 'Details' in this scenario (no extra messages, no date). Maybe we should removing or disabling the button then? Thanks for all the efforts!
Created attachment 91165 [details] long error dialog BWT, I also noted that dialogs can get very long when the message is long. Make sure the label wraps...
Created attachment 91172 [details] First and second message are much closer now For wrapping I have bug 220609 and 220758. I will fix them as soon as I will have displayed information relatively stabilized.
Created attachment 91173 [details] Patch
The word "Job" should not appear in the UI - this is a technical detail that we have always been very careful not to put in user-oriented messages. For example the progress view always uses the term "operation". In this case, I think you can just say: 'Java Search' has encountered a problem. I.e., just remove the word "job".
Created attachment 91339 [details] Patch reviewed Krzysztof please mark patches that are obsolete appropriately. I removed references in Javadoc to ErrorDialog and TitleAreaDialog that are not valid. Moreover I changed modifiers of some methods to private since they should not be visible. Please, update javadocs in WorkbenchStatusDialog and remove final modifiers. This class is not intended to be subclassed so the modifiers are not necessary.
Created attachment 91363 [details] Two more 'final' removed
Just wanted to add my 2 cents. I haven't seen the proposed solutions yet, but I wanted to be sure it's not forgotten that the Jobs API is an important part of RCP applications as well. So comments on the bug about the information presented to the user being non-technical (up-front anyway) is extremely important to me- it really depends on the audience, for Eclipse users we're mostly technical; for RCP users, they're mostly non-technical (at least not w/ Eclipse).
Szymon released last patch today 5th March 2008.
28-03-2008 verified using described test scenario
