I really like this. I had done something similar in a project, but this execution really ignites my imagination. Really well done. I am curious if chosen.js would have to be modified to handle backbone style async, I know it's been strange in cases like that.
Pretty cool and thanks for releasing for free! That said, why would you put a multi-step wizard inside of a modal? Seems like bad UI to me. Modals should be used for quick data collections, small actions or context-aware warnings/insights. Using one for something that is complicated enough to need a wizard just seems like a bad idea.
Just wondering how you would vary presentation of a wizard? I have a modal wizard in one of my applications and it has been well received by users. I'm not as in love with it as I was as when I wrote it, but I'm still not sure how to improve it. I'm always interested to learn mo' betta UI/UX approaches
Anything more than a couple of steps pushes it, yeah. I was going to say no more than three, but I can't even talk myself into three. Maybe no more than 2 for a modal-wizard, but at that point it is barely a wizard.
Great idea. Wizards are definitely useful for a variety of projects, so it's nice to be able to get one off the ground without having to consider the UI too much more than one needs to.
When I zoom in to view the page (on Android, but I guess this will happen with zooming on many browsers), the page is not scrollable horizontally, meaning only the center of the modal is visible on the screen. This seems to happen with almost every modal implementation I've seen.
I see that a lot myself.. I started to be hyper aware of it when I used a netbook for a year... a lot of modals were off screen.. got really familiar with F11 and ctrl+/-
Unrelated to this component, but the Monitoring Location step shows a limitation in the Chosen select library; the dropdown is attached inside the parent container.
I ran into the same issue and went with Select2. It's forked from Chosen and solves this positioning problem (and adds remote AJAX loading and other cool features).
http://ivaynberg.github.com/select2/
I'm not familiar with Select2, but it's easy enough to fix this if you don't have a lot of content in .modal-body; simply define overflow: visible and it will render outside of the container.
Say I'm on Twitter's web site. Most of the time, I just want to browse tweets. So don't pollute the site with a new tweet from that I rarely need. Sometimes I want to send a tweet though. Refresh the whole page (with a trip the server), just to pop up a new tweet form? I want to get back to my Twitter stream after this tweet. Just put some UI front and center so I can focus on that one new tweet.
Modal dialog boxes have plenty of good uses. But most of all, they're an option. Another tool to use.
1. The simplest solution to the problem you described is to have a simple link to the new tweet form, which the user would middle-click to open in a new tab. It requires no fancy coding and allows for remarkably smooth workflow.
2. Does your server demands a human sacrifice for every request it processes or something? And if so, do you not include any images, fonts or script files on your pages and inline everything?
3. Modal popups don't just display new information. They block access to everything else in the window. In the wast majority of cases doing that is pointless and stupid. The evolution of Firefox UI is a great example of how much more usable modal-less interfaces really are.
Suggestion: I thought the progress bar was much longer, spanning the total lower part of the modal, up to the buttons, because there is so little contrast. If I were using it as a real wizard, i might have aborted, thinking there were maybe 10 times as many steps involved.
wow... just today I started looking for a wizard for a new project and this is exactly what I had in mind. will have to translate that CSS to LESS though.