Mobile app on boarding, how to lower the barrier?

The on boarding flow in your app begins when your potential user launches your app for the first time and has to be convinced about the app’s benefits and eventually why he or she should sign up for it. This is the process in which you want to convert your potential user (visitor) into a engaged and active user that repeatingly will use your app.

It will be even better if you can convert your visitor into a user that is referring to your app (ambassador) or a paying user (customer)! To accomplish this the first impression of your app should be impressive from a visual perspective and it should explain what is in it for them.

The on boarding flow of well known apps

Here is how IFTTT does the on boarding in their app. It shows multiple slides explaining you why you should want to use it and what the app is all about. Before you decide to sign up you have a clear impression of what to expect.

If you want to see how other well known apps take care of the on boarding process you can check out the User on board site or the UX Archive.

Many apps, even well known ones, require you to sign up on the first page with little to no explanation what the app is about. That may work well for the Facebook app that almost everybody is familiar with but it is not going to work for your app.

Onboarding patterns

To lower the boarding barrier there are multiple well known patterns that you can chose or combine. Some of these patterns are listed here:

The Introduction approach shows a couple of slides and often require the user to sign up but some apps choose to show the content of the app right away. A Tutorial or a Tour approach show the real app, pointing out some example cases.

A Joy ride approach allows to use the app right away highlighting from time to time features that are new to the user. It is great way of showing what the app is all about but if your app is complex it also may be a little bit overwhelming if you do not this carefully.

A Social sign up allows the user to perform a quick sign up using his Twitter or Facebook account for example. This may be required for the user in order to be able to continue the app but it will lower the barrier if you first show what the app is about and only ask to sign up when needed to proceed.

Late sign up is a concept that is often seen in e-Commerce (and some times in m-Commerce) solutions. Only if you want to check out you have to sign up.

Anothering interesting concept is Continuous on boarding (LinkedIn for example is doing this). We want the barrier to be as low as possible but we also want user profiles to be as large as possible. The concept can be very powerful because it comes with benefits from both worlds. It lowers the barrier (by asking only for the minimum amount of credentials) and it eventually will result in rich user profiles, by encouraging the user to complete his or her profile later.

A known user is more valuable than an unknown one

Probably the best on boarding flow does not require any sign up or login, so you should ask yourself do really want your users to sign up? On the other hand it also true that a known user is more valuable than an anonymous one. In fact we are talking about users versus visitors here. And users eventually become customers while visitors probably never will.

A social sign up has multiple benefits. Not just for the user but also for us, developers. Avoid a lengthy registration process with many fields. The chance that the user will sign up increases and, with the appropriate permissions, you have instantly access to various information of that user, for example an avatar and a name of the user, which is great for personalization options.

Offering a social login could lead to 50% more sign ups. After all, a sign up is only one or two clicks away!

Use Fabric to allow the user of your app to sign up with Twitter or a phone number

There are services that will take away most of the hassle that comes with the implementation of these kind of features, such as the Fabric SDK, which is free to use. The SDK has features for signing up with Twitter but also for a sign up using your phone number, just like WhatsApp is doing.

Conclusion

It is important to keep the on boarding barrier as low as possible and also to make clear from the beginning what is in the app that your user can benefit from.

You can experiment with the different types of on boarding and see what works for your app by obtaining metrics about the conversion and learn from them. And once they are on board (activation) you can focus on optimizing the rest of the flow. Will they keep using the app? (retention) What about referrals and revenue?

As you can see, although intended for SaaS in particular, Dave McClure's start up or pirate metrics can be applied to mobile apps as well. AARRR!

Get the book!

My new book that I am currently working on, together with Arvi Krishnaswamy, is -amongst other things- about the lean startup methodology applied to mobile app development. In this book you can read more about topics such as on boarding, obtaining (actionable) metrics and split testing.

It also comes with some real world examples for both Android and iOS developers. Expect the book to arrive by the end of this year!

Further reading

• 1. User onboard, onboarding flows of well known apps described
• 2. UX Archive, onboarding flows
• 3. Fabric, sign up with Twitter
• 4. Digits, sign up with your phone number
• 5. AARRR! or: Pirate metrics

The bots are back in town. Meet Botterik on Slack

Chat bots are around us since the introduction of ELIZA somewhere in the sixties. And that probably was cool and then we forgot about bots. But now they are back and they have become smarter since are connected to the internet and because we now have improved AI algorithms and with that API's for semantic parsing.

Companies such as Apple, Microsoft, Google, Facebook and Slack have rediscovered the chat bots and now they are just everywhere.

