Alertify.js(github.com)
github.com
Alertify.js
https://github.com/fabien-d/alertify.js/
33 comments
It's rather annoying it's modal but leaves most of the page visible and unresponsive to clicks. Maybe dim the background slightly?
One concern is the ordering of buttons. Windows users will be used to OK/Cancel whereas on OS X, etc Cancel/OK is the norm. I wonder if this is something this library should handle?
In the "prompt dialog" the buttons don't get highlighted when I tab over to them ... so instead my browsers buttons get highlighted, and I end up hitting back instead of Ok or Cancel...
Degrades perfectly down to IE7, great example on how to do this - the design and functionality become less and less polished yet it still does the core tasks accurately.
I love it but I actually don't understand why you decided to put two completely separated features in a single library: the alert/confirm/prompt dialogs and the log/success/error messages.
I think that if you'd split this two things into two different libraries it would be better (e.g.: if i want only dialogs i'd prefer to include just them)
I think that if you'd split this two things into two different libraries it would be better (e.g.: if i want only dialogs i'd prefer to include just them)
Great work!
I've been using apprise (http://thrivingkings.com/read/Apprise-The-attractive-alert-a...), which is pretty good, but going to switch to this. I really like how Alertify has the growl-like log alerts along with it.
I've been using apprise (http://thrivingkings.com/read/Apprise-The-attractive-alert-a...), which is pretty good, but going to switch to this. I really like how Alertify has the growl-like log alerts along with it.
Great work, but one suggestion:
Make the alert notification go away when ESC is pressed, like the Confirmation and Prompt notifications.
Make the alert notification go away when ESC is pressed, like the Confirmation and Prompt notifications.
I'd also suggest that clicking anywhere on the body should dismiss it, and behave like cancelling.
Submit a pull request then.
Very slick. The only thing I'd add would be Chrome desktop notifications (optional) for plain alerts.
Very nice. Thanks for sharing. I think that I'd like to see the ability to <tab> off the dialog onto the underlying document restricted. The concept of 'semi-modal' is pervasive but undefined :)
Very nice! I've used jGrowl for this in the past, but this seems much improved, more feature-rich and with sensible default styles. Alertify FTW!
Sweet, thanks for Sharing. Another lib to add to the list. Not sure how it compares to noty, which has many options.
I like that it doesn't require any JS frameworks and still being lightweight.
Very nice work, I will look deep into it today :D
works surprisingly great on mobile
-----
on a galaxy nexus (cm10) (animations are bit laggy, but thats fine)
Looks awesome! Smooth transitions!
This is pretty bad ass.
Cool library, i'll deep into it today :)
No examples?
http://fabien-d.github.com/alertify.js/
Edit: I had a good time click on the buttons and filling the page with notifications. The animation is solid, and it's super clean.
Edit: I had a good time click on the buttons and filling the page with notifications. The animation is solid, and it's super clean.
They are linked there on the repository.
"No examples on a github repo page?" Classic. Good one.
[deleted]
Pretty slick, animation-wise. If I could make one design-layman suggestion...the thick, black border belies the unobtrusiveness of the plugin. Maybe a lighter, thinner border would be a better fit for the use-case of this plugin?
Making the border any less obtrusive might make the notification blend into the page too much.
You can go into the css and for the .alertify {} selector
Remove the border{...} values and change box shadow to:
box-shadow {box-shadow: 0 0px 60px 30px #666;}
Remove the border{...} values and change box shadow to:
box-shadow {box-shadow: 0 0px 60px 30px #666;}
looks like it's using class="alertify alertify-show alertify-prompt"
you should be able to override any of these to your liking
you should be able to override any of these to your liking
Yeah, I meant for demo, first-impression purposes. I know it's just a easily-changed visual tic once a developer decides to implement it...but might as well entice as many people as people as possible.
Really nice smooth animation.
It would be nice if the alerts appeared in the centre of the screen though... I find that jerking my eyes up to the top of the screen and then back down to what I was looking at quite intrusive.
It would be nice if the alerts appeared in the centre of the screen though... I find that jerking my eyes up to the top of the screen and then back down to what I was looking at quite intrusive.
Ideally you could specify an HTML element to place the notification near, and then pass whatever element the user activated to trigger the notification. Or you could specify target coordinates, and compute the desired location yourself. Both of those ought to use optional parameters, though; defaulting to center seems reasonable.
If you look on the demo page (http://fabien-d.github.com/alertify.js/), all of the alerts get injected into #alertifylogs.alertify-logs which is positioned by css and therefore should be easy to overwrite:
.alertify-logs {
position: fixed;
z-index: 5000;
bottom: 10px;
right: 10px;
width: 300px;
}I was literally talking to someone yesterday about how I couldn't believe a plugin like this didn't exist yet. Long overdue. Well done!
Looks great on my iPhone. Thanks for the nice lib!
Here's the examples link: http://fabien-d.github.com/alertify.js/
I love that someone already made a pull request to update the readme with it.
I love that someone already made a pull request to update the readme with it.
This looks beautiful. But I'm curious, do users no longer expect/like their platform's native dialogs for these things?
The native alert is very hard to customize and extremely bare boned.
Not to mention that the second I see a native alert my heart rate increases 10 fold.
Only thing worse are those "Are you sure you want to leave this page?" modals. Those cause me to go into fits of ctrl+w- smashing rage!!!
HALP! Does anyone know of a jQuery plugin that has notifications like they do on OSX. For example, when you raise the volume or mute you see that rounded transparent square? Is there something like that for the web?
I think http://stanlemon.net/pages/jgrowl is very close.
And this plug-in is also close. Build on top of jQuery UI, so small footprint, but you'd need that library.
http://www.erichynds.com/examples/jquery-notify/
jGrowl is a jQuery plugin that raises unobtrusive messages
within the browser, similar to the way that OS X's Growl
Framework works.
And this plug-in is also close. Build on top of jQuery UI, so small footprint, but you'd need that library.
http://www.erichynds.com/examples/jquery-notify/
This is a growl/ubuntu-like notification system built on
top of jQuery UI.It's a DIV with a border-radius and a semi-transparent black background. It's just CSS, why use a jQuery plugin? Why not just quickly build it yourself?
Because it is an alert. I need it to fade in and then disappear. I mean I guess I could build it but was wondering if there is a complete library out there to handle the alerting and all the options a modern notification library has.
I found this project that would fit the bill: http://fabien-d.github.com/alertify.js/
See "Customizable Log Messages".
See "Customizable Log Messages".
i like it, thanks for making!
Very useful! Thanks! ;)
Great stuff, I think this will take over from jQuery.noty for me.
great stuff! i wish prompt dialog auto focused on the textbox. currently i have to click it first to type in. (on windows chrome)
Agreed. Looks like someone reported an issue already:
https://github.com/fabien-d/alertify.js/issues/3
Very cool library! The one thing all of these type of things lack (e.g. this, dojo.dialog()) is that they are non-blocking to the execution thread, unlike alert()/confirm()/prompt(). I know it's not their fault, javascript doesn't allow this natively, but i feel like that would be immensely useful for general user input, form validation and the like. Yes, I am aware that it can be done currently through workarounds, I'm just saying that allowing certain native objects to be blocking upon further user input, would be immensely useful and save code readability
EDIT: Care to explain why I'm getting downvoted? Said nothing offensive, and I'm clearly on-topic.
EDIT: Care to explain why I'm getting downvoted? Said nothing offensive, and I'm clearly on-topic.
I don't know why you were being downvoted but I don't think -anything- should ever be able to block the execution thread. I never liked the fact that you could force lock a user by spamming alert/confirm boxes and I saw this effect as a bug of the default behavior of the operating system over a feature of the browser.
I used to work in applications that require you to do -as much as possible- to keep the window open. This isn't for spam reasons, it is because we did assessment and you really, really didn't want someone closing half-way through an assessment, especially one that is timed. You also don't want to freeze the timer because you might leave the user an opportunity to cheat (close window, research, relaunch assessment, repeat).
So this was real example of something that really should be single-execution. However, even with all the popups, checks, refresh-push-forward, launch-window-on-exit hacks we tried we STILL got users lost out of the system. Not only that but we wound up annoying/angering/confusing 1000 users for every 1 user it helped.
shrug
YMMV, but I believe 99.999% of all issues can be solved with user/session caches and clear wording over blocking the execution thread.
I used to work in applications that require you to do -as much as possible- to keep the window open. This isn't for spam reasons, it is because we did assessment and you really, really didn't want someone closing half-way through an assessment, especially one that is timed. You also don't want to freeze the timer because you might leave the user an opportunity to cheat (close window, research, relaunch assessment, repeat).
So this was real example of something that really should be single-execution. However, even with all the popups, checks, refresh-push-forward, launch-window-on-exit hacks we tried we STILL got users lost out of the system. Not only that but we wound up annoying/angering/confusing 1000 users for every 1 user it helped.
shrug
YMMV, but I believe 99.999% of all issues can be solved with user/session caches and clear wording over blocking the execution thread.
I'm not going to down- or up-vote you. But wanting something to block a UI execution thread is...novel. Thousands of man-years have been spent creating non-blocking systems for the simple reason that it opens up a lot of options.
But I guess in some circumstances having a UI-updating callback called when a modal dialog is up might be a little confusing for the user. And setting (and checking!) a global everywhere is rather messy. So I see your pain.
Ha, one way I just thought of to get frozen behavior is to take a snapshot of the screen, then overlay a canvas element with that image. As an added bonus you can do some transform on the image to make the effect look more native. When the dialog box goes away, the canvas goes away, and your updated state is presented as if it just executed.
But I guess in some circumstances having a UI-updating callback called when a modal dialog is up might be a little confusing for the user. And setting (and checking!) a global everywhere is rather messy. So I see your pain.
Ha, one way I just thought of to get frozen behavior is to take a snapshot of the screen, then overlay a canvas element with that image. As an added bonus you can do some transform on the image to make the effect look more native. When the dialog box goes away, the canvas goes away, and your updated state is presented as if it just executed.
Looking at the other comments, I think there might be a misunderstanding.
The last thing you want is a UI blocking popup like alert() that, at least in browsers like Firefox and IE, effectively lock the entire browser from doing anything, which is a terrible anti-pattern in multi-tabbed browsers. Chrome did it right, at least with the HTTP authentication prompt, to make the UI block on a per-tab basis and have the prompt window not be a top-level-window-manager-managed-block-the-entire-app modal dialog.
I think a case can be made to have functionality that shows a dialog that is modal within the context of the page it is on, not modal for the entire browser. The former would be useful for the cases you outline, the latter is the bane of users everywhere.
(forgive me if I'm misrepresenting the current state of browsers other than Chrome when it comes to modal dialogs like alert(), I don't use them much; I think everyone can get what I'm saying despite that)
The last thing you want is a UI blocking popup like alert() that, at least in browsers like Firefox and IE, effectively lock the entire browser from doing anything, which is a terrible anti-pattern in multi-tabbed browsers. Chrome did it right, at least with the HTTP authentication prompt, to make the UI block on a per-tab basis and have the prompt window not be a top-level-window-manager-managed-block-the-entire-app modal dialog.
I think a case can be made to have functionality that shows a dialog that is modal within the context of the page it is on, not modal for the entire browser. The former would be useful for the cases you outline, the latter is the bane of users everywhere.
(forgive me if I'm misrepresenting the current state of browsers other than Chrome when it comes to modal dialogs like alert(), I don't use them much; I think everyone can get what I'm saying despite that)
FWIW, Firefox handles alert() much better than Chrome does. In Firefox, you can navigate away from the page, and switch tabs. Chrome won't let me open a new tab, and keeps the alert in front of other pages.
This may be platform dependent. I was just stuck in a FF alert that was a modal top-level window manager managed window the other day on Linux.
There are still a number of types of dialogs that are not tab-modal. See https://bugzilla.mozilla.org/show_bug.cgi?id=616843 and the bugs it depends on. alert() should be tab-modal content, though, and is for me.
IMHO, no modern JS developer should ever need to create a blocking alert or prompt; the reason the native alert or prompt functions block is because, well, they are not designed for what the web is today.
Just out of curiosity, if you had a web app like Gmail, and your user accidentally went to close their browser window with an unsaved email half done, how would you plan on warning them without blocking events?
You use the onbeforeunload event, which doesn't block the event thread. (EDIT: actually it does, just not while JS code is executing, unlike alert().)
In fact, the HTML5 spec permits browsers to disregard the normal blocking behavior of alert()/confirm()/prompt() (making them no-ops) while this event is being handled: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore... the dialog box is open
In fact, the HTML5 spec permits browsers to disregard the normal blocking behavior of alert()/confirm()/prompt() (making them no-ops) while this event is being handled: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore... the dialog box is open
I managed to break that link somehow and can no longer edit it, here's the correct one: https://developer.mozilla.org/en-US/docs/DOM/window.onbefore...
Save it in drafts and notify them when they come back.
So Facebook and Twitter should also save drafts of posts you were going to make? What if latency is non-trivial, or connection is lost? Do I also want to send ajax posts for drafts every second to ensure that as little as possible is lost? A lot of this is mitigated by a very simple
confirm("Are you sure you want to leave?");Yeah but for all the times when I really do want to leave, now I have to annoyingly click "Yes" in a dialog I didn't expect in the first place.
I like the localStorage solution for drafts much better.
I like the localStorage solution for drafts much better.
Twitter actually does save drafts in localStorage.
Are you saying it would be good for them to block? Why?
When they execute, they run a callback with the input provided. Inside that callback, do whatever you need to do that requires some input.
When they execute, they run a callback with the input provided. Inside that callback, do whatever you need to do that requires some input.
Confirm and prompt are typically used to indicate a decision by the user. Natively, these functions stop javascript execution to wait for the users input, so that it knows what to do, but do not allow for customization. Non-native libraries do not have this ability to prompt the user for input, then wait for their response, before continuing the execution of that script. Callbacks are one way to circumvent this issue, but introduce new issues with scope and readability.
All I'm trying to say is that allowing custom defined objects to have the ability to block execution can be very handy in certain instances. I by no means was criticizing the alertify.js library
All I'm trying to say is that allowing custom defined objects to have the ability to block execution can be very handy in certain instances. I by no means was criticizing the alertify.js library
Sometimes it's just easier to have linear code with some blocking than to create an entire state machine. Yes there are libraries that get close to this. No, it's still not the same.
You can have linear code without blocking - it's exceptionally common in the node world.
async.waterfall([ function getInput(){...}, function checkInput(){...}, function submitInput(){...}, ], function finally(){})
Each of the functions takes a callback, and returns err (if any) and output. If a callback returns err, it jumps to finally where you say what failed.
This is odd when you first get started with async, but it's really easy to visualize.
Think of a production line, with a number of different workers doing different stuff. If one of them gets a dud part, it throws it away.
async.waterfall([ function getInput(){...}, function checkInput(){...}, function submitInput(){...}, ], function finally(){})
Each of the functions takes a callback, and returns err (if any) and output. If a callback returns err, it jumps to finally where you say what failed.
This is odd when you first get started with async, but it's really easy to visualize.
Think of a production line, with a number of different workers doing different stuff. If one of them gets a dud part, it throws it away.
I get it. I do plenty of async programming. But, at the end of the day, no matter how nice you think the async.waterfall mess is, sometimes you just want to block. Sometimes it turns out that that is the right pattern. I've written dozens of async apps, much to the chagrin of co-workers who hate anything resembling async. I think I'm qualified to know that sometimes I get to a bit of code that sure would be nice with a simple blocking call.
What you want isn't blocking the UI thread but a stack of states where each state defines the current behaviour of the elements, with bonus points if states can be composed together.
There is a method called `showModalDialog` in modern browsers that was supposed to be used for exactly that, blocking interaction. Unfortunately it doesn't actually work consistently.
https://developer.mozilla.org/en-US/docs/DOM/window.showModa...
https://developer.mozilla.org/en-US/docs/DOM/window.showModa...
[deleted]
[deleted]