All of these UI components are containers/windows that show on top of the content you are currently viewing/interacting with. The different names are based on the attention they deserve, the context you're in, and how you can interact with them.
Alert - These messages need immediate attention. The window/container is usually locked, meaning you can't ...
I hate it when a modal dialog appears asking me to confirm an action and the only way I can confirm that, yes, this is the record I want to delete, is to view the information underneath the immovable dialog.
I usually have to cancel, double check, then click again.
Or, consider this scenario:
Hey Mr. Team Leader, there's this case I'm working on and I'm ...
Usually the downsides outweigh the upsides
i.e. usually the answer is "no"
Here are some of the typical considerations with movable modal dialogs. Note that some of these verge on implementation issues, but I've included them anyway because they all have usability impact:
Moving the modal requires a lot of cognitive load. The user has to find ...
In my opinion it would be better to distinguish between creating and editing the business object.
For creation a wizard is fine. Besides the next button it could also have a finish button if the current and all following wizard pages only had optional information as input.
For editing an existing object a tabbed dialog could be a good choice, since allows ...
If a popup confirmation is so uninformative that a user might need to move it out of the way to decide whether to proceed, then the problem is a bad popup, and allowing it to be moved is not solving the core problem.
Assuming you really do need a popup that comes before the action and fills the screen, to get an informed response from the user before ...
In general, I use the following guidelines for using modals:
Is it focused? Every time you throw a modal in front of a user, you're disrupting their workflow. Disruption isn't always bad. Sometimes that's what you want. But you have to realize you're doing that and use it for your benefit. Items within a modal should self-contained. A good rule of thumb is ...
I would say that this often leads to an unwanted drag and drop action. What if this window for example has a small scrollbar, you want to scroll to the bottom of the page and you accidentally miss the scrollbar? You would drag the window down and you might need to reverse this action.
Why is it uncommon that windows can be moved by clicking anyway in the ...
It may be redundant, but independently of this the real concern should be to evaluate if this redundancy is beneficial, harmful or neutral.
Different goals, different designs
Do you need a confirmation modal or just an informative one?
Confirmation: To start with you'd need a OK/Cancel pattern which will offer a clear binary option. You could avoid the X ...
Showing a full page modal window on mobile devices means users may confusedly think they’ve been taken to a new page.
Modal windows are typically boxes which contain information relevant to the current page but which don’t require the user to leave the page they’re on to view that information.
Considering these facts, I think, it would be best if we ...
A tenet of good user experience in software is system feedback. In this instance, the system should confirm it will no longer show you notifications... which is a good place to offer an undo option, as well as tell them where they can change their preferences.
I recognize that the web leads to its own problems because it is platform independent, but if most of your visitors are Windows users than using Windows standards might make sense. Here is one page from Microsoft on UI design.
User testing would really be the best option in this scenario. This may be common knowledge to everyone here but I'd recommend the ...
Keep the Finish button
There is nothing wrong with the Finish button because it provides an exit shortcut for users who want to save and finish the process early. Otherwise, users who want to edit just the first page of the wizard, should click 4 times next until they can save and close the form. That's 4 unnecessary clicks.
Add a Stepper progress bar
My answer would be to synopsis the question of the modal form, so with the question being:
You are leaving the question with unsaved changes
The title would be:
It's a pattern I've seen and used regularly, it's brief and informative.
In terms of mobile,
A mobile screen does not have the space to fix your problem by moving the popup. You can move the modal window and still not see the information you want to because it has limited space.
A popup usually covers the information below by a black overlay so that it stands out. Just moving the popup won't be enough then. You will have to get ...
If you're going to make the choice for the user, I'd suggest using "Resume" since it's much easier for the user to revert back to the start than it is for them to find their place in the video.
An alternative is to give the user the choice. For example for an unwatched video the option is "Play" and for a partly watched video you use both "Resume" and "Play ...
It sounds as if you are seeking a formulaic answer about a specific button pattern fit for an exclusive purpose and feel that this goal is not being met.
Straight off the bat, there is no such formula. But here are a few things to consider.
Link Buttons Are a Thing
Text-only, rimless buttons have become a fairly common interface element without being ...
The "OK" button has the wrong word.
It should be a "Continue" button, as this is what's required of the user. The user is being asked to acknowledge they're aware of the nature of the warning, and that they'll be continuing without a current reload/refresh of the data.
It is not OK that the data didn't load, so there's a needless cognitive dissonance ...
The title bar isn't always the only spot to that can be used to drag the window, (these days some windows can be dragged by parts of their background, but it's rare) but it's the oldest and most established and common convention. It originated in the early WIMP UIs, the Smalltalk systems from the 70s and 80s.
If you study the way the above windows were ...
As you have pointed out, the double click is not a standard behaviour that your users are familiar with in the situation you are describing.
It's not good practice to use non-standard interactions where you could use a standard one.
Irreversible actions (such as deletion) are usually followed up with a 'sanity check' like "Are you sure? [Yes] [No]".
Something I have gone with in the past is to takeover the whole screen for modals. We built a responsive modal so that on desktop you see the modal in a more traditional overlay, but on smaller viewports the content of the modal takes the place of the whole screen.
Something like the 'JUST ME' example here: https://tympanus.net/Development/...
This is actually not always true. In some cases the default behavior of most apps would be to allow to drag windows by empty space. An example is KDE. See the screenshot:
KDE's default Oxygen widget style has window decoration visually merged with window contents. Thus, to make feel match look, the theme also by default allows to drag windows from all empty ...
There is a section of WCAG 2.0 dedicated to this. 2.1 Keyboard Accessible.
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires ...
I've been thinking a lot about "confirmless deletes" because of a behavioral issue with models that is outlined here.
In short, most users actually intend to delete an item when they initiate the interaction, so throwing up a traditional confirmation is annoying most of the time.
I totally agree with Lauren's answer on the basic ...
Exporting data can be more time consuming
Ultimately it depends on how your users feel about it but exporting data requires users to think more and can add friction to their work flow. If I could only choose one option or the other I would go with option 1, however, export to Excel sounds like a very useful function so consider the following example.
This area is normally giving you information on the type of question being asked (at least in my experience), so the question mark feels like the dialog is questioning itself.
I'm a "Save Changes" dialog... or am I?
The Windows OS provides the (optional) title bar and control box, as well as a mechanism for OS users to organize their application windows (re-positioning, minimizing, maximizing, closing).
From the perspective of the Windows OS, the title bar is the user's API for these operations. Everything else in the window is "content" that is under the control of ...
In my experience, modal windows are best used to present clear interactions that the user either:
needs to do (e.g. resolve an alert)
has chosen to do (e.g. open a photo gallery).
Resolving that interaction should close the modal, and there should already be a control in place that does that.
This is because modal windows interrupt the user flow and break ...