SMS Text Messaging Testing Update

  Thursday, August 6th 2009

In the short period of field testing, I have found a few minor bugs which I am working on fixing - but these are relatively minor.

A few points however worth mentioning:

1. As we depend on Twitter for our text messaging - the "free" price comes with a dependency. If they are down, then our text messaging won't work. As reported in news reports on TV, radio and online - today Twitter was the subject of a Denial of Service Attack.
   
   You can follow Twitter's progress online:
   
   http://status.twitter.com/
   
   It's an important point to make that our stuff won't work if Twitter isn't working. While this is an important condition to keep in mind regarding the text messaging system in place, service disruption is something that happens to all systems. Be that as it may, we ultimately want to have a dependable text messaging service - even if we are dependent on another system.
   
   And like most services, Twitter strives to have a 99% uptime, and you can see this in their freely posted "uptime page":
   
   http://www.pingdom.com/reports/vb1395a6sww3/check_overview/?name=twitter.com%2Fhome
2. The text messages contain information from the Rip and Run faxes - this seems like an obvious statement to make, but the point I am trying to make here is that if there are type-o's or mistakes made in the Rip and Run fax itself - then the software, including the text messages will contain these errors.
   
   I am hoping to work with the county to keep these at a minimum, but the point is, incorrect data inputted to the software, will produce incorrect results.
   
   For example, one goal of the text messaging component of my software is to keep the text message length at a minimum - these are supposed to be quick and easy messages to read - ultimately notifying firefighters of an emergency. Thus, the text messaging logic is to include the location of the call, rather than the address - as it is easy to the human eye to comprehend where the call is.
   
   For example, there are two addresses at 3070 Route 50: Panera Bread, and Giavano's Pizzeria.
   
   So having the text message read "...emergency at Panera Bread" is much more informative to the end user rather than "...3070 Route 50" for a variety of reasons. First, most people don't memorize addresses of businesses (or other popular locations) and secondly, it doesn't differentiate between the two separate businesses.
   
   So its a much better logic scheme to have to include locations rather than addresses (if a location is given in the Rip and Run). That said, we had a call two days ago where the location was the last name of the caller - so for example, the text message read "....emergency at Spackmann" - which doesn't really make sense when read.
   
   Typically resident information is not given in the "location" field of a Rip and Run - its generally put in separate fields. Anyways, I am hoping to work with the county to correct this in the future.

Any questions, just let me know.

posted by spackmann in Rip and Run Development at 12:06 PM (400 day(s) old)  Permalink