Meet the eQuake Alert! Developer

Priyadarsan Venugopalan

$9.00 suggested


Enjoy this add-on?

The developer of this add-on asks that you help support its continued development by making a small contribution.

Why was eQuake Alert! created?

"Just for Horror!" - Creator Priyadarsan Venugopalan's original humorous comment. :)

Developer Leif Westerlind was just an ordinary user, who thought the add-on was something cool and special, and left ordinary reviews complaining about ordinary things, as well as some compatibility reports. He finally got too annoyed that nothing was happening for so long, and nobody was stepping up, so he stepped up. He went on the Facebook page, the home page, looked up all contact info he could, and sent a "spirited" email to all of Priyan's email addresses. (BOOM!) Reply within half hour. =D Not long after, he was a developer and doing all the work. ;)

What's next for eQuake Alert!

New developer comes onboard and "shakes things up".

First goal is to get this addon to function and to pass the AMO review process, which has changed dramatically since the previous release 8.0.1 back in 2013. The new version 8.1.0 is currently queued for full review. To get this started as quickly as possible, the Geomap editing feature had to be removed to pass review, as it would have to be completely reimplemented from scratch to comply with new security policies and best practices. Rather than delay further, the choice was made to remove the feature entirely. However, the filtering functionality remains intact, and any previously defined areas can still be used.

Next goal, two options. Either migrate from XUL/Overlay to Addons-SDK/jpm now, or try and get the Geomap functioning again. We are in favor of migration. By end of this year, perhaps early next year, XUL will be removed entirely. The migration has to happen. Leif came onboard this project in the middle of one of the biggest changes in the addons development environment, and there's a steep learning curve. Oops. This means the Geomap feature development will be pushed back a bit. But moving to the new Addons-SDK/jpm may help speed up the development process once migration is complete. It gives us an opportunity to completely rewrite the addon from scratch. We can also explore different user interface designs. Oh, and maybe get this addon working on the mobile version of Firefox.

The return of the Geomap, and why it had to die. Mozilla's Security Policy for addons, including the automated validation prerequisite to full review by other developers as preconditions for mandatory code signing, has a lot more requirements than it did a few years ago. A LOT HAS CHANGED. They no longer allow externally loaded scripts. Period. This means that ALL JavaScript libraries have to be downloaded and included in the addon's .xpi file. The Geomap feature was powered by Google Maps API. Google Maps API license STRICTLY AND EXPRESSLY PROHIBITS any and all downloaded integration of the JavaScript libraries OR access to their map data. End of story. Bye bye Geomap editor. However, there is some hope and some promise. We are looking at the potential to integrate a very similar, but free and open source software library called Leaflet along with map tiles from the OpenStreetMap project or perhaps MapQuest, as they both have some quality map styles available under a permissive open data license.

Also, languages. All languages except en-US have been temporarily removed. During the automated validation process, numerous errors were found, and translations were incomplete. This will take more time to resolve. Most current users (80+%) are using English, and all locations are in English anyways, as the data comes from the USGS website. We decided that it was more important to have a program that functions get released as soon as possible, and then that buys time to fix things like this.

Finally, feed format. historically we used the RSS feeds, but those have all been changed by the upstream information provider (USGS). The preferred method is to use GeoJSON queries and get more specific queries which means transferring less data, which saves them money. However, in order to get this interim release out quickly, it was decided to just use the Atom format, which is 99% similar to the RSS format, in that they are both XML based feed formats. This allowed for quick repair of the feed processing code. But there's still so much room for improvement here.

This is a tough job, trying to convince you to get excited about getting back functionality which you already had in the past. We realize that. But Leif has reviewed ALL user reviews and compatibility reports, and has gathered some great ideas about what users feel is important. Some of the best ideas came from some of the oldest comments and as a result, we can imagine several nifty features. But coding them all takes time, and may be more complex than at first glance, so no promises can be made. But here are some things being considered, to determine feasibility.


We currently have browser shaking, but it sometimes scares or annoys people, and can interrupt workflow, and can mess up minimized states by making browser visible, or maximized state by making browser less than maximum size then making it big but not technically maximized, etc. Some people like the feature. But it won't work on the mobile Firefox. So we need other options, and clean up the min/max if possible. It can also easily be missed if looking away from screen. Someone even mentioned the idea of color coding text according to magnitude. This is much easier to accomplish in the new Addons-SDK/jpm. We're not sure exactly how best to present that, but it is an interesting idea to consider.

