An alternative to alert() | Hacker News Reader

An alternative to alert()

github.hubspot.com

191 pointszackbloom79 comments

Not modal, not dismissable, not necessarily working depending on browser.

That's not an alternative to alert, that's just one more notification popup thing out of a billion or two.

It's dismissible, try showCloseButton.

It's an alternative to alert in the sense that you can use it to provide a better experience than {error: alert}. It's not a great option for modal alerts.

What browser does it not work on? We'll file an issue.

Most people only use alert() for debugging. It blocks the thread of execution until dismissed which is a nice feature. However, alert() is almost never used to display user-visible messages, which one definitely would use your nice looking plugin for. The concept is called "flash messages" and there are some other plugins that also implement them, but they are not as sophisticated as yours.

> It blocks the thread of execution until dismissed which is a nice feature.

I've wanted a "just wait a minute, Javascript engine; let me look at what you're doing!" API call for quite a while.

Turns out there is one: you can put "debugger;" in any JS code, and (if you have Webkit Devtools or Firebug or what-have-you) it will act as if you had set a breakpoint right at that statement.

Much less diddling with the mouse to set a breakpoint in code you already had open in a text editor. Good complement to console.log :)

This is one of most important things I've learned this whole month! Thanks for the tip! :)

They are also known as Toasts. I believe that's what the Android SDK refers to that concept as, as well as many other libraries.

I remember this as a Microsoft term, based on notifications from Outlook and MSN Messenger. The analogy is that it pops up like toast from a toaster.

Yeah: http://en.wikipedia.org/wiki/Toast_(computing)

Though they're often known as merely "notifications", that's how Growl calls them and libnotify... well no need to spell it out.

I had no idea they had a name, thanks!

> alert() is almost never used to display user-visible messages

What bank do you use?

I just realized my bank does this as well. Sad, very sad.

It did strike me as odd that showCloseButton isn't true by default. I can't see many scenarios where you would want to force the user to leave their screen obstructed after they've seen the message.

{hideAfter: 10} is default, meaning it will hide in 10 seconds without intervention.

That's a good default for expiration, but I always expect to be able to dismiss notifications early to get them out the way.

It definitely makes sense to hide the dismissal button when there are interactions prompted that would get rid of it (Retry/Cancel), but the default case is a plain text message to the user.

By the way, I like it, thanks for putting it out there! A more unique name might help me find it for future projects :)

While it technically works in Opera Mobile 12.10, it is just not giving me a good user experience. It is down in the lower right corner of the phone and I need to zoom in to be able to read it (which takes effort and time since my phone/handheld computer is not that fast). That is a lot different from an alert() box which integrates with the UI on the device to instantly give me an actual popup.

I also had a general problem with boxes disappearing. I tried opening a box with autohide after 10 seconds, then a box with a button. I positioned my mouse over the button but then the autohide box disappeared and the button moved away from my mouse! I seriously hate such UIs. Stuff should not move on a page, especially not if they are meant to be clicked. And text boxes should not disappear when I am half-way through reading them.

I'm on the latest Firefox on Mac 10.8. The "run" buttons do not show up at all...I had no clue what I was supposed to be looking for.

