Ashley Kleynhans

Osmotic Communication

Introduction

I recently came across a book called Crystal Clear, A Human-Powered Methodology for Small Teams by Alistair Cockburn where I learnt about Osmotic Communication.

The basic principle of Osomotic Communication is that team members subconsciously absorb information that is being discussed by the team members around them.

This can only really be accomplished when team members are all located within the same room.

If someone in the team asks a question, the other team members can either tune in and contribute towards the discussion, or tune out and continue with their work.

Osmotic Communication is most beneficial to small teams, but a small team can range from all the employees of a small start-up to a small team within a large organisation which employs thousands of people.

Personal Experience

I have been fortunate enough to work for many different types of companies, ranging from large corporates with hundreds of thousands of employees to start-ups with less than 10 employees.

Some of the companies had flexible working conditions where I could work remotely, and others did not.

Although more and more companies seem to be allowing telecommuting, I find that working remotely can have a huge disadvantage for the team members who are telecommuting as well as the rest of the team, compared with being in the office and being able to benefit from Osmotic Communication.

For example, I recently joined a new company and they were kind enough to let me work from home while I’m in the process of selling my home and purchasing a new one. They flew me up to come and work in their office for a couple of weeks, and while I was in the office I learnt a great deal about the product, processes, and many other things just by overhearing the conversations of my team members.

One of my team members needed to implement device detection so that he could determine whether to forward people to the regular website or to the mobile version. I had previously used DeviceaAtlas and was able to suggest it, as a result of overhearing the conversation.

I then flew back home and continued working remotely while having our daily standup and other catch up sessions online, but even though we communicated online frequently, I was not able to keep as up-to-date with what was happening with our product as the team members who were in the office every day.

There were also instances of miscommunication where someone thought that one of our systems had broken because I was returning to the office for a couple of days.

Prior to joining this company, I had worked at start-up which allowed me to work from home most of the week, and only required that I had to come into the office once per week. Prior to the telecommuting arrangement, I went into the office every day. I found that telecommuting was extremely convenient, but had distinct disadvantages in that I didn’t know what my colleagues were working on, what cool new technologies they had discovered, and even missed out on the office jokes and humour.

Conclusion

Having had the opportunity to telecommute and also to work in small teams, I find that Osmotic Communication far outweighs the benefits of telecommuting, so I strongly recommend that all members of small teams should be seated within the same room so that they can benefit from the advantages that Osmotic Communication has to offer.

Building Your First Mxit Application

Introduction

I have had quite a large number of people asking me advice about building Mxit applications, so decided to share some of that information here.

This information relates to building Mobi Portal applications, and probably won’t be useful if you’re using the .NET SDK.

Before you start building your application, you should refer to all the various different Mxit terms to ensure that you won’t be in violation of those terms. You should also start off by reading the Mobi Portal API Specification.

Mxit Mobi Portal applications use a very small subset of HTML, so you won’t currently be able to access GPS, Compass, Accelerometers, etc.

An Idea

Obviously the very first thing that you will need to do when building a Mxit Application for the first time, is to come up with an idea.

Although Mxit is an Open Platform, and you can clone existing applications, I have much more respect for people who come up with an original idea instead of cloning applications that already exist.

It will also be difficult for you to try to compete with an existing application that has already been around for several months and has an established user base.

If you are struggling to come up with an idea, you should consider browsing the Programmable Web API Directory which lists almost 9,000 APIs at the time that I am writing this article, for some inspiration.

Hosting

You can use whichever hosting provider you like.

South African hosting solutions tend to have lower latency since Mxit is also hosted within South Africa, but unfortunately decent South African hosting can be very expensive, and the cheaper hosting providers aren’t really an option. I know of people who have tried to host their Mxit Applications at Afrihost and Cybersmart and ended up having to move them over to international hosting due to their local hosting providers not being able to cope.

I am a big fan of Amazon AWS, but their hosting can become very costly very quickly. Although I don’t use Amazon EC2 for my server hosting, their S3 service isn’t very expensive, so I highly recommend using it to store things like images.

My preferred hosting provider is Hetzner in Germany. I have a few Dedicated Servers hosted with Hetzner Germany. I don’t recommend local Hetzner hosting in South Africa because they have too many outages and their service is also not as good as Hetzner in Germany.

Database

You don’t need a database to have a Mxit Application, but I think your application will generally be pretty pointless without some sort of database. In the very least I recommend storing the userid of each user that interacts with your application, so that you can engage with them using the Mxit Messaging API.

