15 Sep 2005 grey   » (Journeyer)

Some assembly required, glue not included.
TXT/SMS directions to cell phone. Initial spec/draft.

Section 1: Intro/premise/justification:

The other day before driving to meet a friend & go to a concert, I wanted to look up driving directions to his house and then the venue. Rather than print these out, I thought I would just send them as a text message to my cell phone. I had remembered that mapquest had a "send to phone" option before, and though what the hey. Unfortunately, when I clicked on that link this time - it isn't just a simple text message, it requires a Get It Now/java applet type download and a $4/mo subscription more or less. They also had a send to PDA, which requires avantgo so again - additional software is required, as well as syncing steps and the like. I can understand that, they're using traditional approaches to getting content to these mobile devices, and in the case of mapquests' send to phone thing - they have a business and want to make money. But I think they're also missing a bigger picture.

Not everyone has a PDA, but a LOT of people (even kids) have a cell phone now. However, not all cell phones support these java app things, moreover - while a map is NICE to have, it's by no means necessary. Just about any modern cell phone (or heck at least any of the FREE with subscription type cell phones, let's not go into 5+ year old analogue phones) support a TXT/SMS message, and the cost per message is either very cheap, or included with your basic plan just about now. In other words the txt/sms message is ubiquitous - has a huge footprint, and doesn't require additional software to be loaded. If you can send a text message with a simple smtp client, or heck a 12-key phone pad, that seems to be the lowest common denominator/biggest footprint of any portable device (again, way more cell phones than PDA's).

