HMI - annoying pop-up windows

Article#: 00108

Date: 2025-02-09

Author: Radim

Have you ever experienced this? You want or need to complete a task, but annoying pop-up windows keep appearing on your screen. They distract your attention, obscure important information, and generally slow down your progress.
Unfortunately, this is a common issue with some HMI systems, and it's not just frustrating - it can be downright dangerous in certain situations. For example, if a user is in a critical scenario where quick and precise intervention is crucial, unnecessary distractions could lead to catastrophic results.
But does this mean we should do away with pop-up windows altogether? Absolutely not! When used correctly, they can be an invaluable visualization tool.

So, how can we ensure that pop-up windows are helpful rather than counterproductive? Below is a list of "Don'ts" and "Dos" to keep in mind when implementing pop-up windows.

1. Don'ts (what to avoid):

1.1. Do not use pop-up windows for ordinary notifications.
Ordinary events (e.g., "Parameter changed" or "Maintenance required in 30 days") should not disrupt the user's workflow with pop-up windows.

1.2. Don't obscure important screen information.
Pop-up windows must never cover important machine control and status information. User should not be allowed to move the pop-up window either to avoid covering up important screen information.

1.3. Avoid displaying multiple pop-ups simultaneously.
Situations where multiple pop-up windows layer on top of each other create chaos, confusion and often result in the operator ignoring all the messages.

1.4. Don't repeat the same message unnecessarily.
If the operator has already acknowledged a pop-up, the system should not continue displaying the same message (e.g., for an ongoing error). It is particularly bad when the pop-up windows that keep appearing take control of the active window and take the cursor or the input field away from the user.

1.5. Avoid technical jargon.
Steer clear of cryptic messages like "Error code 0x8000F!". Operators need to know exactly what happened and what actions to take.

1.6. Do not use pop-ups for information that the user wants to call up again with the "Back" button.
A pop-up window is not a visualization page and won't appear when the user navigates back to the previous page.


2. Dos (best practices):

2.1. Pop-up window does not disturb if it was triggered by the user.
Examples include:

• Logging in or out of the user.
• Confirming of safety-critical actions, such as starting/stopping a machine or machine part or changing a critical value.
• Confirming irreversible actions, such deleting important data, or permanently modifying a process.
• Notifying the user about the completion of an action running in the background (e.g. a process previously started by the user was completed successfully or with errors).

2.2. Use alternative notification methods when appropriate.
Instead of relying solely on pop-ups, consider other methods:

• Log events in an event log file.
• Use visual indicators ("eye catcher") to attract the user's attention and show them the way to the source of the problem.

2.3. Display pop-ups at predefined locations.
Ideally, define a fixed area for pop-ups in which they do not cover any important screen information.

© Radim-Automation, 2020–2025. All rights reserved.
Sharing of this article is permitted with proper attribution (link to the original page).

Related previous articles:

• HMI – Don’t hide anything
• HMI - back and forward navigation buttons
• HMI navigation
• HMI layout design
• HMI layout and correct display size
• Choosing an HMI display
• HMI is not a web page
• HMI - Don't overdo it with complex design
• HMI - Have a consistent style
• High Performance HMI
• Graphic designer
• Event logger as the very first function implemented in the program
• Talk to operators
• Design considerations for effective HMIS
• Are there also any disadvantages?
• Design machines with a focus on user's abilities and needs
• Collect all the requirements and sort them!
• Who will operate?
• Functional and intuitive HMI
• HMI and PLC applications should grow together
• More than just start and stop
• Safety first!
• Define test scenarios and test cases continuously!
• Don't make it worse!
• Realize every good idea ASAP!
• Industrial evolution - Listen to your customers and follow new trends!
• What does the customer need?
• Don't disappoint your customer!
• Ask questions!
• Don't hide any problem!
• Check the result!
• Keep it simple!
• Choose the right tool!
• Transparency and reliability

Related next articles:

• What makes an HMI intuitive?

Comment#: 00001

Date: 2025-02-14

User: Radim

Make sure that pop-ups are used sparingly, if at all. Nothing is worse than a cascade of error messages - all of which have to be acknowledged individually - before the operator can get to the screen where the condition can actually be resolved.

- Automation Direct. HMI Handbook - Practical Guide to HMI Selection, Design and Operation. (Page 20)
- https://www.automationdirect.com/ebooks/hmi-handbook

Comment#: 00002

Date: 2025-02-18

User: Radim

When good intentions become annoying:

While developing software for a glass coating machine, the customer requested a pop-up window on the HMI that would appear whenever the argon gas pressure in the gas cylinder dropped below a critical level, to prevent the risk of forgetting to replace an almost empty gas cylinder. (Argon, supplied from a pressurized cylinder, is used as the working gas during the sputtering process.)
At first, this seemed like a logical and effective solution - until the system was put into real operation. After a few weeks, it became clear that the constant pop-ups were more annoying than helpful for the operators. They reported that these alerts disrupted their workflow and caused frustration instead of serving as a useful reminder.
Based on user feedback, we revised the system: instead of intrusive pop-up windows, we implemented a standard warning, which remained visible on the HMI but did not require immediate confirmation. The result? Happier operators and a more efficient system. :-)

Comment#: 00003

Date: 2025-06-02

User: Radim

If a pop-up dialog is intended for making changes (e.g. editing settings or data), it should always offer the option to close it without saving those changes - meaning the state should revert to how it was when the dialog was opened.

The users should have full control over whether to confirm or cancel the changes.
They must be able to reconsider and discard the action without unintentionally saving any modifications.

Comment#: 00004

Date: 2025-06-04

User: Radim

A pop-up window possesses a key characteristic – it is not a full visualization page. It is not recorded in the navigation history, so it can't be recalled using the "Page Back" navigation button. After closing the pop-up window, the user remains on the same visualization page. This can be either an advantage or a limitation – depending on the specific situation.

This behavior should be considered already during the design phase of the visualization. A pop-up window is suitable especially in cases where a momentary value is being set, a one-time action is confirmed, or a context-dependent event is being handled. On the other hand, if the information needs to be revisited later, a dedicated visualization page is more appropriate.

(In some cases, help information can be effectively displayed in a pop-up window, as well as setting of configuration parameters or setpoints.)

Comment#: 00005

Date: 2025-06-13

User: Radim

When working with pop-up dialogs, it's important to ensure that live data remains up-to-date even while being displayed in such a dialog window. A common mistake is that the data "freezes" at the moment the dialog opens and stops updating. This can lead to users seeing outdated information, even though the rest of the application continues to function correctly. Dialogs must not rely on a disconnected copy of the data - they should always be linked to the "live source of truth".