When building a large project in maven with many dependencies and snapshot-update check is performed, the process takes a long time, during which I switch to work on something else. Making the title of the output window "bold" during the build process and then "regular" upon completion is not enough to draw attention. I suggest to play a sound indicating a successful/failed build.
Product Version = NetBeans IDE 7.1 (Build 201112071828)
Operating System = Windows XP version 5.1 running on x86
Java; VM; Vendor = 1.6.0_23
Runtime = Java HotSpot(TM) Client VM 19.0-b09
This opens the more general question of handling lengthy operations and their output in panels below main editor window. Especially with respect to build process and test-run process users often prefer to get an unobtrusive but clear notification about the state of the process. The convention currently accepted is to not open respective output windows (if they are not already opened) unless a problem needs to be reported. This approach is followed because it leaves the workplace unchanged and available for further work when a lengthy operation is started. However, this is often perceived as inconvenient by those users who prefer to stay informed in detail about the state of the lengthy process even if there is no failure to be reported, and they miss clear notification of the end of the process. Therefore the following ideas need to be considered:
- header emphasize - by default all headers are black. Only for windows that contain output of a finished lengthy process display header text in a) green in case of success, b) red in case of failure. The color is reset to black immediately when the window is brought to front (user clicks the header or navigates to the window in other way or the window area gets focus)
- more info in statusbar label. When building, display project name + main called target + currently performed sub-target. When testing, display project name + number of tests passed/remaining + current test name
- decent beep when lengthy process ends, different for success and failure
- consistent behavior of passing focus when the window is already open (but being not the one with focus). Starting a build currently does not change focus of the respective Output window; for running tests it seems logical to follow the same convention
- improved navigation between these output windows under the main editor area. Because some of the output windows do not have direct shortcuts (e.g., Test Result), it would be good to have a shortcut for cyclical switching between those output windows that are currently open. I am not sure whether such option exists now, but certainly it is not discoverable
(In reply to comment #1)
> header emphasi[s]
Interesting idea. Would probably not be too hard to do, though requires an API change.
> When building, display project name + main
> called target + currently performed sub-target.
Perhaps. Currently the subtarget is left to the detail area visible e.g. when you select Window > Processes. Showing it in other circumstances might make the label too wide; and anyway as a UI principal we do not generally change the progress handle label constantly.
> decent beep when lengthy process ends, different for success and failure
BTW I have played with this: https://bitbucket.org/jglick/nbsoundlogger/
> some of the output windows do not have direct shortcuts (e.g., Test Result)
> it would be good to have a shortcut for cyclical switching between
> those output windows that are currently open
I do not think so; they might have been docked into other modes, etc.
(In reply to comment #1)
> Comments welcome.
- another approach could be to use floating notifications
they are clickable, so it is easy way to go into TestResults view and Output View even for finished processes
Btw, another comment:
- Output of build is available from context menu of build progress bar
- Tests view is not available at all
I like all of Petr's thoughts, but agree that this needs to be part of an overall progress and long-running notification strategy. I know that we've got some initial work going on in both areas for JDeveloper so we'd want to leverage that as much as possible.
To the initial enhancement request, though, I would combine a bubble notification with a subtle auditory cue. Think of the sound that iTunes makes when it finished synching or burning a disk.
Just thinking about a generic UI for setting lengthy process notification behavior. In Options dialog such a thing would fit either in General or Miscellaneous, as it might potentially relate to IDE-wide events. Miscellaneous is overcrowded, General has no tabs at all. Isn't it time to introduce tabs in General category? The current options from General would fit to General->IDE_Setup or so, what would open the possibility to add a tab General->IDE_Notifications or so. This would contain a list of actions that would permit notification on finish. Examples of what types of actions the list could roughly contain:
- build finish with errors
- build finish without errors
- test finish with errors
- test finish without errors
- background update finish
- inspect/transform refresh finish
- search results refresh finish
- (re)scanning finish
- application run finish
For each item in the list it would be possible to specify
- specific alarm sound
- floating notifications (option: length of display in seconds, optinaly unrestricted thus requiring user confirmation?)
- bringing in focus the respective output window (options: only if window open, or always; valid or not when the window is minimized)
- temporary tab title coloring until any user action on the tab
- output of timestamp to specified logfile ?
Actually a notification UI like that could probably be also interconnected with Action Items - if the user were allowed to assign priorities and time plans to Action Items, then the notification UI would define what happens when a deadline is coming close, or some high-priority action item with no deadline set has been ignored longer than others etc..
I like where you are going with this, but I think that your proposal might actually offer a little bit too much flexibility. If we were the chunk the different events we notify on into no more than 3 or 4 categories, what would those categories be? Also, I think that we can probably come up with reasonable default actions for each event, based on how important it is to get the user's attention. We want to avoid looking like the Microsoft "clippie" paperclip here. :-)
Created attachment 118873 [details]
proposed introduction of tabs in General options category
Created attachment 118874 [details]
proposed Notifications tab in General options category
For NetBeans 7.2 we need to settle on a subset of the discussed ideas as soon as possible. Therefore I propose this:
Make the General category in Options dialog contain three tabs (see attachments). The tab Settings would contain the original contents of General as they had been till now. The tab Windows should be moved here from Miscellaneous category, as it has IDE-wide implications. (Miscellaneous should contain only stuff that is not general but does not fit to other existing categories.) The third tab Notifications is the only new tab. It contains a list of events for which there will be the option to define two types of notification - by the bubble notification window that appears for a short while and/or by sound. Bubble notifications are enabled by default, sound notifications are disabled by default (some users are strongly against being distracted by sounds, although many consider it useful). For 7.2 the list of events is restricted to Build Success, Build Failure, Test Success, Test Failure. The list can grow in future. If a sound notification is enabled, there is a choice of default or custom sound. We don't have a dedicated sound for "default" available at this moment, but initially the pop.wav sound in collab.ui\src\org\netbeans\modules\collab\ui\sound would do as it is a reasonable compromise between notability and unobtrusiveness. Another choice could be javafx2.samples\Xylophone\src\xylophone\Note1.wav but for that I am not sure what are its usage restrictions.
Can we agree on this, taking into account that 7.2 deadlines are quite close ?
(In reply to comment #8)
> proposed introduction of tabs in General options category
Then you might as well break the meaningless panel "Settings" into "Browser", "Proxy", and "Statistics".
We are well after feature freeze - surely nothing like this can be considered now for 7.2. Would also require various new APIs.
BTW the Files tab from Miscellaneous should probably be moved to General too.
(In reply to comment #11 and comment #12)
I agree it is quite late for far reaching changes. If Tonda agrees, let's postpone this; it seems difficult to find simple enough way of resolving even a part of this issue in 7.2.
As for possible changes in Options, it seems we agree that General is well suited to gather anything that has IDE-wide implications, while Miscellaneous is suited to gather more specific bits and pieces that do not fit to other categories.
I agree Files also fits to General in this respect.
Browser, Proxy and Statistics do not fit together too well, and splitting them can make sense (I am not too happy about tabs with almost empty panels but it is probably better then mixing apples and oranges). Yet isn't there a reason for them to be packed together ? I mean it looks as if they were intended to be shown at once as the first thing to see in Options panel ? I expected some such reason so I tried to invent a suitable compromise tab for them to preserve the grouping...
(In reply to comment #13)
> Browser, Proxy and Statistics do not fit together too well, and splitting them
> can make sense [...]. Yet isn't there a reason for them to be packed together?
None that I know of except that the last UI designer was afraid of making General a container panel.
Proxy is probably the most commonly changed thing there, for people for whom system settings are unreliable (esp. since currently the IDE does not track ongoing changes - filed separately). Browser should be OK at the default setting for most users. Statistics is normally something you would be prompted to enable on second start and probably do not care about afterwards.
(In reply to comment #13)
> I agree it is quite late for far reaching changes. If Tonda agrees, let's
> postpone this; it seems difficult to find simple enough way of resolving even a
> part of this issue in 7.2.
Though I wanted to have this resolved now, I agree it is better to resolve fully after 7.2 rather than partially now.
> As for possible changes in Options, it seems we agree that General is well
> suited to gather anything that has IDE-wide implications, while Miscellaneous
> is suited to gather more specific bits and pieces that do not fit to other
In my view also IDE-wide settings which are rarely changed can be "hidden" in Miscellaneous. I think Options dialog looks cleaner and more polished if General tab includes only a few "promoted" options. But this is just my aesthetic feeling about the dialog's content.
> I agree Files also fits to General in this respect.
IMO the Files settings need to be changed by a small percentage of users. In such case I like these settings more in Miscellaneous. But maybe it is used by much more users than I thought.
(In reply to comment #15)
Regarding the role of General Options I would be interested in Rich's opinion. My proposals were led by the simple logic (IDE-wide vs. not-fitting-anywhere) which more or less ignores other possible concerns, like the one pointed out by Tonda about the perception of General as the place for the limited number of the most important options. Rich, can you comment on this ? (is there anything known about what is actually perceived as the better approach from general user's point of view?)
Most if not all IDEs have a "general" area where IDE-wide settings reside. It isn't always called General, and even more to the point, it becomes a catchall for weird stuff that couldn't be described as General (which is what appears has happened here).
I'd like to familiarize myself with the Preferences dialog in general and come up with a list of possible improvements to the information architecture of it. Moving forward the Preferences dialog should have some prescribed guidelines for what gets added where, meaning:
- what qualifies as a top-level node
- what qualifies as a subtab
- what is truly "general" vs. "just visiting until we have a better place for it".
I realize this is a larger question than the bug we're discussing. If I'm reading the thread correctly, we are deferring on the notification settings until post 7.2, right?