We have an icon that changes color for a little while. It can likewise be easily missed. Currently it is positioned in the addon bar, which requires an additional addon such as The Addon bar (Restored) or the Classic Theme Restorer. Moving to Addons-SDK/jpm will allow us to put the icon anywhere we want (including back on the addon bar if one of the above addons is installed). But the new API allows for badges buttons. We can have a button that not only has an icon, not only has 2 colored icon states, but also has a little numeric indicator which could tell us how many new earthquakes we have.

One option is to use plain text in the statusbar. Which can be problematic. Especially if something in the feed format processing breaks, and goes uncaught, the addon may just blast huge strings of junk into the user interface. That would not be good. It could even be very bad, if someone exploited that weakness to do very bad things. ;) Sanitizing data to prevent such things is one of the strengths of using the Addons-SDK, because these tasks can be done much more simply and in a more secure manner.

User interface:

As a user, Leif has also enjoyed other popular addons, especially Forecastfox. The user interface elements are nice. Multiple icon states with graphics, little popup panels with various data in a colored and stylized view. Maybe even a map popup. All of these functions will get a lot easier with Addons-SDK/jpm and a library such as Leaflet.

Options and Configuration:

It might be better to give the eQuake Alert Options its own wep page to configure things, rather than a small grey popup box. This also means the Geomap area could be made bigger, and thus editing a Geomap could be easier.


Some people have expressed a desire to enter a zip code and configure a radius of say 25 miles by default. Not sure how to translate zip codes into geographical latitude and longitude, but the data likely exists and this likely could be achieved.

Others have multiple friends or family in different regions across the world, and would like one tool to keep them updated about all of them. The filtering has to be more complex than a single polygon, or a continent level polygon (what about Oceana, the most vulnerable place to tsunamis, as they have no continent). Arbitrary number of simultaneous disconnected polygons. Straightforward gruntwork. But may provide an opportunity to learn some algorithm optimization techniques. Also, each region may have it's own magnitude, so this feature has to allow for that. The current options only allow for a rudimentary set of filter options: no filter (everything everywhere), magnitude everywhere, every magnitude in a region, every magnitude within region, and every magnitude outside region, and specific magnitude inside or outside of a region, or both. Although rudimentary in nature, it is a complex enough abstraction to create. ;) So expanding that abstraction would be a massive effort, but very rewarding and interesting to develop.

Feeds and other Tasty Bytes:

Upstream feed format changes have always been an issue. XML based feeds like RSS helped greatly, but those XML files did sometimes get changed around, and things broke. Other newer XML formats like Atom, the successor to RSS, are almost identical, yet can in some cases be a step BACKWARDS from RSS, due to the introduction of some randomness in the file format. (i.e. the old USGS RSS feed was simpler to parse, because the new Atom feed introduced some key pieces of data being stuck inside a CDATA content inside a tag, after some other random content. more complex to parse, more prone to breakage if the format changes). Unstable feed formats are just bad. The USGS has made available GeoJSON formats. (Queue the music of angels coming to rescue us.) JSON is a lot easier to work with, especially when we're already coding in JavaScript. Getting all the data in GeoJSON will mean easier (less code, less development and debugging and maintenance) for feed processing. It will also mean ease of reuse and passing the data around to functions, such as those within Leaflet.js, which can let us do many more powerful things, all while spending less time transferring and parsing large XML feed files.

Another user suggests using feeds from multiple sources, not just the USGS. Indeed, this has been on our minds, but it has proven difficult to locate feeds from different places around the world. When finding some feeds, they are not providing a queryable server script which spits out convenient GeoJSON. Some of these places don't even have proper feeds, but just spit out a list inside a broken HTML file. -_- Shall we mount a crusade and have Leif single-handedly smash down the doors of colleges and government organizations worldwide, and rewrite their server side scripts to provide queryable databases with standardized outputs, all covered by an open data base license? ^_^ Perhaps not just yet. But we can at least make the feed processing code modular in nature, so that we have multiple processors side by side, reuse as much code as possible, and minimize and simplify the implementation of the feed-specific processing. But, we need YOUR help here. If YOU have the feed URL in your hands, let us know, send it to us, send us the page you found it, the name of the place, all info you have. It is very time consuming to try and find this information when you have no idea where to look, and all the pages are written in a language that makes your screen remind you of ants attacking a sugar cookie.

About the Developers

Developer Information
Name Priyadarsan Venugopalan
User since March 5, 2007
Number of add-ons developed 2 add-ons
Average rating of developer's add-ons Rated 4 out of 5 stars
Developer Information
Name Leif Westerlind
Location United States of America
User since March 24, 2016
Number of add-ons developed 1 add-on
Average rating of developer's add-ons Rated 4 out of 5 stars