Agents (or bots) as Siri, Cortana and Google Now are supposed to have an answer for anything but a new trend shows that there is a market for niche bots. On Facebook there are (mostly B2C) bots for providing information about a particular service or for selling you a particular item. On Slack bots are perfect for automating and delegating business related jobs (B2B or B2E).

Niche bots, connecting services

On a dedicated platform that is already been used for most of the communication a bot will be accepted much faster, reason why this time the bots will stay. They are no longer stupid or annoying (Well, Siri for example can still be pretty stubborn), but they actually make sense and can be great personal assisstents, that are capable of connecting one service to another.

If there is an API for that and you can do some smart semantic parsing then developing your own bot is not hard at all. And if it cannot be done virtually you can outsource any task to the real world, for example using Amazons mechanical Turk API.

Create a Slack bot yourself

If you do not have a Slack account yet you can sign up for free. Creating a bot on Slack is pretty easy and it will take you probably less than ten minutes to get the first one up and running. For the first sample, using BotKit, you also need to have NodeJs installed on your machine.

Create a bot user at The developers section of Slack. Give it a name and click on the Add bot integration button. It will result in an API token that you will need later and you can add some additional information such as an icon for the bot, a first and a last name and a description of what the bot does.

BotKit

If you are (a little bit) familiar with Node.js and JavaScript you can create your first bot with BotKit. BotKit works with Slack, Facebook messenger and Twilio. Grab it from GitHub or use NPM to get it.

bash
npm install --save botkit

Within the botkit folder you will find the slack_bot.js You can start your first bot with this command

token=your token at stack node slack_bot.js

That is all you need to get the conversation started! You can modify the file to make your bot 'listen' for other commands if you want or you can go through the documentation and examples that come with BotKit.

controller.hears(['what time is it', 'how late is it'], 
  'direct_message,direct_mention,mention', 
    function(bot, message) {
      var topic = message.match[1];
       bot.reply(message, 'It is '+ new Date().getTime()+
       ' milliseconds after January 1, 1970. '+
       'Does that answer your question?');
    });
});

.NET bot

If you prefer to use the web API instead or if you want to use C# and .NET for your bot then there is a solution for that as well. To get started with developing a Slack bot in C# you can get the .NET SlackAPI project from GitHub.

There is a little bit more work to do here to make it happen as this project, also because it is not as sophisticated as BotKit. First create an app in Slack. At The developers section of Slack go to Your apps and click on the Create app button. Enter a name, a short and long description, select a team and enter some (random for now) url for the instruction link, support link and redirect url fields. Then click on the Create app button.

Slack confirms the creation of the app and when you click on the App Credentials button you will find the OAuth information. You wil need the Client ID and the Client secret information in your .NET app

Visual Studio

Open the SlackAPI solution in Visual Studio, set the SlackAPI.console project as startup project and open the Program.cs file. Here you can modify the values for clientId, clientSecret and redirectUri, just as they appear in your app settings at Slack.

Customize the app a little bit so it will fit your needs. Then run the app and follow the instructions that will read in the console output.

  ...
  SlackClient.GetAccessToken((response) => 
   {
     var accessToken = response.access_token;
       Console.WriteLine("Got access token '{0}'...",
       accessToken);
       // post...
       var client = new SlackClient(accessToken);
       client.PostMessage(null, "#general", 
         "This is from the app powered by a "+
         ".NET implementation...", 
         "teambotterik");
   }, clientId, clientSecret, redirectUri, code);

In this example we post a message directly into the #general channel but with some extra effort we can do anything in .NET that you can do with BotKit. This could be handy if you have already an existing .NET solution that you want to use with your Slack bot or if you are more familiar with C# and .NET than with NodeJs and JavaScript.

Conclusion

In 2016 bots have become relevant again. With better AI and in a more connected world they have become smarter than ever. With bots dedicated to a particular task and the possibility for any company to create new bots to be used on widely used platforms the adoption of chat bots will be much larger than before. They may not eat the web yet but soon they will...

Further reading

• 1. BotKit on GitHub
• 2. Howdy
• 3. The .NET implementation of the Slack API
• 4. Slack API
• 5. Facebook messenger
• 6. NodeJs
• 7. Amazon mechanical Turk

Teamcity and HockeyApp; Delivering your iOS app

TeamCity and Hockey App are awesome tools for creating a daily (or continuous) build and distribution of your iOS app. Most developers will use Xcode to create an ad hoc distribution but the Xcode command line tools are more convenient for this purpose.

