Although not directly involved in the project beyond some high level discussions, it has been a pleasure for me to assist in its testing. The new system allows customers to browse a store’s menu, create an order and place it directly with their chosen store – all from the comfort of their PC or mobile phone. At the moment, payment is cash only with the facility for credit card payments to be launched soon.

It was pretty neat to fire up my browser, login and customise a pizza (chicken and mushrooms with extra jalepenos if you must know), and have it delivered to my door a few minutes later. All in the name of software quality assurance of course.

So next time you’re in the mood for pizza, why not take a look at ordering online at www.debonairs.com or www.debonairs.mobi if you’re not at a PC.

We’ll post some more comprehensive case studies on the technical aspects of project at a later stage, but if you have any comments or questions about the system itself (service and culinary feedback should be directed to Debonairs obviously), feel free to get in touch. To my knowledge this is the first online fast food ordering system launched in the country, where the order is placed directly at the kitchen when you checkout.

Happy ordering.

Naturally, through our work on Mobile Researcher and Mobenzi, we’ve had a lot of technology decisions to make along the way. It goes without saying (although I’ll say it anyway) that I do not believe in a “one technology fits all approach”. SMS is obviously great for ad hoc, instant communication and a range of other communication-oriented tasks. But it falls down in a lot of other, more complex (and sometimes more valuable) scenarios.

Here are 5 reasons why:

1. Usability

Although people are familiar with how SMS works, they aren’t normally familiar with what your service is or how it works. I’ve seen loads of solutions which force users to format responses (commands, requests, etc) in cryptic ways so that a system can understand them and render the correct service (e.g. looking up information). This is one of the main reasons we’ve built Mobenzi in an attempt to improve the usability of SMS by adding real people to the mix.

2. Cost

Although SMS costs are probably coming down (I hope?), when one considers the transactional cost of an SMS, it’s a hellishly expensive way to conduct multiple interactions with people. Cost can even be a factor with reverse-billed services because SMS has a perceived cost which can act as a barrier to user participation.

3. Service portability

If you’re planning to use a short code, you can almost forget about using the same one worldwide. It’s often difficult, expensive, and/or impossible to register the same code in different countries. This again reduces the usability of the service (or at least increases the training you need to do in each country).

4. Connectivity

While SMS coverage is generally much better than data coverage, it’s still patchy in areas (even in very mature mobile markets like SA). Using a system which can’t work offline (rather than a smart client application) puts you at the mercy of coverage dynamics.

5. Building for the future

I don’t have anything more than anecdotes and my own experience to support this but as if you look at even the low end models being brought out these days, its a relatively small percentage that don’t have internet connectivity. If you’re going to base your service on SMS now, it seems somewhat sensible to have a medium term plan to migrate it to IP. And be prepared to expend significant resources in that process. Swapping an engine whilst in flight might not be impossible – but rather expensive I would postulate.

Trying to take sides or apply a “technology x is better than technology y” approach is futile and in my opinion a waste of time which could be better spent leveraging an appropriate technology to solve a problem.

I believe the biggest barrier to wide-spread adoption of IP-based mobile services is that operators and manufacturers are generally pretty poor at shipping “internet-ready” devices. Don’t even get me started on signing applications which are able to use protected handset APIs.  That’s a rant for another, longer blog post.

With this ambition, and some help from the Business Trust’s Shared Growth Challenge Fund, we’ve launched Mobenzi – a technology service which seeks to remunerate low income workers for completing simple tasks on their phones which are valuable to business and are not easy for a computer to perform. The name originates from the Zulu word for work – “umsebenzi” and the concept of mobility.

Over the next few months, we’ll be running a series of pilot projects to craft the software offering, assess tasks which work well, and work through a million other challenges.

What’s really exciting for us is that this is finally happening and allows us to pursue our philosophy that you can combine software, commercial enterprise and social development. We’ll be sharing a lot more about the initiative on the Mobenzi website – we hope you’ll join us on the journey.

Over several months we worked closely with them to prototype and test early versions of our mobile application. The project demands pushed the envelope of what was possible with entry level handsets of the time. The rudimentary web-based survey designer also began to take shape.

In the early days, the Mobile Researcher back-end was a PHP/mySQL implementation which utilised the CakePHP framework (a Ruby-on-Rails port). As the solution grew in complexity and response volumes swelled with large scale data collection projects with the Medical Research Council and Human Sciences Research Council, we felt that a migration to a more robust ASP.NET/SQL Server platform was warranted.

Once we migrated to what is now our current architecture, we launched our API which has facilitated the development of bespoke systems, providing capabilities for real-time logistics management, monitoring and evaluation in addition to paperless data collection.

Starting out, we weren’t exactly sure what we’d end up with or even whether what we wanted to achieve would be possible with such limited devices. But now, almost 4 years later, Mobile Researcher is an enterprise level SaaS field research and data collection platform which includes many of the features of solutions designed for “high-end” hardware. Whilst the feature set is continually growing, it’s the simplicity and familiarity of the solution which we keep central as we forge ahead with development.

The MobileActive08 conference, due to take place between 13 and 15 October in Johannesburg, South Africa will bring together a wide spectrum of stakeholders to explore, discuss, debate and discover methods to “unlock the potential of mobile technology for social impact”.

