Mobile Development is not Front-end Development

According to Stackoverflow, almost 80% of developers there claim to be “web developers”. That sheds a lot of light on why mobile development has become this presentation focused, HTML5, CSS3, screen-size/orientation field, rather than understanding and utilizing “mobility”. I suspect engineers from device companies such as Motorola, Samsung and Apple are quite frustrated that they make this marvelous powerhouse and it’s potential is so untapped due to the hijacking of this space by so called “hybrid development”. You know there are seven layers in the ISO-OSI stack and a mobile phone is quite awesome in all of them. So why all this focus on just the top border of the application layer?

Use the mobile phone as a second, separate and equal device to make your use cases more graceful.

Let me ask the leads here of companies that have field operations. Can you tell me what your ongoing installs are – right now? I’m not asking about installs that are scheduled for today or sales orders that have today’s date as the installation date. We all know how that goes. What are your ongoing installs?  – or, your feet-on-the-street direct and indirect sales people, where are they now? who are they talking to?

Use mobile technology to feed real time awareness to your backend systems so they can respond with agility and context.

If a sales person is with a potential customer and has to stop and make a customer-service call either because he or she does not have the answer or something is not working, you can kiss that sale goodbye. An installer calling in as something is not right with the work-order makes the customer feel they made a mistake by choosing your company. In these scenarios, the saving grace is if that call goes well, really well, like the system knew why he or she was calling and had the correct people with the correct facts lined up. Then the person onsite can talk-up the kind of service the customer will get if they have any issues. Or else, you know they are going to talk about the “fools in the back-office”.

When you think mobile, if you are thinking about location services, that’s a start – but that’s just a start. [At least you are not asking your users to enter addresses in text fields. You are way ahead of some you would expect know better. Mobile apps asking for home addresses or address of the current location (of a customer site for instance) is due to poor hybrid development practices where some web-component is reused without thought (or care). Typed in addresses cause so much pain in backend systems and operations.]

So, going beyond location.

Fire-up the sensors:

When we created the ‘my-avatar‘ Alexa skill and implemented the “Where’s my phone” command, it was essentially natural language processing with the Alexa Skills Kit, then secure messaging from AWS to our backend and then routing to the mobile through GCM (and/or APN). All that was neat. However, what was really cool is when we made the phone say, “You found me!” in a happy voice when the user picked it up. That’s done by firing up some sensors. A mobile phone is rich in sensors: an accelerometer, a gyroscope, an ambient noise sensor, a light sensor – why? So that it can do it’s basic functions and be a good mobile phone. However, those are available to all developers. Use them. Don’t let your framework or development practice hide them.

Fire-up the networks:

How many networks does your mobile phone have? At least three, but most have many more: a legacy voice network, a modern data network and a local network (3G/4G (LTE), Wi-Fi), not to mention Wi-Fi Direct, Bluetooth/BLE and NFC. How many are you using in your use cases? The data network? How are you using Wi-Fi? merely as a transport to the internet? You know it is a network. What use cases can you solve with that? How about discovering your product’s MAC addresses perhaps and registering them with your backend? Do you node lock licenses? Do you want to secure install-time license file downloads only when your person is on customer-site? The ability within an app to switch between networks is something you can’t do with a laptop. Often you can’t even get on the internet as your customer’s Wi-Fi is protected and it is unprofessional to ask for Wi-Fi passwords. Let’s face it, we don’t equip our field professionals with LTE dongles and pay the monthly device access fee to our friendly operators. Heck, we want BYOD – don’t we! So use the app.

Fire-up social:

We all want our employees to be ambassadors and actively promote our products on their social media. But, are you making it easy for them? First, allow them to log into your enterprise app with their social media logins – not just your corporate logins. Then, what did they do that day? Did they install a cool home automation system for a customer? Did they make some sales? Did they answer some questions? Did they process some orders? Did they fix something? Did they write some code for a new feature? Whatever they did, they did it with some product or service you want to market and highlight. Prepare the social media content with their actions and link relevant pieces back to your main presence – wherever that is, and keep it relevant for the follower too. Then, after dinner, with one-click on a follow-through notification on their mobile phone, your ambassador-employee can share their <marked-up> accomplishments of the day.

If all you are doing is presenting an alternate view of your website – thanks to responsive design! – or even worse, thinly wrapping your website in an app – due to reuse/hybrid development practices – you should think again. Free your mobile team from front-end thought and urge them to think at a system level.