For a recent project I have been using Bitbucket, TeamCity and HockeyApp to create a canary build. In addition it is using CocoaPods for dependency management. This approach works well but it takes some time to figure all things out. If something goes wrong it is difficult to find out what went wrong although in most cases somewhere in the large logfiles a clue can be found.

Building an IPA file successfully does not guarantee the signing was successful as well. So the logfile says yes but your testers or early adopters say No. For this reason it is always smart to verify if the app can be installed on a device using Hockey app.

I will tell you what I did to make the four of them cooperate and how you can avoid some of the mistakes that I have made. It goes beyond the purpose of this blog to tell you everything about TeamCity or HockeyApp, so for now I assume you already have installed TeamCity and that you do have a HockeyApp account.

Prerequisites

• You are using Bitbucket (or another Git based repository such as GitHub)
• TeamCity has been installed and configured on a build server.
• You do have a Hockey app account up and running.
• An Apple developer account.

Obtain a distribution certificate

Use the machine (your own MacBook or a dedicated build server) where TeamCity is running to create a distribution certificate in Apples developer portal.

Create app ID, add devices and create an ad hoc provision profile

Unless you have already done so you need to create a new app ID, add some devices and create an ad hoc provision profile, just like you are used to do when creating an ad hoc distribution on your development machine.

Let's create a little script that takes care of dependencies in the Pod file, building an archive and creating an IPA file, using a provision profile file. At the end of the script we will upload the app to Hockey app and clean the archive and IPA file. It is that easy. Well, once you know what is going on, things are easy...

Pod install

If you are using CocoaPods to manage the dependencies in your project (and well, of course you do !) then you need to update them on your build server as well. That makes sense. So the first of the script goes like this:

pod install

Note: If CocoaPods is not installed on your build server then you need to install the gem first.

sudo gem install cocoapods

Build the archive

The command below is what you need for building the archive for a workspace, as is the case if you are using CocoaPods.

Here we will build the sample workspace using the sample scheme. It will create a sample_ad_hoc XCode archive file in the work folder. It is the same thing as when you choose Archive from the menu in the Xcode IDE.

xcodebuild -workspace sample.xcworkspace  
-scheme sample clean archive 
-archivePath /path to your TeamCity work folder/sample_ad_hoc.xcarchive

If you have no clue about schemes (or targets) in your project or workspace. you could use the list command to find out. Execute this command in the directory where your workspace or project reside.

xcodebuild -list

- or -

xcodebuild -workspace sample.xcworkspace -list

The output wil be something like this

Information about project "sample":
    Targets:
        sample
        sampleTests
        sampleUITests

    Build Configurations:
        Debug
        Release

    If no build configuration is specified and -scheme is not 
    passed then "Release" is used.

    Schemes:
        sample
        sample-cal

Export the archive

If everything went well an archive file has been created. The next step is to create a distributable IPA file from it. For this we need to have a valid provision profile file that you have created in the developer portal previously.

xcrun xcodebuild -exportArchive -exportPath build/ 
 -archivePath "path to work folder/sample_ad_hoc.xcarchive" 
 exportOptionsPlist exportOptions.plist  
 -exportProvisioningProfile "name of the provisioning profile"

Here you need the provision profile file that you have download from the Apple developer portal. It probably will be convenient to commit the provision profile file to the repository as well.You can also download the provision profile in a different directory on the build server and include the path to it.

Note: The name of the provision profile is the name as you have typed it at the Apple developer portal when creating it (or as it appears in Xcode -if you would have downloaded and installed the provision profile by double clicking on it-). Other than you might have expected it is not the name of the file.

Distribute the IPA file

Verify if a build.ipa file exists in the work folder. If it does you can distribute it to HockeyApp. It requires an app token from HockeyApp and a Hockey app Id. Make sure the app Id is configured for uploading purposes.

Using the curl command you can easily upload the IPA file you have just created. If this is for a daily (or continuous) build you probably do not want to notify all users each time a new version is available. You can use notify=0 for that.

HockeyApp obtains the version Id from the IPA file so you might want to create an auto incremental script later.

curl -F "status=2" -F "notify=0" -F 
 "ipa=@/build.ipa" -H 
 "X-HockeyAppToken:" 
 https://rink.hockeyapp.net/api/2/apps//app_versions/upload

Clean up

Very important but easy to forget is to clean up things, just to make sure that Hockey App fails if the build fails as well. Include this in your script to remove both the IPA and the archive:

rm build.ipa
rm -rf //sample_ad_hoc.xcarchive