I’ve found that running a single MySQL database server can cause high CPU load during peak times, so I generally prefer using MongoDB to store my data. MongoDB is schemaless, so adding new fields doesn’t involve updating millions of records. If you find querying MongoDB difficult, Stripe recently launched MoSQL which live replicates MongoDB to PostgreSQL, so that you an benefit from NoSQL in the form of MongoDB, but also be able to query your data using SQL.

Tracking and Analytics

I recommend implementing Google Analytics tracking in your applications. Nic Malan has written a PHP Wrapper for Google Analytics which I use in most of my applications. Nic’s wrapper requires the curl executable to be installed on your server.

In addition to Google Analytics, I also record custom analytics in Redis and have a CMS that displays those analytics.

These analytics are useful for finding trends in your applications and have also helped me in noticing that things were not functioning correctly, so that I could either fix those things myself, or raise them with Mxit where applicable.

Ensure that you keep track of the userid of each of your users if you plan on Improving User Engagement with the Messsaging API.

Caching

You should ensure that your application is scalable by implementing caching for resources that will be frequently required. Various different options are available such as Memcache, Redis, Couchbase, etc.

I typically develop my Mxit applications in PHP, so I use APC (Alternative PHP Cache) as an op-cache, and generally use either Redis or Couchbase for caching data. The main reason why I choose Redis or Couchbase rather than Memcache is because both Redis and Couchbase persist to disk, but Memcache does not, so if you have to reboot or restart your Memcache server for whatever reason, there will be a large amount of load while data starts to get cached. I have had some bad experiences where I was caching user agent strings in Memcache and had to restart the Memcache server, which brought the entire application to its knees.

Using External APIs

If you’re going to call external APIs in your applications, I strongly recommend caching the data that you retrieve.

Many external API services have implemented rate limiting, and if your application becomes successful, there is a very good chance that you will exceed those rate limits, which could potentially cause your application to generate errors and become inaccessible.

I experienced outages in one of my applications less than 3 months after launching it, due to rate limiting imposed by the third party API that I was using.

Pagination

When I built my first application, I was much less experienced than I am now, and made the mistake of neglecting to use pagination. If ever pagination was important, it is within the Mxit environment.

Most Mxit users have older phones which don’t have much memory, so spewing out massive amounts of data on a single page will most likely cause the Mxit client to crash on those phones.

The number of items per page depends on how much data is contained within each of those items, but generally somewhere between 5 to 10 items per page is my recommendation.

Images

Remember that many Mxit users are using devices with extremely limited memory, so you should try to keep the number of images that are displayed on a single page to an absolute minimum to avoid the Mxit client from crashing.

You should also bear in mind that different users have different devices which have different screen widths, so you should resize your images to at least 2 or 3 common widths to ensure that the images are correctly displayed across all devices.

In my first Mxit application I made the mistake of using an image as a separator between each item on the page, but obviously this caused the devices with limited memory to crash, so I received plenty of complaints from my users, and changed the image to a text separator instead.

Recommendations

Mxit provide a feature where your users can invite their friends to your application. In order to use this functionality, you will need the Referral ID for your application. Unfortunately the referral ID is not yet available from the dashboard, so you will have to manually request it from the Mxit Developer Centre.

Once you have your referral ID, you can allow users to invite their friends to your application by adding a link as follows:

1
<a href="mxit://[communityportal]/RecommendPage?ItemId=00000000" type="mxit/service-navigation">Invite Friends</a>

Or, alternatively, you can link to other Mxit applications as follows:

1
<a href="mxit://[communityportal:Refresh]/ReferralPage?ItemId=00000000" type="mxit/service-navigation">Another Awesome Application</a>

In both cases, the ItemId is the Referral ID that Mxit will provide you with.

Improving Mxit Engagement With the Messaging API

Introduction

This is a follow-on from my previous post Mxit Monetisation, and focuses on improving user engagement in your Mxit applications by using the Mxit Messaging API.

This article is focused on Mobi Portals, and will not be useful if you are using the .NET SDK.

Keep a record of your users

One of the biggest mistakes that people make when building a Mxit application for the first time is not keeping a record of their users.

You will need to keep a record of the userid of each of your users in order to send in-app broadcast messages to your users with the Messaging API. Ensure that you read the Mxit API Terms before you start working with user data, to ensure that you are not in violation of the terms.

The userid is available from HTTP_X_MXIT_USERID_R variable in the server headers, for example in PHP:

$_SERVER['HTTP_X_MXIT_USERID_R']

You can use whichever database you prefer to store the userid of your users. I generally prefer using MongoDB.

Formatting your message

