Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alertify.js

github.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Alertify.js

#51

Post by JoeCortopassi »

svachalek wrote: post #49
JoeCortopassi wrote: post #47

Earlier quoted context omitted.

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?

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?");

Re: Alertify.js

#52

Post by kevincennis »

JoeCortopassi wrote: post #51
svachalek wrote: post #49

Earlier quoted context omitted.

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?");

Twitter actually does save drafts in localStorage.

Re: Alertify.js

#53

Post by columbo »

JoeCortopassi wrote: post #29

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

Re: Alertify.js

#56

Post by teraflop »

JoeCortopassi wrote: post #47
Mahn wrote: post #43

Earlier quoted context omitted.

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

Re: Alertify.js

#57

Post by Kroem3r »

Very nice. Thanks for sharing. I think that I'd like to see the ability to off the dialog onto the underlying document restricted. The concept of 'semi-modal' is pervasive but undefined :)

Re: Alertify.js

#58

Post by thwarted »

JoeCortopassi wrote: post #29

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

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)

Re: Alertify.js

#59

Post by ianstormtaylor »

JoeCortopassi wrote: post #51
svachalek wrote: post #49

Earlier quoted context omitted.

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.

Post reply on HN