Yep, we just discovered that bug in the underlying doc library (https://github.com/HubSpot/executr/issues/1), thanks!

Super nice, but TWO dependencies? jQuery I guess is okay, since it's already, well, everywhere - but backbone?

Don't get me wrong, the first thing I thought was "Gotta use this somewhere", but if I need Backbone (a great library for where it fits!) just to make alerts prettier, then no thanks.

Yeah, that caught my attention as well. I think it's pretty insane for something like this to require backbone to work, the functionality is trivial to implement without Backbone.View.

Plus the examples are written in 'coffeescript':-/

Alert works in plain old javascript.

Coffescript is an actual thing - no need to use "quotations". Besides, Messenger will work with plain js too (or any other compile-to-js lang) it's just the examples that are in coffeescript. You can write an example for alert in cs:

    alert "Blammo! A coffeescript alert example"

I believe the point is, why provide examples in CoffeeScript? Is there any benefit?

I'd venture to say less than 1% of people who know JavaScript also know CoffeeScript.

Personally, I was wondering what the language language it was.

If I see examples in Coffeescript, I'm not sure if you can also write it in Javascript, or if the whole thing is in Coffeescript or what.

I’m not clever enough for Coffeescript.

I wish the examples were written in such a way that if I showed it to coworkers half of them wouldn’t roll their eyes.

It would be nice to get rid of Backbone. The chief dependency is the event parsing piggybacks on Backbone's, but it shouldn't be too hard to pull that code out and include it directly.

Ping me (tomaz[at]codeable[dot]io) if you do that (getting rid of Backbone dependency), I'll be more than happy to include it in our product, since we're just in the middle of implementing a notification system.

Wilco: https://github.com/HubSpot/messenger/issues/9

Excellent, and while you're at it, make it a proper jQuery plugin then advertise it like one. Review sites and bloggers will be more than happy to put it in their "Top X jQuery plugins" posts, giving you a wider reach.

Someone did pull out the events for you

https://github.com/jrf0110/backbone-events

Not sure if they're keeping it up to date however.

Would probably be even better to use custom DOM events.

Plus backbone has a requirement of underscore so that's actually three dependencies.

Personally, I found this a breath of fresh air from the modal-based alert dialogs out there, although I wouldn't call it an alert per se. Alerts (as others have mentioned) block the UI and prevent the user from interacting with it until the message has been dismissed. This is more of a low-key notification element.

First of all, I'm not crazy about the other themes, but Future (the one enabled by default in the demo) is gorgeous. Maybe I'm just a fan of circular progress bars, but check out the demo involving "Error destroying alien planet." This is really pretty!

The stated use case for this is "transactional messages in your app." For that I think it fits pretty well. It might work as a debugging utility, similar to how we used alert() before we had console.log(), but it seems like the intended use case is for an end-user-facing interface.

Two minor gripes: 1) Backbone as a dependency for a UI element is kind of overkill. 2) This is more of a pet peeve, but why is the demo written in Coffeescript? I love Coffeescript and use it all the time, but I think it makes more sense for something like this to be demoed in Javascript. People who know Coffeescript are a subset of people who know Javascript, so you cater to a larger demographic this way.

That out of the way, great job on this. I'll have to find a project to use this in :)

I think it's pretty clear that the intention of this tool is to provide alerts/notifications to users. Not sure what all the clamoring like "It doesn't do this" or "It doesn't work exactly like alert() in this way" are all about.

Anyway...Nice work, zackbloom. The notifications look and work great.

I'm going to guess it's due to being billed as "an alternative to alert()", while alert() is rarely used to display messages to the user.

I love the action buttons and the countdown timer. Very useful, though I might suggest optionally pausing the timer when the user mouseovers; that way if they want to take an action things are suspended. On the whole, it's a bit rough around the edges (close button is not always in the right spot on Chrome on Ubuntu; overlaps with the scrollbar, etc.) and I wouldn't use it in production just yet. But it's a great contribution.

alert() and confirm() have one feature that no other alert system can match -- the execution of the surrounding script blocks at the calling location.

In at least Firefox and Chrome, you can use the "debugger;" statement to not only block execution, but actually drop into the interactive debugger.

Indeed, it can be abused as a sort of primitive step-by-step debugging tool.

I remember the days before the "Don't allow this site to show more alerts" checkbox when, if you accidentally left an alert in a loop, your only option was Ctrl-Alt-Delete.

Weird how you had JavaScript support but no process killing. I imagine you must have used DOS. What browser? Arachne didn't have JavaScript support...

Ctrl-Alt-Del is one of the ways to access the task manager in Windows, with which you can kill a process.

You could even instrument your code to implement a full debugger using "prompt".

In fact, I did: https://github.com/tlrobinson/xebug

I tried it out on an app I'm building. A few notes:

1. The documentation is pretty lacking IMO. I would really like to see a unified "This is every option available to you" section. I have to dig through the code to figure out what is and isn't available.

2. Please do the docs in Javascript, otherwise it is very difficult to notice that you're actually passing TWO objects to $.globalMessenger.do().

3. A few of the code examples don't run, and a few don't look like they're meant to run. These should be in a separate 'notes' section (along with the options!)

4. Just an FYI, to get this to work with Backbone.LayoutManager I had to add manage:false to the Messenger and Message classes.

5. Why is the counter hidden in the future theme?

All in all a pretty solid library! Clearer documentation would do wonders but I am enjoying it so far. I really like the delay implementation, especially.

Thanks. I created a few gh issues to track these.

Re the counter, it is planned that the spinner would take the place of the countdown in the future theme. The messenger-retry-soon and messenger-retry-later classes are in there to make it possible, it just has to be wired up.

Any thoughts on #4, do you think it makes sense to always include {manage: false}?

I was thinking about that. While one part of me thinks that the library shouldn't have to specifically support libraries like LayoutManager, the reality is that there is no way to make it work without transplanting that code into GlobalMessenger. Considering it doesn't affect non-LayoutManager installations, it may as well be in there.