The Mxit Messaging API supports Mxit Markup. If you make use of Mxit Markup, you must set the ContainsMarkup field to true in the API call.

If you are using the Messaging API for in-app broadcasts, I strongly recommend using Mxit Markup to add a link to the end of your message, for example:

$Click here for menu$

Without the link, most of your users will have trouble getting back to your application unless they are aware of the shortcut commands (.hm/.home/.bk/.back/etc).

You can use newline characters within your message, but depending on the language you are developing your application in, you might need to escape the new line characters.

You can also use emoticons within your message, but will need to escape any Mxit Markup contained within those emoticons.

For example, in PHP (new lines don’t need to be escaped):

Example Message
1
2
3
4
5
$message = "(\*) Congratulations to our winners (\*)\n\n";
$message .= "1st place - Michael with 100 points\n";
$message .= "2nd place - Sipho with 50 points\n";
$message .= "3nd place - Carla with 25 points\n\n";
$message .= 'Good Luck! :) $Click here$';

Notice that the asterisks in the first line of the message are escaped. The reason for this is because the asterisk is used in Mxit Markup, and is translated to Mxit Markup unless it is escaped.

Broadcasting to your users

Once you have recorded the userid of your users, you will be able to send your message to your users.

Although you have stored the the userid of your users, some users might remove your application, but currently Mxit don’t provide a tool for developers to determine which users have removed their application. Your message will only be delivered to the users who still have your application as a contact. The users who have removed your application will not receive the message.

You will need to split your broadcast into batches because the Mxit Messaging API only supports sending to a maximum of 500 users at a time. I generally split my broadcasts into batches of 50 users and thus broadcast to 50 users at a time.

The Client Id and Client Secret from your Mobi Portal Dashboard are required for sending messages using the Mxit Messaging API.

I have written a PHP Wrapper for the Mxit Messaging and User APIs, which is used in the following example

(announcement.php) download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
<?php
/* Require the PHP wrapper for the Mxit API */
require_once ('MxitAPI.php');

/* Function to count the number of users in MongoDB */
function count_users() {
    $mongo = new Mongo('127.0.0.1');
    $collection = $mongo->sampleapp->users;
    $collection->ensureIndex(array('uid' => 1));

    return $collection->count();
}

/* Function to get batches of users from MongoDB */
function get_users($skip=0, $limit=50) {
    $mongo = new Mongo('127.0.0.1');
    $collection = $mongo->sampleapp->users;

    $collection->ensureIndex(array('mxitid'     => 1,
                                   'created_at' => 1));

    $users = $collection->find()->sort(array('created_at' => 1))->skip($skip)->limit($limit);

    return iterator_to_array($users);
}

/* Instantiate the Mxit API */
$api = new MxitAPI($key, $secret);

/* Set up the message */
$message = "(\*) Congratulations to our winners (\*)\n\n";
$message .= "1st place - Michael with 100 points\n";
$message .= "2nd place - Sipho with 50 points\n";
$message .= "3nd place - Carla with 25 points\n\n";
$message .= 'Good Luck! :) $Click here$';

/* Mxit Markup is included in the message, so set ContainsMarkup to true */
$contains_markup = 'true';

/* Count the number of users in the database */
$count = count_users();

/* Initialise the variable that counts how many messages have been sent */
$sent = 0;

/* Keep looping through the user list, until the number of messages sent equals the number of users */
while ($sent < $count) {
    /* Get users in batches of 50 */
    $users = get_users($sent, 50);

    /* The list where the user MxitIDs will be stored */
    $list = array();

    foreach ($users as $user) {
        $list[] = $user['mxitid'];
        $sent++;
    }

    /* If there is a problem getting an access token, retry */
    $access_token = NULL;
    while (is_null($access_token)) {
        /* We are sending a message so request access to the message/send scope */
        $api->get_app_token('message/send');
        $token = $api->get_token();
        $access_token = $token['access_token'];

        // Only attempt to send a message if we have a valid auth token
        if (!is_null($access_token)) {
            $users = implode(',', $list);
            echo "\n$sent: $users\n";

            $api->send_message($app, $users, $message, $contains_markup);
        }
    }
}

echo "\n\nBroadcast to $sent users\n\n";

Its a good idea to follow the Mxit “Rules of the Road” for Messaging which state:

Our API gives you the ability to push messages to your application’s users. Don't use this to spam your users – they will probably remove your application, or stop paying attention to your messages.

Mxit Monetisation

Introduction

I was asked to prepare a talk for a Mobile Entrepreneurship class in Kenya, and decided to share the talk in my blog.

You can listen to an audio recording of the original talk at the end of this post (provided that you have a browser that supports HTML5).

