This is a nice modal, but I'd much rather never have a modal ever. The only time a modal should appear is if a critical error occurred that the user must know about immediately. For most cases where modals tend to get used, like on iOS "please rate us", or "we want your contact information now", I don't think it is appropriate at all.
It's a forcible interruption of whatever the user is doing, and the user has to interact with it before continuing. As such, it should be used only when there is something that needs attention immediately.
If it's used for collecting user info after they hit a signup button, that's marginally acceptable, but they would still be unable to, for example, scroll back up the page to double-check some info until they finished with it. So I see popups like that as a failure of design; "I didn't know where to put this, so, here. Modal."
What modals are actually used for in the majority of cases I've seen is making modal popups begging first time visitors to register for websites and similar. This task is neither urgent nor necessary (nor, in most cases, desirable) for the users. Forcing them to interact with it before the rest of the page is incredibly irritating, but that will never stop because it's more lucrative.
> As such, it should be used only when there is something that needs attention immediately.
There are a lot of times that this is the case, it's strange you'd prefer no modal at all. I make backend web apps and modals are hugely valuable. Creating/editing new objects, confirming actions, applying filters, etc etc. I'd agree they have no place in informational web sites (like your favorite news site), but the web is used for a lot more than informational websites.
But the reasons you're giving for saying "but I'd much rather never have a modal ever" are down to bad design decisions. In that sense any UI pattern could cause you the same reaction if used badly.
I don't think you can write of modals simply because you don't like how they are used in some cases.
For example, how do you feel about Pinterest using modals to expand on content?
The first that I personally have seen so far that doesn't screw up when zooming in on a mobile device (actually resizes and re-positions itself), so great job! I'm sure there are others, but this one is now the best in my opinion solely based on that regard.
This is fantastic, I will definately be replacing my bootstrap modal code to use your library. This would be great if this got committed into bootstrap.
It suffers from the same bug as the stock bootstrap modal; focus is not contained in the popup window. Press tab a few times and soon your keyboard focus is on elements on the page behind the modal.
That:
1 - enables focus on the modal div
2 - hides focus visual indicator on the modal (because it's not an interactive element, just a wrapper)
3 - sets focus on the modal
The user's next tab keypress will select the first focusable element inside the modal.
Restricting tab keypress to just elements inside the modal (ie cycling through only modal content) doesn't return significant benefit and it's a whole lot more work. It's easy for a user to error-correct by simply clicking back inside the modal, but it's hard for a developer to manage enabled/disabled states for native behavior.
Well, I actually submitted a pull-request almost a year ago but it was rejected for "complexity"...
I didn't understand that decision back then and I don't understand it today. The patch weighs in at about 100 lines which doesn't seem heavy to me. Especially when you consider that without the patch the bootstrap-"modal" is not a modal...
Anyway, here's the fixed bootstrap-modal.js for the version that was current back then:
Line 23-82 is the important bit, that snippet is lifted nearly 1:1 from jquery.ui.dialog which fixed this issue ages ago. Beyond that there's only a couple lines of glue code.
Feel free to port this forward to the current version (or better-modal). Personally I've stopped using the javascript parts of bootstrap because I don't want to maintain forks for basic bugs like that.
Thanks for this. Currently I have a workaround by using data-tabindex instead of the standard tabindex but I've been trying to find a more robust solution to this problem so I'm going to take a look at implementing something like this.
"If you want to prevent the background page from scrolling (see demo for example) you must wrap the page contents in a <div class="page-container">.
The reason for doing this instead of just simply setting overflow: hidden when a modal is open is to avoid having the page shift as a result of the scrollbar appearing/disappearing."
I have found one case where it makes sense. Say you have a modal popup with an 'editor' widget in it. If that widget then needs to popup another modal for adding a link, it makes sense. Here is a screenshot of what I'm talking about...
True, I could resize the modal to be a lot larger, but it hasn't been a big issue so far. I do like it in a modal because it allows me to enable/disable the Save button depending on if things change (although this doesn't work now that I've switched to Redactor since they don't support figuring out that info yet... feature request has been submitted). All of my UX does editing of form fields in a modal, for consistency, it is nice to keep things the same.
It's a very common pattern in desktop software (complicated config panels, for instance). I don't think that makes it "good" but at least it's well understood. It's dumb that most existing modals can't do it.
I think we agree, at least in principle. Bootstrap is meant to facilitate quick prototyping, though--quick prototypes for complicated flows will include sub-optimal UI.
Desktop solutions I'm talking about: anything in Windows control panel (people still use that OS, God help them), any configuration panel in Ubuntu (go modify your network settings, for example), all sorts of horrible-to-use and yet somehow magically-useful simulation/CAD programs, etc. (A common theme here is that Apple software and most software created for Macs does not have this UI pattern, because it is indeed suboptimal. The rest of the world still sees it a lot.)
I think it's a terrible UX the way it's presented, but there is definitely a use-case for the functionality.
Say you have a modal that contains a step-by-step process. Now you can load multiple modals, and dismiss them one at a time. To a user, it will look like s/he is moving through the steps.
Is this a good use? Ehh...maybe not, but it's possible.
Just brainstorming here.
You know what's really awesome about this Modal? Unlike built-in one, this one works on iPhone without issues! Long window scrolls just fine. You just made me so happy :) Definitely using in something I am currently working on. Thanks!
This is pretty awesome, I'm going to be using it for sure. As the title suggests I definetly think it is much better than the standard bootstrap modal. You should try to get this implemented into bootstrap. Good work.
I've been using this (as well as helping give feedback on it after I developed my own and realized this one is better). This is by far a much better solution because it handles responsive resizing, z-index and smaller devices a lot better.
Issues have been opened referencing this modal and there has been no response from @mdo or @fat on it other than to say that they were working on it themselves for a future version.
1. Ajax loader inside the modal (load modal first)
2. Pinterest like modal (aka modal with HTML5 history API /
hashchange / browser back button support)
Nice. I'd remove the animation though. I think that animation is just annoyance (even slight) in structures that do not require animation. That extra few fractions of a second can mean a lot. That's why on Windows or OSX I remove the animation to hide and show application windows.
Definitely prefer this to the default modal, which blacks out the screen around it. I'll have to run some tests to see if any version of IE can handle this.
Is it really worth installing an entirely new library just to achieve something a simple line of CSS could do?
.modal-background { background:white; }
For me, Twitter Bootstrap's components have been the right tradeoff between flexibility and functionality. It doesn't have too many bells and whistles which makes it way easier to integrate into my own code.
Maybe I just haven't run in to the use cases for Bootstrap's modal that causes the pain that this fixes, but most of these "features" seem like "it would be cool if..." product cruft.
That isn't the question. The question is if jschr's modal implementation is more (or less) bug free than bootstrap's. Based on my analysis and many others, it is more bug free. Feel free to read through the issues. https://github.com/twitter/bootstrap/issues/search?q=modal
