The telephone : Just another UI

Many of you know that I’ve been doing more work with Twilio over the last few months. I’ve been progressing slowly simply for lack of time but things are starting move more quickly. We’re starting to look toward near-term deployment of new apps based on the Twilio platform. These are intended toward a general consumer audience. While it’s completely unrelated to the Pick/MV market space, MV people can use this stuff too, to enhance their existing applications. The telephone is just another UI, and there’s no reason why it shouldn’t be considered right along with email, web sites, reports, or a plain ol’ green screen.

About Twilio, I’ll just refer you to their website. If you’re a .NET developer, I strongly encourage you to look into the TSL.NET library that I published at Codeplex. TSL.NET and my efforts were profiled on the Twilio blog back in June. If you’re not a .NET developer, other libraries are available to faciliate development – though a code library isn’t really required, it’s more of a convenience.

This afternoon I looked at a request for a Proof Of Concept which was requested by a Twilio customer. Using TSL.NET I was able to bang out the POC, get a new telephone number, and publish the POC for the company to evaluate. Development with these tools can be that quick.

The POC was for an app that allowed employees “on call” to send a text to a system to indicate that they are now processing calls. When this happens, whoever was already on call gets an SMS to notify them that the other person has taken over.

My solution, and remember that’s just a POC for now, included the following:

• SMS “register {name}” to register for on call duty.
• SMS “oncall” to say you’re on call
• SMS “who” to see who is on call
• The person already on call gets the SMS when someone new sends the oncall request.
• A user can “register newname” and they will get a confirmation that their phone is now re-registered under a different name.
• You can also call the number by phone to see how many people are registered and who is on call.

To dress up the app for production use, I’d offer to add voice/DTMF operation for land-lines so that SMS isn’t required, I’d add support for more than one on-call person, I’d add an option to restrict access to the app to pre-authorized phone numbers, and I might add a browser interface so that management can see who’s on call now and all activity to-date. I could add controls to make sure someone is always on call, require confirmation from people going off-call, or to notify management if people aren’t logging in/out on a timely basis.

Heck, once that’s all complete I might as well offer it to the public as a SaaS. The Twilio model almost begs for apps like this to get published for use by whomever sees value.

But the point for now is not what the specific app is, or the details of the feature set, but about what is possible with mobile and land-line telephones, a business requirement, and a little time for coding. The limited set of commands above (register, oncall, and who) could as well be requests to a server to tell a sys admin whether or not backups completed, how much disk space is available, or whether there were errors in the daily close reports. The commands could be instructions to start a backup, to start nightly reports, or to reboot servers – because for “some” systems that needs to be done from time to time, and wouldn’t it be nice to be able to do those things from your comfy chair at home rather than having to go into the office?

The telephone is a mobile User Interface device. It doesn’t need a browser or a graphical interface. It doesn’t need a mouse or a whole lot of text to make requests or return results. The telephone is an alternative to a full-blown UI in the same way that Twitter is an alternative to blogging. Twitter is a micro-blog for when you don’t need a full blog entry to make a short statement, and telephones are excellent devices to issue quick commands and get short, fast responses.

One difference between the telephone (with voice and SMS) and other UI’s (including a browser in a mobile device) is that you can push information to it. Your server can call people or send a text message to let them know something special is going on. It can further expect responses and process them. For example: “the filesave aborted, retry or quit?” Many people would find it preferable to have that option right after the event, rather than to get the bad news in the morning. Email doesn’t normally provide that sort of interaction. (It can, but most people don’t issue commands to their systems by email. Please let me know if you’d like to do that.)

So when your end-users say they need info, you’re going to consider presenting it in a character inteface, a thick-client GUI, a browser, email, a printed report … and now you should also consider the telephone. It’s not tough. Twilio provides an excellent platform for the purpose. You can use .NET, PHP, Java, or other frameworks. You could even go direct from your MV BASIC code if you did the coding – but you don’t need to.

If you’d like some help to code a phone interface, please let me know. I can also help to just stir the creative juices, to discover places in specific environments where having telephone command and reporting capabilites would be of value.

VARs: Let’s talk about places in for-sale applications where a phone interface would present a competitive advantage – or at least where it would be an interesting differentiator in marketing material. Many VARs read this blog, and should consider that many end-users would pay for new phone interfaces if only they were available. Don’t take my word for it – have you ever heard of an iPhone mobile app? (Bet ya have!) People buy and use a lot of apps for their mobile deveices. You probably use a lot of mobile apps – but even people who use mobile apps still have a hard time seeing how they can be applied to the business software that we write and use every day. I think some developers are just too close to their own software and they get blinded by its current limitations. In this case we’re not talking about device-specific apps, but just normal telephones and texting. Have you ever confirmed a flight by phone or received flight schedule notifications by SMS? These are valuable resources which your end-users might appreciate. I can help with that.

And if you need to keep track of employees on-call, well, I might have something for that too…