Date: 12 DEC 2012. Authors: Petr Somol, Jan Peška


NetBeans Notifications Handling after 7.3

Various notifications keep appearing while using the IDE, mostly in the form of bubble pop-up in bottom right corner. Those to which the user did not respond are collected in a simple list accessible by a strangly looking little icon in bottom right in the status bar (to the right from progress-bars). Once an item in this list is clicked, it's message is displayed and the item is removed.

A considerably more practical and centralized handling of a wider spectrum of messages can certainly be defined. In this document we attempt to propose how to better deal with messages, and what extent and types of messages to consider.

Remark: To keep the IDE in good shape we introduced an updated UI Review process (NetBeans 7.3+). See UIReviews for details.

Proposals for new notifications

  • Task Management
    • incoming changes in the Task Dashboard
    • scheduling
  • IDE Exception - if a user ignores an exception at first she can review it in Notifications TC and e.g. report it
  • Recommendations (show just once?, should be possible to switch off)
    • Tips and Tricks, context sensitive - related to the currently used project type only?
    • What's New - same feeds as in the Startup window

Current NotificationDisplayer clients


  • Autoupdate
    • Plugins available
    • Plugins warnings
    • Updates found
    • Restart needed
  • VCS
    • Files changed notification
    • Install warnings (git)
  • Hudson - Job result
  • Kenai
    • New or changed bug
    • chat notifications
  • Maven - build failed
  • Export options status
  • Slowness reports
  • Low Memory to compile
  • DB - multiple installations of MySQL found
  • Remote Connection
    • Reconnect needed
    • Error while connection
  • Window system - restart needed
  • CND
    • FS clock skew warning
    • Remove changes on file
    • Remotes updates result
    • Code Assistance setup
    • Project problems

Key Questions

Name :-)

"Messages" or "Notifications", I'm not sure which one is better. I'm going to use the term "Notifications Center" until we will decide.

Rich: I think notifications is a broader term and thus better. Messages has the chance of being construed as something coming out of the log or output.

Do we want the entries of the Notifications Center to be interactive?

It would be very useful if entry (but not necessarily every entry) provide a details panel containing addition info and/or some actions. It would complicate the API but without the interaction the Notification Center would be only a list of titles and time stamps.

Honza's suggestion - Yes, entries should be interactive i.e. it should contains details panel with additional info and/or actions if it makes sense.

Rich: My assumption was that this would be a master-detail UI-wise. The master list could just be the type of notification, a terse description, and timestamp. The details area could show more "rich" content like links, icons, etc.

Honza: Yes, that is what I meant.

Who should be the client of this API?

Right now there are few components (APIs) providing notifications and messages to the user, e.g. Progress API and Notification Displayer (popup bubble). Since most of the messages/notifications we are interested in pass through these components it would be useful to use them for forwarding messages to the Notifications Center.

Honza's suggestion - Yes, we should definitely use existing APIs for "forwarding" notifications and messages to the Notifications Center. We don't want to make client of e.g. Notification Displayer API to use another API to log the notification. But we will probably have to do some API changes, e.g. in Progress API we most likely don't want to log every progress event so there has to be some king of flag whether to log or not to log the event.

Rich: Agreed on using standard APIs. Are those APIs capable of allowing the notification sender to classify the notification in terms of priority/severity and persistence? See below for more details.

Honza: Well, as far as I know Notification Displayer is only API that can provide priority. Persisting is not contained in any of them - API changes would be necessary.

Do we want to persist entries?

Do we want to persist entries between IDE sessions or should we display only notifications from current session?

Honza's suggestion - I don't see an added value of persisting entries between sessions since I don't think the user would like to see e.g. a slowness report notification from two days ago. Also we have to operate with limited set of entries (memory issue, UI responsivity). Another problem is that we can persist textual information but what about details panel provided by API client. So I think we should display only notifications and messages from current IDE session

Rich: I think this depends on the notification. If it pertains to a condition that persists between instances of the IDE, we should be able to persist it. As stated above, the notification sender should be able to specify this by API.

