Live data from Hacker News

A Better Twitter Bootstrap Modal

github.com

71–73 of 73 posts

Re: A Better Twitter Bootstrap Modal

#71
post #63

Earlier quoted context omitted.

Why do you think that?

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 finis…

> 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.

Re: A Better Twitter Bootstrap Modal

#72
post #63

Earlier quoted context omitted.

Why do you think that?

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 finis…

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?

Re: A Better Twitter Bootstrap Modal

#73
post #48
post #46

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.

Is there even a way to avoid that?

Assuming your modal is an element lacking native focus (eg a div) and you're using jQuery:

modal.attr('tabindex','1').style('outline','0'); modal.focus();

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.

Post reply on HN