Conclusion

Finally your script looks more or less like this:

pod install

xcodebuild -workspace sample.xcworkspace  
 -scheme sample clean archive 
 -archivePath /path to your TeamCity work folder/sample_ad_hoc.xcarchive

xcrun xcodebuild -exportArchive -exportPath build/ 
 -archivePath "path to work folder/sample_ad_hoc.xcarchive" 
 exportOptionsPlist exportOptions.plist 
 -exportProvisioningProfile "name of the provisioning profile"

curl -F "status=2" -F "notify=0" -F 
 "ipa=@/build.ipa" 
 -H "X-HockeyAppToken:your hockey app app token" 
 https://rink.hockeyapp.net/api/2/apps/
  your hockey app app id/app_versions/upload

rm build.ipa

rm -rf //sample_ad_hoc.xcarchive

You can store the script in a file and call it in a single build step or you can create multiple build steps. With some modifications you can use also the script for Jenkins instead of Teamcity.

These are just the basics for a CI/CD flow and there many things that you could include with a script or additional build steps. What about automated unit testing? Or running Cucumber tests on your build server? That would be fun too!

Further reading

• 1. TeamCity
• 2. CocoaPods
• 3. Building from the Command Line
• 4. Xcode command line tools
• 5. Cucumber
• 6. Hockey app

7 Parse alternatives or Parse It Yourself

Last Friday it was a bit disappointing to find out that Parse will discontinue its services. It used to be my favorite mBaaS as it was perfect for prototyping but also suitable for production data. It is a scalable solution, it has great documentation and is easy to use.

Many mobile developers of iOS and Android apps rely on the Parse backend system for data storage and push notifications. The fact that Facebook has decided to discontinue it is a bit surprising as they did put a lot of effort in supporting Apple TV (tvOS) and Apple watch recently.

What is Parse actually?

Parse is a mobile Backend as a Service (mBaaS) that uses a MongoDB database to store data and Amazon S3 to store files. The Parse SDKs for Android and iOS include handy stuff such as caching and uploading data and files in the background. Other features are analytics, push notifications and cloud code, which is useful for the integration of mail and SMS functionality for example.

If you want to create a new app using a mBaas right now there are some interesting alternatives. But if you do have an app that currently is using the Parse SDK probably your only option is to use the Parse Server. Here is a tutorial to find out what you need to keep your app running on the Parse technology. Or have a look on Github where the source for the Parse Server is hosted.

Some of the features supported by the Parse Server:

• CRUD operations
• Schema validation
• Pointers
• Users
• Installations
• Sessions
• Roles

Some of the not or not fully supported features:

• Push notifications
• Facebook login
• Web based dashboard

It cannot be too difficult to reanimate most of the Parse functionality using the recently published open source Parse Server. And that is what The distance has planned to do. Well, more or less. They have plans to offer hosting for the Parse Server.

Apps on the big screen part III: Debugging on an Android TV

How cool would it be if you can debug your TV app on a real device! For tvOS all it takes is a provision profile and an USB-C to USB-A cable to connect the Apple TV 4 device with your MacBook. How to enable the debugging option on a real Android TV is less obvious. It starts with selecting the right Android TV device.

Android 5.0 set-top boxes are hardly available in my part of the world and getting one from Ali Express is not an option, because the delivery times are too long and I do not have that much patience. So I decided to get myself a TV running on Android.

1. Pick the right Android TV

First of all, if you have plans to develop apps for Android TV and want to be able to debug them then it is important to decide which brand and model you pick. Previously I have made the mistake to chose a Philips TV, the 32PFK6500 to be exactly. It was the only 32 inch model that was available, which made it the perfect development TV, or so I thought.

It turned out to be not such a good idea. There is no way to debug and test your apps on this or other recent Philips Android TVs, basically because of Philips security policy. Yes, you can unlock the developers menu, but you will never be allowed to connect the ADB. This makes debugging impossible.

Too bad! It is a nice TV and I really enjoyed the Ambilight experience. This TV is probably great if you just want to watch TV and use some apps, but it is not really suitable for app development, although there seems to be a workaround to get your app at least tested through the Google Play alpha- and beta distribution mechanism.

Tip of the day: If you want to return your smart TV to the shop then do not forget to restore it to the factory settings. You may have entered your google account and others details that you do want to erase first. Unlike me, do this before you put everything back into the box ;)

So I went back to the shop and exchanged the Philips TV for a Sony Bravia TV, the 43W80xC one. With this television I have made a new attempt; this time with success!