Honza: Right now we have a simple usecase: User misses a notification so she wants to retrieve it somehow just to take a look what was it. I believe that for this usecase we don't need persisting at all. Question is if we have some more complex usecases where a persisting is needed. I've done a little research about clients of the Notification Displayer (see #NotificationDisplayer clients for more details). All these usages seem to have tight relation to the current state of the IDE so the info loses its value over time.

Stan: Isn't 'failed Hudson job' or 'P1 issue update' an important message that user would want to have available even after IDE restart? I know that this kind of info is available elsewhere in the IDE but the Message window would keep such messages grouped together so it would be easy to check if there's anything wrong in a single glance...

Honza: After a offline discussion with Stan, we've agreed that a persisting is not doable - we are simply not able to persist interactive parts of the details panel i.e. actions provided by API clients. Anyway in case of Hudson there would be also a problem that most of the older persisted notification would be outdated (job status is changed, etc.). So I believe that the best practice for a user is to use Hudson support as a starting point.

Entry Expiration

The current notifications API removes an entry either when it's garbage collected or upon API client's request. We should consider some sort of retention policy to avoid memory leaks. If the Notifications window holds all entries indefinitely it might hold references to closed projects, files in the 'details' part of each entry (which the Notifications window will have no control of) thus creating memory leaks.

Functional specification

I just want to summarize required functionality of the Notification Center.

  • master-detail UI with a list of notifications/messages
  • main entry contains: priority, timestamp, title (message) and ??entry source (notification, progress, status line)??. Content of details panel is provided by a client of the API.
  • filtering: full-text, filter by a source/provider - saveable filters would make sense similar to a e.g. Action Items
  • option to disable notifications popup - as a reaction to the Ashwin's concern I've come up with proposition: add an option to disable the notification bubble popup but notifications are still logged in Notifications Center. It is true that with future development of the bugtracking/task dashboard the increase of the number of displayed notifications can be expected. So it could be useful for users to turn off popups and keep track of notifications only using Notifications Center.
  • ordering: by default most likely order by timestamp, but it could be useful to enable ordering by other attributes too.
  • a button to remove all/selected entries

Notifications Center - "Notifications" Dockable Window

It might be practical to provide a standard dockable window that would provide filterable lists of all message types considered above.

Rich: this is what I had in mind in terms of a UI.

UI Specification

Notification Framework

In order to prevent "chaos" in the notification center, there needs to be some rules built into the APIs for how providers add notifications to the notifications center window.

These rules include specification of:

  • Required: Notification short description. 4-6 words giving a high-level overview of the notification
  • Required: Short Category Name. 2-3 words detailing where the notification is coming from, or the type of notification it is.
  • Optional: Priority. Default is "low". The other alternative is "critical" or high priority. Low priority notifications are momentary updates on changed state, process completion, etc. Critical priority is for notifications that could cause data loss, system or IDE instability, and the like.
  • Optional: Lifetime. If the notification concerns a state that will expire at a certain point, the provider should be able to specify a lifetime. In absence of this, the notification will persist until dismissed or until the end of the IDE session.
  • Optional: Long Description. The long description is what appears on the right-side "details" area of the notification center when the user clicks a notification in the left-side "master" list of notifications. In absence of a long description, the right side should read "No further details are available". The long description should support rich text or some sort of stylistic markup so that name/value pairs and other formatting can be shown.

UI Mockup

The following mockup shows a visual example of the Notification Center window.


Details on the mockup:
  • The filter and grouping controls on the left mimic functionality from Netbeans action items window. The grouping control groups by Category. Customizations to the filtering control is described below.
  • The grid shows, in order, the Notification short description, the time-stamp when the notification was sent, the priority, and the category.
  • There is a quick search/filter box above the grid that should be able to search/filter on any grid column.
  • The grid should be sorted by priority first, with high priority items showing at the top.
  • The details area on the right shows, in large text, the short description. If it is a high-priority notification, it should be decorated with an icon like the one shown. It should then show the long description if available. At the bottom should be the category and the long-form date and time.
  • Timestamp, when in long form, should be in "friendly format", as per the following algorithm:
    • Up to one hour in the past: show as "nn minutes ago"
    • From the beginning of today to 1 hour in the past, show as "Today at HH:MM, AM/PM"
    • From the previous day, show as "Yesterday at HH:MM AM/PM"
    • From the 5 days prior to yesterday up through yesterday, show as "(Name of Day) at HH:MM AM/PM", e.g. "Monday at 8:13AM"
    • Prior to one week in the past, show as "(Short Month Name) (Day-numeric), Year at HH:MM AM/PM", e.g. "Feb 24, 2013 at 12:37PM"
  • At the top right of the details areas should be a Close button for dismissing the notification.
Filter Customizations

The UI for filtering the notifications center should function significantly like that of the Action Items window. The following tweaks need to be made to customize the Filter dialog for use with the notifications center:


  • Callout 1: The Types list should be populated with the known notification categories.
  • Callout 2: There should be one pre-defined filter type for showing only High Priority notifications.
  • Callout 3: Since we have a quick search in the window itself, the Keywords tab can be removed.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo