This is continued from Part 1, posted previously.

I mentioned earlier that the services layer is where we’ve seen the most work happen in mobile ministry. Part of that is because of the maturity of that layer, the accessibility of that layer due to (simply) the existence of the Internet, and the (usually) generous offering of compatible APIs between services and some families of devices. This allows the ministry/organization/individual developer to focus on making sure things plug together neatly, and they can put more energy towards the experience that is to be gained from using their application.

But what if you want to focus on the device layer? What are you in for? Let’s just look at a few device platforms that you could support:

• iOS (Apple)
• RIM (BlackBerry 5, 6, and 7)
• Android (1.6, 2.1, 2.2, 3 (Honeycomb), and now Ice Cream Sandwich which has no version number and spans several device form factors both mobile and not)
• Windows (WM 6, 6.5, Phone 7, and Phone 7.5)
• Nokia (S40, S60 Feature Pack 2, Symbian^1, Symbian 3, Qt 4.5)
• Brew (incompatibilities across carriers)
• HP (WebOS 2, 2.1)
• Samsung (Bada, Bada 2)
• And several mobile devices which use proprietary OSes that cannot be developed for directly, but are sometimes enabled on the carrier-level for some services (see the graphic in this Vision Mobile article for details)

And that’s just what I could name off the top of my head.

You can’t focus on the “mobile = devices” meme. You can’t even let that maintain more than 1/3 of your thoughts on mobile. When you do, what happens is that you start to make smaller the addressable persons who would be able to successfully utilize produced content, or even enable them to produce content for themselves.

Let’s say that you want to focus on the services layer. What are you in for here? A small list again:

• WAP
• HTML (4 and 5; devices support different and mismatching pieces of these)
• SMS (MMS, shortcodes, carrier-specific rules, analytics that matter, etc.)
• APIs to default applications (requires platform-specific SDK)
• APIs to web services such as Facebook, Twitter, etc. (read the terms of service for what you are able to access and what compromises you or consumers might have with these).
• Content Management Systems

Again, just a few pieces. But you can’t just say “go SMS” and not also be cognizant of the fact that SMS broadcasting rules are different in various countries/carriers. You also need to be able to scope carefully what your entire workflow will be for that communication from the creation of the message, to what happens with the data about that consumer, to expectations for them and your organization.

I’d go into experiences, but you might be getting it now – you can’t just think about mobile as some isolated channel. It isn’t isolated, and the entire mobile definition is predicated on the synergy of devices, services, and experiences.

The potential of mobile is that there are 5.3 billion accessible persons who can be touched in some way by a carrier of the Gospel. The realistic assessment is a lot smaller, and requires more than just a passion for the theological command. Our passions also have to account for the ability to get to the message in an accessible manner. That’s more than a device. And ultimately, it requires us getting on a deeper level than the channel itself.