views:

56

answers:

4

I have a winform software that communicates with hardware through a protocol.

Sometimes error in communication happens and i would like to notify the user. Errors could be for example: timeouts, crc errors, physical disconnection etc...

I have a communication window in which i show these errors, but by default this is hidden. The user can open it though the menubar.

Popups are annoying to the user (and to myself) so i would like a un-invasive way to notify the user that an error has occurred. Perhaps a info bubble like when XP tells you updates are ready for your computer? I know that NotifyIcon can help put things in the system tray, which i do not wish to have. I'd rather keep it within my MDI.

I'm open to other creative ideas as well.

+1  A: 

One (relatively) common paradigm is to place a message on the status bar ("[x] New Messages"), and make the appearance of the message window a user action.

TreDubZedd
+1  A: 

If your MDI window is open/visible, then you could have a comms status icon on it - this would be green when everything is fine, orange for warnings (like corrupt packets have been detected, but comms is still working and the system has recovered), and red for errors (like no decodable comms received for 5 seconds). This allows it to be fairly subtle when things are wokrking, but quite noticeably "different" is a problem occurs.

For a serious error (e.g. disconnection) you may want to get more "invasive" because there comes a point where not bringing the problem to the user's attention is worse than bothering them with the error report.

If your window is not guaranteed to be visible then (despite your dislike of the idea) a system-tray icon (to show this status) is a standard and rather clean solution - it can be permanently visible or simply appear when it is relevant, it's about as non-invasive as you can get while still bringing information to the user's attention, and easy for the user to check periodically to reassure themselves that they have a "green light".

An alternative to visual indicators is to use audio alarms.

(For example, we use a monitor on our build server. It simply has a green icon when the builds are good, and a red icon if a build has failed. This is perfect, as it doens't bother me at all but I can check the build status in an instant.

Alternative example: I have an email app that shows an "envelope" icon in the system tray when I have new email, and nothing if I don't. In practice with this system I notice pretty soon (within a minute or two) when mail has arrived, but I am not bothered by constant popups or message boxes.

I think these are both examples that show how much better a system tray icon is than a popup or balloon window. Popups are irritating and with most of them if you aren't watching when they appear, you miss the information. I'm forever spotting popups just as they disappear and then having to open the app to find out if they were telling me anything useful. Which usually they weren't. The same goes for audio notifications: I keep hearing random noises from my IM application and wonder what the heck they mean).

Jason Williams
+1  A: 

There are several alternatives that can be employed when an error occurs, each with their own advantages and disadvantages:

  1. MessageBox popups
    Display a message box popup to the user.
    Advantage: since it is modal, the user has to acknowledge the error to continue.
    Disadvantage: since it is modal, it interrupts the user from whatever they were doing. Multiple errors are also inconvenient, requiring multiple confirmations.

  2. Show the communication window
    If your existing communication window is hidden, display it to make the logged error visible.
    Advantage: uses the existing familiar communication mechanism.
    Disadvantage: if the user does not really care about the errors, it could be annoying that the communication window continually reappears.

  3. Status bar messages
    Show messages in the status bar of the application.
    Advantage: will always be visible on screen, but is "out of the way" of the main window.
    Disadvantage: hard to display multiple messages and may be missed by the user.

  4. Balloon notifications
    Show an Outlook/MSN Messenger style notification message near to the notification icons.
    Advantage: is obvious enough for a user to notice, but does not necessarily require a notification icon. Could also collate multiple messages into a single popup.
    Disadvantage: could be annoying to the user.

  5. Notification icons Show a notification icon (perhaps with a balloon notification).
    Advantage: is obvious to the user, but still unobtrusive.
    Disadvantage: is yet another notification icon to clutter up the user's desktop.

Personally, I would choose option 2 as it requires the least amount of effort to achieve. If it is unacceptable once people start to encounter it, review the other alternatives.

For examples of balloon notifications that do not require a notification icon, see this for Windows Forms and this for WPF.

adrianbanks
Wow a very complete and informative post. Thank you. Since this is communication and i can/will get an incomming msg every 250ms i will not opt for 2 since it would constantly popup. #4 The Balloon notification is the most likely solution at the moment.
Lily
A: 

Depends on your scenarios: If the event requires user interaction to resolve, then a modal dialog may well be the best approach because you can't continue until the user, for example, inserts the device into a USB port (or whatever).

For other unusual notifications that the user may need to be aware of but may not disrupt the workflow, I suggest using an in-app popup-toast or updating the status window.

If the user doesn't need to change/interrupt what they're doing, then don't warn/notify them: your device and app should "just work" - the user should only be interrupted if there's something that truly requires their attention or that will cause them disruption "soon".

bitcrazed
Yes this is my view as well, since whatever the error, the application either recovers by itself or, in the case of a disconnected cable, the user needs to replug it. Unfortunately, i have client requirements to fulfill.
Lily