Being avid proponents of the important role which mobile and web technologies can play in addressing real-world issues, be they in a commercial or social context, we’ll be participating. Through the demonstration of our Mobile Researcher service we’ll collect, crunch and analyse real-time data at the conference. We’re really looking forward to the exciting lineup of speakers and other contributers.

Mobile Researcher has been leveraged by a number of organisations involved in areas of social impact such as Health, Education and Service Delivery. This conference, provides a wonderful opportunity to showcase the service which allows for surveys and forms to be designed online and deployed to standard mobile phones for conduction. It also provides a platform for ideas to be exchanged and collaborations forged.

For more information on the conference, visit www.mobileactive08.org.

The use of the mobile web is currently quite limited due to several factors including:

• Lack of education and understanding of the general public of how to access WAP sites.
• Inherent navigational difficulties of mobile browsers (typing in URLs on a phone is quite a tedious process).
• Setup requirements for connectivity settings and data services.

What are mobile website or WAP sites good for?

• Providing access to rich media information including text, images, audio and video (via download).
• Downloading content such as images, video and applications.
• Capturing structured, formatted information or data which must be validated in some way (examples include a booking, reservation, customer information, order, etc.).
• Simple “conversational” interactions – where the state of the interaction must be maintained or where the context is important.
• Membership-type requirements and restricting access to information or services via a login system.

What are mobile website or WAP sites not good for?

• Applications for use in areas with limited or unstable connectivity.
• Client-side processing (i.e. performing some custom action on the recipient’s device such as storing or retrieving information).
• Highly interactive or “suspend and resume” type situations.
• Smart client applications where most processing should be offline and only synchronisation performed online.
• Interfaces which require any degree of complexity beyond simple images and form elements.

What is the extent of device support?

• Most phones, even those in the lower tier have some level of WAP support.
• In South Africa, many of the network operators (as of this blog) do not have data services enabled by default which means some users’ phones may not be set up to access WAP.
• This situation is changing quite rapidly however.

Example application

The Qpid service has a mobile website which provides access to frequently asked questions, privacy concerns and other information which allows users to learn about the system without needing to find a PC. You can access the site from your mobile phone by navigating to http://m.qpid.co.za.

The Qpid WAP site is very simple. We developed a more advanced mobile website for one of our clients which allows call centre agents to produce deals for customers from a web interface and send a WAP push (link to the WAP site) which contains the specific deal information (product photo, pricing, etc) – all whilst on the phone to the customer.

This post forms part of a series on a comparison of mobile technologies.

Bulk SMS usually involves integrating with an existing database of users (from a CRM system for example) and automating the process of sending information to these users. A simple example is when you log into internet banking, you can elect to receive an SMS which contains your one time pin (OTP).

2-way SMS allows SMS’s to be sent to end users and for those users to respond to these messages. The response is then processed by the business application and some automated action taken.

Premium rate SMS is also 2-way in nature but allows for rates other than standard SMS rates to be levied. A multitude of billing options exist, including rate bands (where a set fee is charged for a number) and variable billing (where billing is based on the requested service or content). In a non-subscription type service, when a user sends an SMS to a premium rated number, funds are deducted from their cellphone account. In a subscription type service, funds are deducted periodically or on some stated basis. The network operator takes a share of the revenue and the remainder is passed on to the application owner or service provider.

What are custom SMS solutions good for?

• Reasonably simple interactions: exchange of information (predominantly text).
• Capturing larger (relatively) quantities of textual data.
• Simple “conversational” interactions – where the state of the interaction must be maintained or where the context is important.
• Revenue collection (via premium rated SMS).
• Textual information dissemination.
• Communicating with a large number of users, quickly and reliably.

What are custom SMS solutions not good for?

• Capturing structured, formatted information or data which must be validated in some way.
• Multiple, extended or continuous interactions (due to cost).
• Rich media (video, images, music, etc).
• Client-side processing (i.e. performing some custom action on the recipient’s device).

What is the extent of device support?

• Almost every mobile device worth considering (mobile phone, GSM-enabled PDA, pager, etc) supports SMS.
• It is by far the most widely supported mobile technology after voice.

Example application

Qpid is a premium rated SMS service, developed by Clyral which allows users to send anonymous secret admirer messages to one another in a safe way. The system tracks who “fancies” who and interacts contextually with each user (conversational). All interactions are text based.

This post forms part of a series on a comparison of mobile technologies.

Continue to Part 2 – WAP or mobile web.

This post forms part of a series on mobile technologies.

SMS (2-way and premium rate), MMS, WAP, mobile application, USSD, WIG or a combination of technologies are some popular methods for mobile service delivery. With all those TLAs (Three Letter Acronyms) flying around, venturing into the mobile space can be a little overwhelming, even for a business with a strong ICT background. I hope these discussions will provide some insight into the pros and cons of a few of the mobile technologies available as well as a simple example application of each. Please bear in mind that this is not intended to be a definitive guide (or even close) and has been intentionally simplified but may answer a few preliminary questions and illustrate the potential that mobility provides.

Continue to Part 1 – Custom SMS solutions.

Continue to Part 2 – WAP or mobile web.