I was recently talking with a colleague of mine who works in the construction industry about blended learning techniques. To address one of her concerns, I suggested that she send best practices (from ILT sessions) via text message to workers in the field.
If you are currently doing this, would you explain what platforms/software you are using to generate text messages? I'd like to give her a two-to-three sentence answer when we speak again. I'm good with the spacing principles (a la Art Kohn), but need help with the mechanics of making it happen.
I haven't done this yet but have been doing a bit of research. There are some things that I'd consider:
1) Functionality and implementation. Really depends a lot on what you want to be able to do and how you want to be able to do it. You'll find many more API's for sending and receiving SMS messages than you will simple sites (most folks are going to have very specific / niche things they want to accomplish) so you'll get MUCH more flexibility using a cloud API. However, that means someone will need to buckle down, know what they're doing, and bust out some code:)
2) Costs. These are really pretty trivial per message but could add up. See these two for examples of pricing for cloud API's. These services allow you to connect your own application to send or process received SMS messages. You'd need to custom develop an application for these:
These seem to offer some flexibility in how things are sent in addition to offering an api for connecting to a custom application. Pricing isn't as transparent but it would surprise me if each text cost much more than a penny each.
3) Security. The last thing I'd want to do is expose participants phone numbers to a skimming service somewhere. Some of the services I found felt a little "suspect". See this service listing for the bulk of the places I used as starter for research. https://www.mashape.com/explore?query=SMS
Here's the messagebird interface. It's really expensive per-message at 7.5c European relative to some of the other API's. On the positive side, it's really simple to add credits and dispatch messages. It's also out of Amsterdam. This could work well for many companies but a client like the US Gov't might balk at it.
Steve: Man, thanks so much. I hope you are patient, as I ask a few basic questions to help me better understand:
1. Could you more fully explain the benefits of going with a cloud api versus a simple site? I don't quite see how the former allows for greater flexibility.
2. If one does go with a cloud api, could you give an example of an application to which one would connect to send the messages out?
Really appreciate your thoughtful reply, Steve. Above and beyond. As usual. --Daniel
No worries. Sure. With a cloud API, you have lots more options. Some of these cases may be supported in the interface similar to messagebird above but I couldn't find them. In these cases, the SMS API is just the radio. The application takes care of processing incoming and outgoing traffic over the radio.
If you wanted to schedule messages. You could setup a simple "calendar-like" application for the instructor. The application would send the messages automatically when the date / time was reached.
If you wanted to connect the SMS or Voice API (most have both) to Moodle or another open LMS product, you could. So if you wanted to dispatch a text a week after a participant submitted an assignment. Or 2 days before it was due. Or capture questions from students. Or send grades automatically through SMS. You could do that. It wouldn't be easy to wire in but once the work was done... it would just work.
If you wanted to write an application on the server to allow the instructor to send out quick survey questions or ask the participants to take a picture of their environment and text it back the application could handle all of the "middle-man" operations and store / dispatch messages through the service API.
If you wanted to wire your SMS send and receive into the xAPI or another API, you could do that. Each thing does its thing. And it's as automated as you design it to be.
There may be an issue with sending text messages to construction sites. Some worksites don't allow cell phones on site, as it could be a distraction hazard or a explosion hazard in flammable atmospheres. It would depend on the specific practices with that company and worksite.
Definitely a consideration. However, sending SMS to a registered phone can be picked up later. So when they get their phone to check at lunch or at the end of the day, they can receive the sent message then.
Thanks so much, Steve. You've given my colleague and I much to think about... and research. If it's ok, I may reach out to you directly as I go deeper into this.
It's worthwhile noting that the vast majority of business SMS providers will charge for undelivered messages. This could mount up as your workforce churns and data gets long in the tooth.
The SMS API provided by the SMS Works a delivered-only service in the UK, which ensures that you only spend when messages are delivered.
10 Replies
Hey Daniel. Excellent question. I'm excited to see what ideas the community will surface for this one...
Hey Daniel -
I haven't done this yet but have been doing a bit of research. There are some things that I'd consider:
1) Functionality and implementation. Really depends a lot on what you want to be able to do and how you want to be able to do it. You'll find many more API's for sending and receiving SMS messages than you will simple sites (most folks are going to have very specific / niche things they want to accomplish) so you'll get MUCH more flexibility using a cloud API. However, that means someone will need to buckle down, know what they're doing, and bust out some code:)
2) Costs. These are really pretty trivial per message but could add up. See these two for examples of pricing for cloud API's. These services allow you to connect your own application to send or process received SMS messages. You'd need to custom develop an application for these:
These seem to offer some flexibility in how things are sent in addition to offering an api for connecting to a custom application. Pricing isn't as transparent but it would surprise me if each text cost much more than a penny each.
This one is a little more pricey at 8.5cents per SMS, but I suspect that's because it offers the ability to send via their site.
3) Security. The last thing I'd want to do is expose participants phone numbers to a skimming service somewhere. Some of the services I found felt a little "suspect". See this service listing for the bulk of the places I used as starter for research. https://www.mashape.com/explore?query=SMS
Here's the messagebird interface. It's really expensive per-message at 7.5c European relative to some of the other API's. On the positive side, it's really simple to add credits and dispatch messages. It's also out of Amsterdam. This could work well for many companies but a client like the US Gov't might balk at it.
Steve: Man, thanks so much. I hope you are patient, as I ask a few basic questions to help me better understand:
1. Could you more fully explain the benefits of going with a cloud api versus a simple site? I don't quite see how the former allows for greater flexibility.
2. If one does go with a cloud api, could you give an example of an application to which one would connect to send the messages out?
Really appreciate your thoughtful reply, Steve. Above and beyond. As usual. --Daniel
And btw, the messagebird interface did seem pretty friendly, easy to navigate. Thanks for sending the screenshot.
No worries. Sure. With a cloud API, you have lots more options. Some of these cases may be supported in the interface similar to messagebird above but I couldn't find them. In these cases, the SMS API is just the radio. The application takes care of processing incoming and outgoing traffic over the radio.
There may be an issue with sending text messages to construction sites. Some worksites don't allow cell phones on site, as it could be a distraction hazard or a explosion hazard in flammable atmospheres. It would depend on the specific practices with that company and worksite.
Definitely a consideration. However, sending SMS to a registered phone can be picked up later. So when they get their phone to check at lunch or at the end of the day, they can receive the sent message then.
Thanks so much, Steve. You've given my colleague and I much to think about... and research. If it's ok, I may reach out to you directly as I go deeper into this.
It's worthwhile noting that the vast majority of business SMS providers will charge for undelivered messages. This could mount up as your workforce churns and data gets long in the tooth.
The SMS API provided by the SMS Works a delivered-only service in the UK, which ensures that you only spend when messages are delivered.
This discussion is closed. You can start a new discussion or contact Articulate Support.