Just a quick question - the $._messengerDefaults hash allows me to set a couple simple defaults across the app, but it appears that it can't set other defaults (e.g. showCloseButton). Is there an official way of setting this app-wide or do I need to just hack it in?

I'll merge in a branch in a bit which gives you the ability to set $._messengerDefaults.messageDefaults

edit: merged!

Great, thanks!

Got to give you props on the demo website, I like the layout you used where you have all the code with the RUN link right next to it. Very clean

If it can be of help: https://github.com/HubSpot/executr

The X to close messages doesn't respond on ipad (running in chrome for IOS but I think safari does the same)

Also, in the change location thing, can you show what the current setting is (make the corresponding box darker).

We'll take a look at it on an iPad, thanks!

Nobody's mentioned Blackbird JS yet, so: http://www.gscottolson.com/blackbirdjs/

Filterable log messages, closable and easy to stub out when you go into production.

This is more a purr/growl replacement than a alert() replacement.

This would be a true alternative to alert in older browsers if it provided what alert() doesn't: object inspection.

Something like?

    prettyAlert = function(obj){ 
      alert(JSON.stringify(obj, null, 4)); 
    }

No, I'd like to see the same as used in Firebug, a sort of expandable tree that gets updated as the object is modified.

Looks useful. Not having click to dismiss/a close button by default is sheer madness though. Users expect to be able to close popups and having it just sit there is frustrating.

Also quite of few of the examples fail for me on Iceweasel, throwing reference errors for "msg" etc.

Yep, not all the demos are 'runnable' on their own (they shouldn't look like they are). They try to use 'msg', even though its not defined in their scope [each example runs with it's own scope].

> (they shouldn't look like they are)

In that case I'd suggest not putting a big "run" button next to them and mixing them in with ones that are "runnable".

Or if you mean "they should look like they will cause a reference error" that would also be wrong - "each example runs with it's own scope" is not obvious.

Keep code that is purely "example code" and code that is intended for functionality demonstration separate. If you need to give example code as part of your explanation of the functionality it should appear with the explanation not in the same box as the demo code.

It would be nice if we were able to run the edited code for viewing purposes. Kinda like what they did here http://pinesframework.org/pnotify/#demos-simple

If you're going to build an alternative to something, it should be easier to use.

    alert("Your request has succeded!");

is way easier than

    $.globalMessenger().post "Your request has succeded!"

Would

    alert = $.globalMessenger().post

help?

Each time you call globalMessenger() it gets a chance to do some checking to make sure it's at the right place on the page and has the right classes, but if you're not doing anything fancy (like injecting it into a page which keeps getting rewritten), this should be fine.

My main concern is the amount of typing especially when I'm just wanting to debug something with alert or console.log().

It seems like overkill for a function that's (mainly) used to debugging.

That's a miscommunication then. It's mainly for providing feedback to the user, e.g. "Document saved", "Error deleting user", "Can't connect to the server, retrying in 4", etc.

For debugging, you should probably use console.log.

True, I think it was my stupidity. Sorry about that.

Not at all, it wasn't the best title. Thanks for pointing out the confusion. We (HubSpot) are all talking about writing an actual alert replacement now :).

Why not

    alert = (args...) -> $globalMessenger().post args...

This allows $globalMessenger to be notified for upkeep whenever the call to .post is proxied.

Very nice, but you really chose the wrong title. My initial reaction was "how is a replacement for alert() interesting in any way?" Glad I clicked anyway.

I was actually hoping for an alternative to using alert() in IE7, as that's the only place I still use it for debugging purposes

If you use jquery, I wrote this really simple snippet that I use for quick down and dirty debugging.

var logit = function(x){$('body').append('<div id=logit></div>');$('#logit').css({'background':'#000','position':'fixed','bottom':0,'right':0,'color':'#fff','padding':5,'font-family':'arial','font-size':'9px','z-index':9999});$('#logit').append(x+'<br>');};

It could very easily be adjusted for non-jquery too.

Then just call it like: logit(whateverYouWantToDisplay);

<sarcasm> You still debug IE7? </sarcasm>

What happened to console.log() ?

How about accessibility? Is there any story, or any plan for that?

It's a good question, we'd love to get any experience you have on the topic. I created an issue to track it if you can weigh in: https://github.com/HubSpot/messenger/issues/10.

Sweet, thanks very much!

Slick design. My gripe is backbone being a dependency.

Is there any demo page?

There was a bug with the rendering on firefox which caused the run buttons to not appear. Should be fixed!

Rock on Zack!

Reply on news.ycombinator.com