Timeline for Should modal dialogs be movable?
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:51 | history | edited | CommunityBot |
Commonmark migration
|
|
| Jul 12, 2015 at 6:23 | comment | added | Craig Tullis | @tohster Agreed, except I'm going to bed. ;-) Note that I didn't say I necessarily like flat design, by the way. | |
| Jul 12, 2015 at 6:19 | comment | added | tohster | @Craig I agree with that last point...also your question around flat design is a good one though probably out of scope here so maybe we should take this up in chat. | |
| Jul 12, 2015 at 6:14 | comment | added | Craig Tullis | @tohster I would echo and agree with a sentiment expressed elsewhere here, that in far too many cases a modal dialog ends up being used where it really isn't the right solution. In other words, it might be the wrong design choice in the first place, and making it immovable exacerbates the problem. On the other hand, something like a logon dialog is its own context and is perfectly appropriate as an immovable modal dialog. I'm just saying that just because the designer has a hammer, it doesn't make everything a nail, and rigid thought even with respect to something like this is no virtue. | |
| Jul 12, 2015 at 5:55 | comment | added | Craig Tullis | @tohster Interesting, then, how modern Flat Design has been taking the world by storm (no "deliberate" depth or shadows, deliberate removal of 3D effects, etc.). All that stuff is so yesterday... ;-) | |
| Jul 12, 2015 at 5:53 | comment | added | Craig Tullis | @tohster and yet I see plenty of griping here about sucky non-movable modal dialogs, which tells me that part of the reason people aren't abandoning sites is just lack of alternatives. It's a little like presidential elections in Russia. Vote for anybody you want to, just as long as it's the party leader. Which does not mean the party leader is a great person or even particularly good at the job. Most OS's have similar underpinnings. Mobile touch OS's tend to have more lightboxy, modal popups, but the context is very carefully constrained--not true with far too many websites. | |
| Jul 12, 2015 at 5:52 | comment | added | tohster | @Craig actually it's well documented through cognitive focus and inattentional blindness studies that the area of visual focus is very small...often less than about 2 arc degrees in many situations. Also, users do in fact perceive different layers on a screen: that is also well documented for both windowed operating systems and also for browser CSS layers (watch the Google videos on Material Design for example). That's why modern modals are designed with deliberate depth (box shadows) and background masks, to amplify the existing perceptual behavior. | |
| Jul 12, 2015 at 5:47 | comment | added | tohster | @Craig browser modals and browser apps are cross-platform and need not comply with the way your OS works. A draggable modal in windows may not make sense in on a tablet or on a smartphone for a responsive site. You can (and should!) abandon any software whose usage you detest, but the facts work massively and overwhelmingly against your point of view here, because the vast majority of the most popular sites on the web do not offer draggable modals and users have not abandoned them. | |
| Jul 12, 2015 at 5:46 | comment | added | Craig Tullis | "re-orient visual depth to the underlying layer" seems like a red herring. There's only one focal length on a computer monitor, no need to re-focus. If the window is resized, just have a little JavaScript automatically reposition the dialog so it is still on-screen (not so hard). If the user wants to move the dialog mostly off-screen, let 'em. It's their computer. And I 100% AGREE that in very many cases, a modal dialog is probably a symptom of an underlying design deficiency. | |
| Jul 12, 2015 at 5:24 | comment | added | Craig Tullis | I actually detest UX's that force somebody else's aesthetics as an additional layer on top of the operating system's basic UX for the very reason that such constraints often end up suffering from the designer's or another involved party's lack of foresight, ending up crippling the user experience instead of enhancing it. The OS designers have spent far more time studying usage patterns and catering to usability. If your design makes me frustrated, I will find alternatives, and recommend to others that they avoid your product. So ultimately, it is indeed my choice. | |
| Jul 12, 2015 at 5:22 | comment | added | Craig Tullis | @tohster Respectfully, the designer deciding how I can and cannot use the machine is borderline obnoxious, sort of like all the "pixel perfect" web designs that predominated for a decade or so were mired in old print publication notions and were obnoxious. I guess what I mean is, it's my machine, my choice. If the UX is obnoxious enough, I'll choose a different product. By "I," of course I mean any user of the software. In the case of the immovable modal dialog, the failure of the designer to include necessary information would have been mitigated by simply allowing me to move the dialog. | |
| Jul 12, 2015 at 4:33 | comment | added | tohster | @Craig respectfully, it's the designer's choice and not yours, although you can certainly blame the designer :-) Choices around what to show and not to show are made with every single window, form, panel, widget, and label in a user interface. That choice is no different for a modal. Failure to show the right information in a modal is no different from failure to show that right information in any other window (e.g. causing you to hit a back button). The constraint is just perceived more offensively in a modal because the info is in the background, but the design choice is the same. | |
| Jul 12, 2015 at 3:21 | comment | added | Craig Tullis | Nah, complete horse-hooey. I can't count the number of times I've been presented with a modal dialog, then needed information that was obscured by the dialog in order to deal with the dialog, but couldn't move the dialog to see what was underneath, forcing me to close the dialog to reference the necessary information. If you're going to put a window on a screen, let me move the bleeping thing if I want to. It's my choice, not yours. Respectfully. | |
| Jul 8, 2015 at 21:19 | history | edited | tohster | CC BY-SA 3.0 |
expanded comments on downsides of movable dialogs, given comment thread
|
| Jul 8, 2015 at 17:09 | comment | added | tohster | @JDB I agree. While UX design should ideally be independent of implementation, the reality is that implementation constraints frequently dictate UX choices, and modals are an example of this happening even with world class companies (Google has 7000+ engineers!). As you suggest, modal dialogs are often the result of bad upstream information/workflow design: that upstream design is actually the first place to look when confronted with this decision. BTW i enjoyed reading your answer too (+1) | |
| Jul 8, 2015 at 15:50 | comment | added | JDB | The first two and fourth reasons you've provided have more to do with implementation errors than with the UX of a movable dialog. Those scenarios should never happen, but I've seen them happen even with immovable modals. The third and fourth points are good encouragements to stop and ask whether a modal is actually the correct solution (it often is not). Modals are overused and oft abused shortcuts to cram as much functionality onto a single screen as possible. I've seen modals launching modals launching modals (3 deep!). | |
| Jul 8, 2015 at 6:45 | comment | added | JDługosz | I like page modal because it's a layout of a page contained in a larger presentation element, and its common use in web pages. | |
| Jul 8, 2015 at 5:55 | comment | added | trlkly | @JDługosz I'd probably go with "page modal." Though I guess "tab modal" might work--assuming the web app doesn't have tabs of its own. I thought of keeping the preexisting "document modal," but that is supposed to include any window working on a document. Plus, the web app may have a further document inside of it. | |
| Jul 8, 2015 at 5:48 | comment | added | JDługosz | P.s. I see he did specify he was asking about a web page. I mean to point out only that a "fixed" inside another movable/sizable window is a distinct concept. We have system-modal and application-modal, and this is a further specialization of application. I think there must be a name for that. | |
| Jul 8, 2015 at 5:39 | comment | added | JDługosz | You are assuming that the modal dialog is part of a browser window, whichnis itself a full separate program. You talk about browser, site, etc. In this case, the dialog is embedded inside another window and that causes complications. And also in that case, the user can use apps other than the browser (or tab therein) to do something before adressing the dialog. I read the question as partaining to desktop windows, which clearly has different considerations. | |
| Jul 7, 2015 at 22:39 | vote | accept | Manfred Moser | ||
| Jul 7, 2015 at 21:34 | comment | added | tohster | @ManfredMoser I'd have to understand what your users are saying. Typically some fraction of users will complain with most UX changes, even for the better. That doesn't mean the decision is a bad one (e.g. lots of users hated the move from command line email to graphical email), but I'd need to understand more. Try to figure out why exactly users are moving the dialogs...and whether there is an underlying UX reason you need to fix first. If your users are vocal then they won't mind having you observe how they use the movable dialogs. | |
| Jul 7, 2015 at 21:16 | comment | added | Manfred Moser | Currently they are movable and we had objections from users when locking them down. Seems like this points to a wider usability problem. Would you agree? Can you elaborate on reasons to take the movability away? You already mentioned a few problems with them being movable. Ohers? | |
| Jul 7, 2015 at 20:24 | history | answered | tohster | CC BY-SA 3.0 |