After a year of development the Mercumer SMS Reminder Service has launched. The reminder system is initially targeted at small almost micro businesses and seeks to give those businesses the benefit of being able to send SMS, e-mail and voice reminders easily and cost effectively, something that only larger businesses have been able to do. The project featured the use of user centred design principles, an AJAX GUI providing a true application in a browser experience, a best of the breed approach to language selection, multilingual web-site and application and parsing phone numbers from around the world.
As the core developer of the product, I would like to put back some information about the process and implementation that could help my former academic colleagues.
In 2009, I sent my business partner out to speak with people who were like our potential clients. Most importantly, I asked him to observe how they worked. At the superficial level we found that our target group typically used a paper diary with a week to 2 pages and had quite variable knowledge of computers. At a deeper level we found some opposition to any change in their way of work.
From our interviews and observations we concluded:
We also endorsed the following general principles:
An example of not surprising the user was our choice not to allow a user to login twice. If we had allowed this then one of the logins could have changed appointments without the other user noticing; or a user could find an old window with out of date information. In the multiple update model we need a mechanism to maintain consistency.
An example of applying the user wants what the user wants principle is accepting phone numbers in an almost arbitrary format and storing them in the format entered - we test the number on entry and warn the client if we think there is a problem with the number, but accept it as written. It involves a lot more work on our behalf to convert the numbers and verify them each time they are used, but it allows the user to format the numbers the way they want to. It also allows the user to put in a guess and fix it later.
Another example of applying the user wants what the user wants principle is allowing users to book any time they want; appointments don't have to be aligned with slots in the diary. Our clients know when they want their appointments and forcing them to stick to their plan will just result in their finding ways to force it into the system; better to let them use the appointment slots as a means for filling in the time and date quickly and highlighting that there are multiple appointments in the slot.
This project involved creating a GUI like experience within the browser using AJAX. We experimented with less complete mechanisms but just could not get a complete enough - just like a GUI - feel. After looking at toolkits we eventually settled on the vegUI framework. Although we did not get the code checking facilities of the Google toolkit we ended up with something that was codable and customisable enough to be pleasing to the eye.
Like many of my development projects Mercumer incorporates several programming languages: Perl, PHP, and Javascript. We also used C to create some specialised programming tools.
AJAX naturally incurred the use of a fair bit of Javascript. We used PHP to provide the web interface for the Javascript and any customer facing pages. Message sending was written in Perl.
In general I favour using the language that is best suited to solving the problem, rather than expressing the problem poorly in one language. Naturally, we don't carry this approach to extremes as the code must be maintainable by future programmers. I have found that multiple languages in separate parts of a single project can significantly speed development and ease maintenance.
The multi language approach introduced a few issues in that not everything could be shared via SQL and the database. Sometimes you need to share code and data structures. One facility that required serious speed was the parsing of telephone number prefixes. We settled on a Trie data structure to provide the required speed. We are releasing the code for triemaker. We ended up crafting our own tools in C to read a Lex like grammar which we could target into C, Perl and PHP languages. The result being that we had our high performance data structure with the same data in three languages with minimal effort - once the tools were written.
So why did we write our own tools for the Trie data structure? There used to be tools for generating tries in one of the GNU C++ compilers as an example, but they seem to have disappeared from current distributions. Unfortunately, we found recompiling the old code and updating it harder and more likely to be painful to maintain into the future than reimplementing a custom tool ourselves.
Mercumer makes extensive use of GNU gettext to provide a multilingual capacity. The build process parses the source files and generates the files for translation automatically.
Mercumer examines the prefixes of phone numbers to classify them into groups. We used this classification mechanism both to divide SMS numbers into cost bands and to verify phone numbers. The verification process classed a phone number into fixed, mobile, forbidden and invalid groups - forbidden includes premium services. The collection of the data was a daunting task as the ITU doesn't gather it all in one place, often it linked off to the individual country or regional regulators. And although the ITU has standards for writing documents describing numbering plans, their application appears to allow for a fair bit of flexibility in interpretation. So in addition to using official data it was necessary to look at phone numbers of services in the countries and how the locals wrote their numbers.