I’ve built stand alone web applications before, but you have to spend lots of time and resources to try and make a web application discoverable, and growing your user base organically can take a long time, unless you’re prepared to spend lots of money on advertising.

Last year I started building applications for the Mxit platform. For those of you who don’t already know, Mxit is the largest social network in Africa.

The biggest advantage of building apps on the Mxit platform, is that you can leverage their existing user base of more than 10 million active users, and grow your application organically pretty quickly.

Another advantage is that Mxit only uses a very small subset of HTML, and you don’t have to worry about things like CSS or cross browser compatibility, so you can turn apps around very quickly.

At first I started building applications in my spare time, while working a full time day job, but eventually my applications started generating enough revenue that they were able to fully sustain my living expenses, and I quit my day job and am now developing mobile applications full time.

To date I have developed 5 applications for the Mxit platform, of which 4 were successful and 1 was a failure.

These applications are:

  • People Pets - A photo based role playing game where people can adopt each other as pets.
  • Hangman - A hangman game, where people compete to reach the top of the leaderboard and win prizes.
  • Movie Review - An application where users can review movies and read movie reviews.
  • KookyKardz - A facial recognition application where users can turn their photos into greeting cards. I worked on this as a collaboration with the guys from Appceptional
  • World Flags - An educational game, where users guess the country of the flag that is shown and compete against each other to reach the top of one of the leaderboards.

One of the biggest mistakes I made with my first application was to include too many features. Since then I have used the MVP (Minimal Viable Product) approach, and iterate quickly.

Some of the best ideas for enhancements have come from feedback provided by my users, so I strongly advise adding a feedback feature to your applications.

More about Mxit

When building Mxit apps, you can either choose to use the .NET SDK or to build a Mobi Portal. I don’t have any experience with .NET so I chose to go the Mobi Portal route, because you can use any programming language of your choice.

The Open Source community has released lots of code examples in PHP and Ruby. There is also a Wordpress plugin called MxPress which can transform Wordpress sites into Mxit applications.

Last year Mxit launched some APIs which allow developers to be able to access a wide range of features within the Mxit environment.

You can host your applications with any hosting provider of your choice, but I recommend getting a solution that will be able to cope if all 10 million Mxit users start using it. Generally small VPS instances aren’t able to cope with this amount of load.

I initially started using Amazon AWS, but unfortunately AWS can be very expensive, so I decided to get some dedicated servers from Hetzner in Germany instead. You get excellent value for money with Hetzner. For example my latest server has an Intel Quad-Core i7-2600 processor, 32Gb of DDR3 RAM, and 2 x 3TB SATA 6Gb/second hard disks, with unlimited traffic for only 59 Euros per month.

I find that games are generally more successful than regular applications, unless you build an application that is able to empower the feature phone and provide smart phone type functionality on a feature phone. One such application is MxPix, which basically brings Instagram type functionality to feature phones.

The users on the Mxit platform are extremely competitive, so I found that adding a leaderboard to my applications helps improve engagement, since everyone wants to be number 1 on the leaderboard.

Another method of improving user engagement is to award prizes. I started off awarding small prizes, but as my apps started generating more revenue, I increased the number and frequency of prizes.

With the new Messaging API, you can also improve user engagement by sending regular messages to your user base. The messaging API only allows you to send messages to users who have added your application as a contact. You can’t send messages to people who have not used your application, or have removed your application.

One of the biggest lessons I have learnt along the way is to try to avoid displaying user generated content to other users, otherwise you have to spend many valuable hours moderating content.

Monetisation

Mxit has a virtual currency called Moola. They have a Billing API that enables developers to charge users Moola within their applications.

The biggest problem with using Moola is that premium SMS is used to bill Moola against the airtime of a user. Premium rate SMS has a huge disadvantage in that the operators take up to 50% of the revenue that is generated. Mxit then take a 30% revenue share on the remaining 50%, leaving the developer with just 70% of the remaining 50%, which means that you only earn about 35c for every R1 earned in your application.

I began by charging Moola for almost every action within my People Pets application, but most of my users sent me feedback saying they couldn’t afford to buy Moola and asked me to make things free. I wasn’t generating much revenue at the time. The Moola revenue generated wasn’t even sufficient to cover my hosting fees, so I decided that I needed to try and find an alternative revenue stream.

This is when I decided to implement advertising in my apps as a source of revenue. I discovered that Mxit users tend to click on ads more often than ads served in a regular web application. I then made almost every action in my People Pets application free, with the odd exception, and my user engagement went up by about 300% and I started generating a pretty reasonable stream of income.

