Designing text-message systems for the people - some early lessons
Submitted by Igor Faletski on March 11, 2007 - 12:04pm.
in
It's been a while since the Mobile Muse developer platform was made available to the public and I always looked at it with great interest. Other projects were always getting in the way and I didn't get to play with it until late February. It only took me a few hours (and several email exchanges with Jim) to have the PHP framework running on my server. Connecting to the mobile networks has never been so easy! It seemed that I was mere hours away from having a great, usable application accessible from anywhere in Canada.
At that point, John and I already had an idea about what our application would do. Delivering Translink bus schedules over text messaging was thought of before, but high costs of SMS aggregators prevented many developers from taking a shot at the problem. We decided to do it just to set a precedent.
The first thing we discovered very soon is that since sending and receiving messages costs real money, having a stable web backend is crucial. Garbled messages, errors and anything else that can produce an unreadable response must be eliminated immediately or else real expenses will be incurred. An obvious solution here was only using our production server for actual messaging - the testing was conducted on another site which "emulated" text messages by displaying them on-screen. That worked out pretty well - according to the logs of the Mobile Muse developer portal, almost all of our messages are valid.
The second problem (and also one which we still have to solve) is the response times of the service. When information is delivered over email, it rarely matters whether it takes one minute or five minutes. With text message delivery, it can take up to 10 seconds just for the "fixed" time cost of getting the message to the web service and pushing the response back. As a result, if the web service itself takes more than a couple of seconds to generate the response, the users will put their handset away, thinking that "something broke". When the message gets there in a few seconds, the device has to be taken out again, impacting the overall user experience. Two possible solutions here are aggressive caching on the backend side and strategically hosting the server, to make sure it has the latency and the computing power to process the requests as fast as possible.
The last issue is the overall usability. Both the Web and the Mobile components have to be top-notch, especially in a country like Canada where users are scared of possible costs associated with discovering and trying a mobile service. The website has to be friendly and clear enough to explain how to use the system (and how much it costs) while giving the users a chance to customize the experience and retain the instructions. The mobile component should minimize the need for memorization by introducing friendly shortcodes and message tokens.
In general, designing mytxt.ca was a great experience that just might turn into something sustainable in the long run. Thanks to Mobile Muse for giving us this opportunity!
At that point, John and I already had an idea about what our application would do. Delivering Translink bus schedules over text messaging was thought of before, but high costs of SMS aggregators prevented many developers from taking a shot at the problem. We decided to do it just to set a precedent.
The first thing we discovered very soon is that since sending and receiving messages costs real money, having a stable web backend is crucial. Garbled messages, errors and anything else that can produce an unreadable response must be eliminated immediately or else real expenses will be incurred. An obvious solution here was only using our production server for actual messaging - the testing was conducted on another site which "emulated" text messages by displaying them on-screen. That worked out pretty well - according to the logs of the Mobile Muse developer portal, almost all of our messages are valid.
The second problem (and also one which we still have to solve) is the response times of the service. When information is delivered over email, it rarely matters whether it takes one minute or five minutes. With text message delivery, it can take up to 10 seconds just for the "fixed" time cost of getting the message to the web service and pushing the response back. As a result, if the web service itself takes more than a couple of seconds to generate the response, the users will put their handset away, thinking that "something broke". When the message gets there in a few seconds, the device has to be taken out again, impacting the overall user experience. Two possible solutions here are aggressive caching on the backend side and strategically hosting the server, to make sure it has the latency and the computing power to process the requests as fast as possible.
The last issue is the overall usability. Both the Web and the Mobile components have to be top-notch, especially in a country like Canada where users are scared of possible costs associated with discovering and trying a mobile service. The website has to be friendly and clear enough to explain how to use the system (and how much it costs) while giving the users a chance to customize the experience and retain the instructions. The mobile component should minimize the need for memorization by introducing friendly shortcodes and message tokens.
In general, designing mytxt.ca was a great experience that just might turn into something sustainable in the long run. Thanks to Mobile Muse for giving us this opportunity!
- Igor Faletski's blog
- Login to post comments
