My Dream App

Take a look at SoonR - I found out about this today. While it’s not exactly what I was planning for Telepath, it may be of interest to you.

Thanks to everyone for your support. I am disappointed that Telepath was eliminated, but it’s the will of the people. There are several ideas that I am excited about (and a few that I am perplexed by). I will continue to vote until the end, and will now be in a position to express my opinions openly about the remaining finalists.

Best of luck to the remaining twelve!

Thank you for voting for Teleapth - on towards round two!

Telepath survives, at least for now. It was never at risk for elimination during round one, but in the first half of voting it was in the bottom twelve, which didn’t look good for round two. As it stands now, round two looks good, but who knows how voting patterns will change for the next phase.

I appreciate your continued support.

Welcome to My Dream App and my idea, Telepath.

Please consider adding Telepath to your voting list, as you explore the various candidates. Here is the description…

We don’t always have the luxury of being in front of a computer - whether at lunch, running errands, or on travel. Telepath is an extension of the Mac using SMS as the protocol for information exchange to and from your mobile phone. Event triggers can be programmed on the Mac using Telepath to send alerts to your mobile phone via SMS, and can even trigger actions on your Mac based on your response to these messages directly from your mobile phone. Potential uses include email delivery, IM, Growl notifications, and security alerts. Telepath is a new type of “remote access” technology, with your phone as an extension of your Mac experience.

For more details on Telepath, please view my first blog entry, Telepath - your mobile mac experience.

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).