This is a nice implementation of an alert, but ideally you shouldn't ever need it. Alerts are a pretty horrible feature in a user's experience. Essentially they say "STOP WHAT YOU ARE DOING. THIS IS MORE IMPORTANT."
If something is that important then you'll usually want to give the user a choice from a set of options - e.g. if the user is doing something that can destroy data without the possibility of undoing their actions then you'll want a dialogue that asks them if they're sure. That should block all other interaction because it really is important. When the user has no input though, and there's nothing they can do but click 'ok', there's no need to use an alert. Just put a message on the screen that's high enough up the page's information hierarchy that they've very likely to see it. Make it sticky (so it's there until the user dismisses it, but doesn't block other actions) if it's something that they need to confirm that they've seen.
Don't force the user to do things your way. Guide the user, sure, but let them do things their way.
Generally true, but I work on a system that has to comply with government regulations that basically say "this is the most important thing the user can possibly be doing. PERIOD."
So alerts are pretty much a must for us, and the obnoxious interruptions help us make the regulators happy. Getting a nicer alert like this will make our customers a bit happier while still keeping us in compliance.
But our use case is of course not standard. Usually alerts are like Satan.
True but you can also use it with ok/cancel options, which I think fits the use case you mentioned when you said:
> if the user is doing something that can destroy data without the possibility of undoing their actions then you'll want a dialogue that asks them if they're sure
This should at least have a callbacks for the different buttons.
In terms of design, I don't like absolute vertical centering. It should be higher on the page. I use 1:2, or 1:1.6 for the top/bottom margin as my "default" modal centering.
Oh wow, I just assumed those were tied to callbacks instead of just being a showCancelButton arg. The more I look into it the more underwhelmed I become.
So, if I click OK am I acknowledging the alert to dismiss it or is performing an action? If I hit cancel am I canceling the alert or canceling the action?
Its still terrible UI. Limiting the options to things like "ok" and "cancel" can be very confusing to the end user.
It's not possible for JS code to replicate the native blocking of alert(), prompt() and the like. Plus, if you call this with just one parameter, it does still work:
> [Wow Alert] overrides the existing alert function.
That is an absolutely terrible idea. It overrides alert() but doesn't - and can't - duplicate its blocking behavior.
I'm not criticizing you for liking the idea! I can see its appeal myself. I'm criticizing Wow Alert for letting a nifty idea result in bad sofware design.
Their version of window.alert() returns immediately after setting up the alert window and actions - because that's all it is capable of.
If you just drop this into existing code without inspecting each and every alert() call to make sure it doesn't rely on the blocking - both in your own code and every library you use - you will definitely break things.
Far better to leave alert() alone and make this a separate function with its own name.
> It overrides alert() but doesn't - and can't - duplicate its blocking behavior.
If you really wanted to, I think you could set up an endpoint on your server to be long polled with synchronous XHR in a while loop, while you set up the popup in an iframe. When the popup is clicked, you send a notification to the server so the next synchronous request returns 200 and you dispose of the iframe.
I'm surprised that the SO poster got the synchronous XHR approach to work. When I did some tests with Chromium last year they seemed to show that an iframe runs in the same thread as its parent window. I wasn't testing XHR though, just animation.
So if you ever do try this out, I would be interested to hear the results. Thanks!
No. Modern sites usually depend on browser native dom methods and a Javascript utility belt, like underscore. Or some other combination of new stuff like angular or backbone whatever. But the "include Jquery in boilerplate" thing is not nearly as common anymore best I can tell.
Anyone who isn't using jQuery because "modern sites usually depend on browser native dom methods" is just being an asshole, honestly. If most big sites are using it, you can use it. I just checked: Twitter, Outlook.com, Stripe, Paypal, Pinterest, GitHub, Amazon, LinkedIn, Ebay, Tumblr, etc. The list goes on pretty much forever.
Those are all sites that have been around for ages though, and jQuery is quite hard to remove from a site once it is embedded in. Anyone creating a serious web-app from scratch now really shouldn't be using jQuery, but one of the alternative set ups mentioned above.
I disagree. AngularJS uses jqlite underneath for lots of stuff it does with the DOM. It can use jQuery if it's included, and if you create your own directives, jQuery is a great tool. No, you shouldn't create a single page app based on bare jQuery. Yes, you should use jQuery for manipulating the DOM vs the native DOM manipulation functions.
They wouldn't remove it even if they had the choice, because recreating what jQuery does with regards to cross-browser compatibility is just wasting everyones time. I'm not saying it has to be jQuery, but since everyone is already familiar with jQuery and it works well - why not jQuery? Eventually yes I think we can drop jQuery in favour of native implementations, but most sites can't afford to lose that compatibility yet.
Because it's not built for complexity? Maybe I'm a jQuery newb, but trying to built a tight app with it seems like a painful process. Sure, it's easy to build some quick tricks with it, but I'd hate to maintain a large project with a lot of it embedded.
I honestly can't see how jQuery dictate how you architect your code. jQuery is a DOM manipulating library and AJAX library. It is not a framework. It doesn't force you to organize your code in any particular way. You know that jQuery is not forcing you to not write everything in a single main function, right?
So I fail to see how using $('#...").foo() in your large project is going to be harder to maintain than rolling your own DOM manipulating library.
If all I'm doing is domConstruct.put() instead of $().append() then of course you're right. Dojo in addition to browser normalization and other good things that jQuery does, suggests a structure that works pretty well. jQuery to my knowledge does not.
This doesn't make one an asshole; native dom methods can handle most of what people normally use jQuery for nowadays (even with the same function signature) so unless someone needs to do something more specialized I am not including an additional dependency.
I would always encourage using a library over not using one - if you're not using a library you're just going to end up making your own anyway to "save time" - might as well start with something everyone already knows. If your project is also going to be something that a lot of people touch, you don't want to be using your own solution or a lesser known solution just because it's neater - that would be a waste of time.
So yeah, in my opinion if you opt to use your own solution or a lesser known one, I'd say you're at least a bit of an asshole because 1.) you're assuming you know better than the majority of people (who don't have a problem with using jQuery) or 2.) you're wasting everyone's time by forcing them to learn something new when there's a perfectly fine solution already available.
Given the recent abundance of jQuery alternatives, that's a big assumption to make. It's always disappointing when I find some code I want to use and it has a bunch of dependencies that make it not an option.
I'm not aware of any jQuery alternatives. Most things that predate jQuery (prototype, mooTools, YUI) have long since fallen out of favor, and the 'alternatives' to jQuery are mostly API-compatible subsets (jqLite, zepto). What exactly do you mean by 'abundance of jQuery alternatives'?
I might be an edge case, but I use Dojo a lot because it's much better structured for larger JS applications than jQuery which quickly becomes a mess if you start doing a lot in JS.
That said, it does everything jQuery does, and more, and in a very nice way IMHO. If you're used to the jQuery syntax sugar, you probably don't like it, but I never liked sugar.
I think what the parent meant is that it's not possible to make it blocking like the built-in alert function. WOW Alert still needs a callback if you want to do something after the alert is closed. So it's not a drop-in replacement.
Any app that allows users to create content that is not stored in persistent storage: this will be lost if they close the window without saving in some manner. An example: an HTML5 audio recorder or photo editor.
I'm not sure there's a great reason to block the UI with an Alert. But I also can't remember the last time I saw one except a really horrible AP tool by GXS which uses an alert to tell me my browser won't work on their site. (which of course it does once I switch my user agent string to one they like).
Now this isn't a great use but its one maybe acceptable use if my browser really didn't work on their site.
Confirm dialogs particularly around destructive actions are decent use cases for UI blocking.
This strikes me as cartoonish rather than beautiful. The animated green line art is semantically confusing, suggesting some sort of continuous process rather than a static situation. I suppose that could be good if you feel people tend to hit OK too fast without reading the text.
In fact, the animation draws attention away from the text, which you are probably supposed to read (otherwise, why bother with an alert). I really don't understand this infatuation with distracting unnecessary animations that people have nowadays...
Like other people here have pointed out, this isn't exactly an alert replacement as much as it is a more limited form of modal dialog. And honestly if that's what you need, there's better solutions out there, even in the form of the HTML dialog element (whenever that comes into mainstream support at least).
Please do not use this until the authors ensure people using the keyboard alone / screen readers can dismiss the dialog and access elements contained within.
I think it's just another case of language losing its meaning in certain contexts. In the case of front end web development it seems to mean 'flat with large well spaced fonts'. When terms are abused like this they quickly become terms of abuse. Give it another year and it will be an insult to call something beautiful because by that stage it will be clear that beautiful = early 2010s obsessively flat and minimal web design that everyone finds boring and pretentious now.
(As you can probably tell, I do not like this style at all)
The thing that really annoys me about it is that the word 'beautiful' has meaning to me. That meaning is such that it only applies in very few places. By taking that word and associating it with something as mundane as a bloody message box (in this example - there are plenty of others); It feels like a con. The credit the word 'beautiful' has built up is being used to try to raise the calibre of something completely ordinary. It makes the word and the thing it is describing both seem cheap. There's a lot to be said for calling a spade a spade.
Honestly the native version looks better to me. And it has the desired functionality of blocking the UI thread... I don't think you should encourage anyone to use alerts by making them prettier.
If so, there's a slight typo on the "See it in action!" page (http://tristanedwards.me/sweetalert). For the "A warning message, with a function attached to the "Confirm"-button" demo, the code displayed says 'alert("Booyah!");' but the alert being displayed says 'Deleted!'
Looks great, but it seems like positioning it as a beautiful flash message plugin rather than an alert replacement might be more apt.
Hopefully very few JS developers are using alerts in their production code (or dev for that matter!), and if they are they're probably not interested enough in user-friendly design to seek out this replacement.
I notice that even large apps like gmail and google calendar use native alerts (and I've been using them a bit more under certain circumstances—something has gone terribly wrong). What about native alerts in all situations equals unfriendly design—esp. when trying to mimic mobile native apps, but needing to span the gap from OS to OS?
I agree with their use under very particular circumstances, like in your example or (at least in desktop Chrome) for bringing attention to a window that isn't visible. I was referring more to using alerts as they're being used in the SweetAlerts examples (success messages and other "flash messages"). In these cases, UI-thread blocking seems bad, no?
I actually think SweetAlerts looks pretty nice for those kind of in-app notifications, which was the point I was trying to make. (Though seeing comments from people who have dug in further it seems like it has some issues)
You should be able to click off of the modal and it should disappear.
The only issue I see with doing it that way is if you are in another Window and click to get focus, but you should deal with the alert when it appears since it is a part of completing a task.
Usually people only switch windows when they have completed a task.
Most comments critique the widget, but I'd like to talk about the demo website. It's really well done, I wish more products (especially free and open source) were on top of their game when it comes to presentation, samples and configuration. Good job!
Animation should augment UI, not steal attention away from what the user should focus on. In case of popup alerts, popup animation itself does what is needed.
Also, I suggest optionally only blocking a portion of the DOM and centering over it. This would allow a component to lock without locking the application.
There is one gotcha with native/custom alert messages like these: native alerts block the ui thread of a browser, while custom do not. Sometimes you want to block and sometimes you don't. When you don't - you need something nice and simple.
Does this guarantee that the alert will be on top of the html elements on the current page? Sometimes this is important if you are building a browser plugin and need to show dialog to the user. For example, I use alert instead of a modal html dialog because when you are injecting it on some pages it won't show up properly.
Chrome supports the <dialog> element which is guaranteed to appear on top of whatever page its injected on.
Javsacript's Alert, prompt, also guarantee it will appear on top.
If something is that important then you'll usually want to give the user a choice from a set of options - e.g. if the user is doing something that can destroy data without the possibility of undoing their actions then you'll want a dialogue that asks them if they're sure. That should block all other interaction because it really is important. When the user has no input though, and there's nothing they can do but click 'ok', there's no need to use an alert. Just put a message on the screen that's high enough up the page's information hierarchy that they've very likely to see it. Make it sticky (so it's there until the user dismisses it, but doesn't block other actions) if it's something that they need to confirm that they've seen.
Don't force the user to do things your way. Guide the user, sure, but let them do things their way.