If I had a pencil and paper I would just jot down the turn-by-turn, they already give me the turn-by-turn (plus a lot of other stuff I don't care about like mileage between each) which I just don't want to have to transcribe by hand or print. Most people look up directions before they leave. Even though Sprint & Garmin recently announced a $9/mo subscription service to do on-the-fly mobile GPS Navigation, which is very cool - that's a lot more than people need. Moreover, I don't have Sprint, my cell phone is company paid for I don't have a choice in the carrier (they use Verizon and Nextel depending on your job responsibilities, I got a verizon phone). I really don't want to have to worry about what cell phone provider I am using for something this basic, I don't want to have to use some sync software or Java app that may cost me money or require me to install things I may not be able to.

I also want to stop wasting paper - I HAVE to carry a cell phone. Heck, txt/sms messages can even be sent to most modern pagers, the footprint/cost for these things is HUGE as an information delivery platform.

But where are the tools to do this? Well, they're all there already, they just need some glue. Last night I spent about a minute glueing by hand, but as I did it, it occurred to me that this glue should be easily automated programmatically, so that instead of me spending a minute, a program could do it in microseconds.

One more note: while researching this more, I came across GoogleSMS http://www.google.com/sms/demo.html. This is closer, it's free and let's you interact from your cell phone directly. This is great, but still not quite what I'm hoping for, here's why:

As I said earlier, I want to do this before my trip, when I have access not as I'm driving or on the road. Ok, that's minor (arguably it's actually better to add the feature to do this remotely as GoogleSMS already has, since it's way more useful that way for anyone) and not really a complaint, just a different usage. But, I'd also like to send it to a text pager, googleSMS can't work that way currently because it requires interaction, my pager can't do that. Remember what I said about wanting to do this to use the maximum footprint? Well, text pagers fall into that realm for me.

Section 2: What I did in the present (i.e. the human GLUE)

1. I went to google maps maps.google.com and put in my from/to crap.
2. I clicked the search button.
3. I copied the direction text.
4. I pasted the text and sent an email to my phone#@vtext.com (actually I used www.vtext.com's form, but you could use any simple smtp engine/client).
5. Checked txt message on phone.

Wow, done took me less than a minute, really simple - why the hell hasn't someone written a little glue to do this automatically? OK, some have done a lot more than this, but no one has delivered quite what I'm hoping for. If you know of someone who HAS done this already, let me know please, and I'll save my breath. There are also some obstacles... I'll present those next as well as what tools are already out there to help.

Section 3: Obstacles/Requirements

1. Phone # to carrier smtp address lookup parser.

Ok, the first one isn't actually related to the direction part - it's how to get a message to your cell phone with just a phone number as entry. Not everyone is going to know that phone#@cellphonecarrier-smtphost.com type address for their phone, or pager. You will have to match up the NPA (area code) NXX (next three digits) to a carrier and thus email address format appropriately.

1a. Sanity Check

It's probably a good idea to implement a sanity check to make sure input is alphanumeric, maybe allow for it to include - and (). Country codes could get evil, but let's just worry about North America for starters. Don't implement a sanity check and let it barf if you're making a first run of it sure.

2. TXT/SMS message character limitations lookup.

Each cell phone/text pager has a limit on the number of alphanumeric characters that can be sent per TXT/SMS message. Verizon is 160 characters, some carriers are 110 characters. It would be best to know this in advance, and if the number of characters in your message is greater than that carrier-max-variable number.

3. Message splitter.

If the number of characters in your message is greater than that carrier-max-variable number, then split the message and send two, or three, or however many is divisible by that #-of-characters-variable. If you don't do this, your message will get truncated and be missing the end, which is arguably the most important point. 'Course for a PoC initial run of things, maybe skip this step, but definitely leave it in for rev2.

Note: Parts 1-3 go together as a foundation, but could be useful for lotsa other things too (most TXT/SMS aware clients do this automatically, I'm not sure where, as I'd imagine that #1 and #2 would best be implemented at a carrier gateway level. However, most/any/all? cell phones I have used with TXT/SMS functionality have done #3 in-client [i.e. even your cheap-o cell phone splits the message, does it just guess @ the maxchar variable, or use the native carrier setting as a default, or does it have #1 or at least #2 already stored? Maybe this sort of information is what OTA updates are useful for]).

4. To/From get direction parser.

You need to feed your start/stop info to the directions engine (e.g. maps.google.com, mapquest.com, yahoo maps, etc.). Google maps 1:1 field for To and From is really nice in this way. Ideally take that. Push it out.

5. Direction output text scraper.

Once you get back the directions output, just grab the pertinent direction text and copy it a buffer or variable or something for use at the end.

5a. Returned directions sanity check

If you get one of the "this address doesn't exist/needs clarification" then you need to go back to #3 and get the user to re-input it. For an initial go at this, you could forget this error checking step - don't leave that in for any production system, but who needs sanity checking for PoC? (famous last words?)

5b. Direction cleaner/trimmer/substituter extraneous crap reducer/substituter

If you wanted to get really fancy you could trim out the extraneous things that are returned in the output (like mileage between direction instructions) and shorten/substitute key terms (e.g. LEFT becomes L, RIGHT becomes R, EXIT becomes X or something). It's probably easiest to first implement substitutions for key terms, and then implement ripping out crap most people don't care about like mileage. This is totally optional - and for a quick get-it-off the ground demo implementation should be skipped, especially if you've implemented #3 already. #3 will take care of extra crap by sending more messages if you go over. But if you get this feature implemented, then when #3 gets called you might be able to save TXT/SMS wastage which could in some cases translated to small amounts of money being saved (like pennies per message sent). I would strongly suggest implementing this, but do it as a rev2. I don't want to make this too complicated, but this is the one feature I'll leave in the original spec that is completely optional, by spec v2 or v3, it should be mandatory (but all other specs should hopefully be done by then in some rough form), if you're trimming optional things, this goes first - trim the sanity checks last, and of course the unsubbed #'s are not optional.

5. Send the message.

By now, you've done #4, so you can take the output retrieved in #5, as well as all the stuff in #1-3 and put it all together and send it, yay!

If this weren't flat html written in my spare time I would probably want to flow chart this out, but the process should be pretty intuitive, and in some cases I did state what goes first/comes next so you're smart you can figure it out I'm sure. Or spend a couple minutes drawing the flow out on paper just to get it clear.

Section 4: Things that do this work for you already

After all, as I sit here I'm thinking that all the tools for this exist already, I don't want to write them from scratch nor do I think that needs to be done, I just want them to be glued them together. Particularly as google maps has an API, this should hopefully be easy right? Well, a little more research reveals that google maps currently doesn't have an API for their directions engine, but there may still be ways to get at it (or not, if that changes or has changed).

So what is already at our disposal?

#1 http://www.telcodata.us/telcodata/telco let's you do NPA/NXX lookups to carrier. 'Course to use this you may need to do something like #4 & #5 again, I've seen other sites feed to their engine already e.g. http://freesms.1888usa.com/revcell.htm so this might not be too hard, and any licensing concerns might already be waved because like I said, others are doing that already. Definitely with all of this check on terms of use, don't go building this and advertising to the world unless you're in line with them, but that should be obvious.

#2. http://freesms.1888usa.com/ Has a list of the carriers individual email addresses as well as character limits for each.

#4/5 - well there's a lot of direction services already, mapquest, yahoo maps, google maps - pick your poison.

Tools to glue: dunno, curl, scripting language? Your choice.

Frustrations (opportunities?) & Future

As discussed previously, Google Maps has an API - but currently not directly for their directions portion. D'oh! Also, Google SMS let's you do a lot of this already, directly from your phone, but as far as I've looked I see no way to interface with GoogleSMS directly from a browser. I'm sure somewhere in the bowels of Google are a couple of people who could put this together themselves, such that you look up directions on google maps, and then you don't just have links for javascript:_print() javascript:_email() and link-to-this page, but you could have a javascript:_sendSMS() option as well. I don't know if doing a proof of concept is even fruitful, but I've told this idea to three people in the past couple days, and all the responses have been positive - just someone needs to do it, so I thought I would write up a spec as I saw it needed, even if you wanted to try to cobble it together yourself. I guess this way I can forward this write up as a feature request to the google maps group and see what they have to say. But if anyone wants to try to do this with some spare time hopefully I didn't leave much out. Again, most of this has been done already by others.

If you wanted to get fancier, you could start looking into sending a picture of a map as well, but y'know that's going to start cutting out the number of potential clients who can take advantage of the data. I've been looking at a simplest implementation, highest target footprint/audience approach. You could add on all sorts of other things later. I've heard great ideas about hooking into the integrated GPS of more recent cell phones and getting positional information based on that - again awesome stuff, and the Sprint+Garmin things no doubt do that, but that's heavy weight and costs money currently or is tied to a carrier. If you wanted to go ahead and glue some of these pieces together yourself (#1-#3 being most important first) then you could stick whatever you want in the data, be it directions, pictures of maps, positional/GPS distance-to-interestingpoint stuff (so far that's what most of the uses of the google maps API have been, be it to find hotornot people, gas prices by locale, or the opposite side of the earth). All clever stuff, some quite useful - but all higher layers and bigger projects. I just thought here's one useful, practical and simple starting point.

Anyway, I welcome comments (though I should probably look to another hosted blog that actually has comments by default now that I say that) so umm, you can email christian.c.david-!AT!-gmail.com If you know of someone/place that has already done this le tme know too! Remember I JUST want txt/sms done from a browser to a txt/sms aware device, even if it's one-way such as a pager, and ideally with all the map directions stuff already for this particular application - googleSMS doesn't help me with all of that criteria, not yet at least.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!