With the first round voting starting tonight, I thought it was important to update the idea log. Thanks to everyone who offered up their feedback. I am also looking forward to reviewing the guest judge feedback. Presumably, it will be posted in the next few days.
I raised the issue of pursuing a Java client approach, as an alternative to SMS, but I believe this is the wrong path. Java will severely limit adoption. Mass-market appeal and ease of use points to SMS. It is the way to go, even if it limits the potential of the application.
I want to focus this post on three major issues - pricing, receiving, and sending.
Pricing:
Telepath is not a service, it is an application. The intent here is for Telepath to be sold based on a one-time license fee. Where pricing comes into play beyond the license fee relates to the users’ own costs of receiving and sending SMS messages to/from a mobile phone.
Each mobile carrier and rate plan has specific usage limits and costs for SMS. Because of this, Telepath will have a cost impact that is specific to the individual user. One of the ideas was for the application to keep track of how many SMS messages were sent, and possibly the capping of notifications based on a cost threshold.
In my case, my rate plan includes unlimited SMS messages. Telepath should have no additional cost impact to me beyond the license fee. Other users may have prohibitive SMS surcharges, making the use of Telepath impractical. Just because all potential users can’t enjoy the benefits of Telepath doesn’t mean that the application should be shelved. Some users may be willing to pay the SMS fees based on the application’s value.
Receiving SMS (Telepath -> Phone):
With a cursory look at Google, I find a number of resources for sending SMS messages. Here are just a few:
http://www.technoblog.org/freesms/
http://www.textmefree.com/
http://www.csoft.co.uk/sms/example_code/index.htm
Based on what I saw, I do not think that Telepath will need to incur fees for sending SMS messages, at least for North America and the UK. In addition, most (if not all) of the US carriers have email to SMS addresses for phones:
* T-Mobile: phonenumber@tmomail.net
* Virgin Mobile: phonenumber@vmobl.com
* Cingular: phonenumber@cingularme.com
* Sprint: phonenumber@messaging.sprintpcs.com
* Verizon: phonenumber@vtext.com
* Nextel: phonenumber@messaging.nextel.com
Another option would be for us to partner with someone such as TeleFlip (www.teleflip.com) to manage the outbound SMS message and the company selling Telepath would eat the costs associated with this partnership as part of doing business.
I am not concerned about sending SMS messages under most circumstances. There are a number of options, and this could be resolved during the application planning phase.
Sending SMS (Phone -> Telepath):
This is one area that I have had less time to consider, and may be a limiting factor. While a notification-only implementation of Telepath has value, I have been excited by the potential of controlling a Macintosh remotely. This is only possible if we can resolve the phone to Mac issue, likely through an SMS to email conduit.
A few people pointed me to SMS2Email (www.sms2email.com). There may be a partnering opportunity here. The other possibility may be to setup some sort of SMS Server where all Telepath users send to a single SMS number, and based on the sender address, these control messages are then distributed from the central server to the individual client machines. Clearly, there would be some security issues to work on under this scenario.
Why vote for Telepath?
As you vote during this next round, don’t assume that Telepath isn’t possible and therefore should be passed over. I do believe it is possible and we’ll work out the sending and receiving issues in a way that does not create recurring costs for the users (other than application carrier SMS fees).