I found that the following advertising platforms work pretty well within Mxit:

Shinka are the preferred advertising platform for Mxit, and will soon be the sole advertising platform on Mxit. I strongly recommend using Shinka if you’re building a new application, but will share my experiences with the others as well.

If you use Inmobi or Buzzcity, you earn 100% of the Publisher revenue and don’t need to split the revenue with Mxit, because they have no way of knowing how much revenue you are actually earning, but the quality of the ads on Buzzcity is somewhat questionable and Inmobi’s ad campaigns run dry before mid day, so I strongly recommend using Shinka instead. Shinka and Mxit are both part of the World of Avatar, so Shinka have enforced a revenue split with Mxit, where the developer earns 70% of the Publisher revenue and Mxit earns the remaining 30%. Unfortunately the dashboard which is made available to Publishers can be extremely confusing because it shows the full 100% Publisher revenue, instead of only showing the 70% that you’re actually earning. Although you only earn 70% of the Publisher revenue with Shinka, I still earn more money using Shinka than any of the other advertising platforms, so would recommend using Shinka rather than any of the others.

Inmobi and Buzzcity are both international, and revenue is paid in US dollars. Shinka is South African and pays in South African Rand.

Inmobi used to generate the most revenue when they still had offices in Africa, but since they pulled out of Africa, I don’t generate much revenue with them and their service also isn’t as good as it used to be, so I would recommend that you avoid using Inmobi.

I then switched to Buzzcity, but had to disable the “Dating and Glamour” category, otherwise I would receive porn ads in my applications, and Mxit terms and conditions prohibit porn. Unfortunately Buzzcity also have lots of WhatsApp ads, and obviously Mxit don’t like this, since they consider WhatsApp as a competitor, so they have been issuing developers with warnings to remove WhatsApp ads from their applications within 24 hours or risk having their applications unpublished. Buzzcity only make payments once your Publisher revenue reaches at least 200 US dollars.

When I first started using Shinka, I had some problems with my clicks being discarded, but was fortunate enough to meet with their CEO, who provided me with some PHP code which was slightly different than the code that I had been using previously. One of the main things I was unaware of, was that either the banner images had to be resized for different device screen widths or 3 different ad unit sizes had to be set up to support various different device widths, so it was actually a mistake that I had made, and not the fault of Shinka.

I am having much greater success since implementing the new code, and Shinka is now my advertising platform of choice, not only because they generate higher revenue than any other advertising network, but also because Mxit plan on making them the sole advertising network for the Mxit platform later this year, so I strongly recommend using Shinka when building new Mxit applications.

Receiving Your Revenue

I use Paypal to receive my payments from Inmobi and Buzzcity, which make payments in US dollars.

Paypal don’t charge any commission on payments received from Inmobi, but do charge about a 4% commission on payments received from Buzzcity. Recently First National Bank in South Africa started offering Paypal services where Paypal funds can be withdrawn directly into your bank account. FNB charge a 1.5% commission for this service and it generally takes about a week for FNB to process the transaction before the funds appear in your bank account.

Instead of using FNB, an alternative is to apply for a prepaid debit card from Payoneer.com. Once you receive your prepaid card, you can request the US Payment Service from Payoneer, which is basically a virtual bank account. You can then withdraw your Paypal funds into your Payoneer virtual bank account, and they top your prepaid mastercard up with those funds. Payoneer only charge a 1% commission for this (as opposed to the 1.5% commission charged by FNB). The processing time for the Paypal withdraw also only takes a few days as opposed to an entire week with FNB.

Shinka’s accounts department email a monthly report which has a breakdown of the revenue generated by each app and shows how much revenue Mxit has earned and how much you have earned. You then need to invoice them and they deposit the earnings directly into your bank account within 45 days. The biggest advantage of using Shinka instead of the other advertising networks is that you don’t have to pay any commission to banks if you have a South African bank account.

I asked Shinka if they are able to make payments to developers based in Kenya and they told me that they are able to make payments to countries outside of South Africa by using Paypal.

Conclusion

The best time to start building Mxit apps is right now, while there are only a few apps, and plenty of opportunities for new ideas that haven’t been implemented yet. You can also make a pretty good income from your applications if you do a good job of executing your idea and engaging with the Mxit users.

Just because I have been unsuccessful with Moola, doesn’t mean that Moola is not going to work for you. The TuneIt Mxit application tried the advertising model, and had greater success with Moola, so you should probably use trial and error and figure out which revenue model works best for you.

If you’re interested in finding out more about building applications for the Mxit platform, check out http://dev.mxit.com.