Open vs. Closed: Simple Example - Powerful Point
This happens to you all the time. You are in a meeting. It is an important meeting/interview/etc and you want your full attention to be on the meeting. 10 minutes into the meeting the phone/blackberry goes off. For bonus points, you have the hot time tonight ring tone and that goes off while you are in that meeting.
The simple solution. Not the massively complex, voice over IP routing, artificial intelligence, I'm sorry Dave I can't do that, solution. The simple solution is to simply put an add-in within Outlook so when I schedule the meeting, I can press the Do Not Disturb button as part of the scheduling. When the meeting starts, my phone is sent a message that puts it in silent mode. Simple.
On the Outlook side, there is a developer's kit that lets you add pretty much whatever. So, good on Microsoft. Good on Yahoo as they have a developers kit for their stuff as well. I guess that is the same as saying good on Microsoft. Sorry, back joke as is coming soon, Microsoft Flickr 2009. Sorry.
So, now that I have this applet inside my calendaring program, can I send a message to my device? Well, not so easy as it turns out. You can put an application on for example the Blackberry, but the API set (the way I read it) doesn't allow the developer to accomplish this task. Lots of good reasons, I suspect, like viruses running amok but the reality is I can't get to the functionality on the device which allows me to silence the phone.
In fact, it doesn't appear that any device lets me get to that functionality except, funny enough, a few from Asia that are built on embedded Linux. Others are all closed to the best of my knowledge.
There are probably hundreds of examples like this out there but my larger point is that every time there is a closed system, little things can't get solved. And when the little things can't get solved, you can be sure, the bigger things have troubles.
All of this, of course, means opportunities for you.







Rick - while I totally agree with you about the open aspect of it - some of the handheld makers do in fact do the DND during meetings thing - I have the Motorola Q, and for all it's issues, when I have a meeting in Outlook (that syncs up OTA on the Q) the phone goes into vibrate mode. Pretty nice.
Still doesn't solve the problem you call out, but helps me nonetheless.
As for hot time tonight, I'll just stick with the normal ring ;)
Posted by: Braydon | February 05, 2008 at 19:27
Rick - did I hear you say something nice about open source or at the very least open technologies? Time to check for pods or for you to check your meds. :)
Posted by: Ron | February 05, 2008 at 22:15
Isn't it just easier to switch your phone to silent when you're in a meeting? Rather than risk disrupting a very important discussion or worse, have other people hear your ring tone, wouldn't it be easier to prevent rather than to cure? And this Microsoft applet isn't even 100% ring-proof yet.
Posted by: Julie, writer surefirewealth.com | February 06, 2008 at 03:44
Julie,
Thanks for stopping by. The first point is that lots and lots of people forget and technology should make this problem go away. It is rude, I agree.
The applet was just an example.
Posted by: Rick Segal | February 06, 2008 at 07:20
Hey Rick -
Windows Mobile has this functionality built in (set your profile to "Automatic" instead of "Normal" or "Vibrate").
And if that's not quite what you need, you can change profiles programmatically: http://bansky.net/blog/2007/07/changing-smartphone-profile-from-application/
Windows Mobile also has an "SMS message interception" API which lets any app easily take action in response to messages sent to them over SMS: http://msmvps.com/blogs/donscf/archive/2006/04/03/89053.aspx
-Robert
(former PM for Windows Mobile SDK)
Posted by: Robert Levy | February 06, 2008 at 21:25
The general problem: there's no easy way to have SMS messages trigger applications. In my opinion this takes three things:
1. Carriers allowing us to send / download apps to our phones from sources other than the carriers themselves.
2. A simple, short, standard for this in SMS. I suggest something like ]A(app-id)[, followed by application data, where app-id is about 5 digits or characters, similar to the five digits used for text applications now, or the * functions, and with similar constraints/registration on the IDs to prevent duplication.
3. a "safe senders" type of list (or better, a checkbox in the phone's contact list) to identify who/what your phone will accept those messages from.
Solve the general case, and you've got a platform for lots of things!
Posted by: blooflame | February 07, 2008 at 22:06
Adding a comment to stuff i saw after posting:
While this sounds similar to the SMS message interception API noted I believe the function should be in the OS of the phone, not in an app. In other words, it should be standard for the OS to look at incoming SMS, detect that it's an application message, then start the application and pass the message to it.
The combination of user choosing to install the app (opt-in), and safe-senders list should reduce the potential for abuse.
Posted by: blooflame | February 07, 2008 at 22:11