UEXNotifications

(Difference between revisions)
(Do we want to persist entries?)
Line 93: Line 93:
''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...''
''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.''
==Notifications Center - "Notifications" Dockable Window==
==Notifications Center - "Notifications" Dockable Window==

Revision as of 08:34, 29 January 2013

Date: 12 DEC 2012. Authors: Petr Somol, ...

Work in progress, subject to change.

Contents

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.


Notifications and Messages

  • Warnings, like those that appear now in bubbles, e.g.
    • Slowness,
    • Low Memory
    • etc.
  • Notifications on Lengthy Operations, e.g.
    • timestamps of started and finished builds, runs,
    • scan finishes, starts or restarts,
    • timestamps and names of opened or closed projects
    • finished updates
    • history of IDE starts/finishes
    • etc.
  • structured IDE Log - now it can be accessed as text through View->IDE Log
    • separate view of logged exceptions
  • 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, context sensitive - related to the currently used project type only?

NotificationDisplayer clients

FYI:

  • 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

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.

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.

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