Could Messaging interfaces be the next evolution in App UIs

Facebook launched M last week which lets you complete a variety of tasks, from finding information to making reservations, by messaging the assistant over Facebook Messenger. As Facebook’s David Marcus explains in his post, M sits between completely automated AI run services like Now and Siri and completely manual services like Magic, which lets it be a more useful than the former and more scalable than the latter. As Amazon found with Mechanical Turk, while the promise of AI is fantastic, humans are still pretty good at solving problems till that promise is realized.
But more than the functionality, the thing that struck me most was how simple messaging was almost the perfect interface to a lot of services, compared to the beautifully crafted app screens that so many of us spend so much time and money to develop.
Mobile platforms today have well defined design and interaction guidelines and app designers are left with the challenge of playing well within the guidelines but also come up with signature design and interaction elements that users like enough to choose that app over the flood of competitors. And as these become more elaborate, the cost of developing these apps keeps climbing even as people’s excitement about apps seems to be falling.
Could the simple UI of messaging apps make a lot of that effort irrelevant?
There have a few apps that have used the very familiar messaging UI as the primary interface for interacting with them:
  • Ethan was one of the first viral apps that allowed anyone to ask Ethan, just a random developer, any question and he would respond back.
    • ethanapp
  • I have already mentioned Magic is another interesting startup that lets you order anything at all by just sending them a message.
  • Lark is a fitness app that uses messaging interface and only allowing canned responses to allow you to track fitness metrics and log data like food intake.Screen Shot 2015-08-31 at 8.27.07 PM
  • Penny app has the same idea as Lark but is dedicated to the personal finance domain.
  • In Asia, a lot of apps already live within the messaging applications like WeChat as shown in the video below


Messaging UI also translates really well to non visual experiences, like apps for Amazon Echo.
Its surprising that right now none of the mobile platforms let you extend the core messaging services that come packed with the OS (Hangouts or iMessage). Facebook Messenger released its API this year though and it’ll be interesting to see what kind of services start to appear on top of it.

Rethinking Sign-In in the mobile first world

I have never been a fan of OAuth for signing in. Sure, it was better than sites asking for third party username and passwords, but It solved the problems for web-apps just around the time mobile was beginning to dominate how users interacted with the web. OAuth just does not work for mobile because the it was built on the premise that the sign in flow happened on a browser which could validate and enforce security.

As Twitter and Facebook started to get popular, sites started using their sign in buttons which were slightly better because on mobile, social login was handled by the OS. If you added your Twitter and Facebook credentials in the Settings on iOS, or had the appropriate Account Authenticator on Android, not only were you guaranteed security, the process was also a lot easier for the end user. That said, not everyone was okay with sharing their social data with these services, so the traditional sign in process on mobile remains the traditional links to use popular social platforms and an option for the more traditional email and password for those willing to endure some pain in exchange for some privacy.


As smart phones go global however, social login is just not as feasible. There are people out there without Facebook/Twitter accounts, or are getting more protective of their data. This trend has brought some interesting changes in the auth landscape.

Sign in with an email and no password

I recently read an article on how Medium is walking away from the whole passwords model altogether. Here is how they explain their system:

That’s right, no passwords. When you want to sign in to Medium, we’ll send you an email that contains a special sign in link. Clicking on that link will sign you in. That’s all there is to it. If you’ve ever used a “forgot password” feature, it works a lot like that, except you don’t have to forget a password to use it.

This is an interesting approach. On mobile this may be specially convenient where as soon as you get the email, you get a notification making the process fairly obvious without a lot of context switching between the site and the email app.

I recently saw this model implemented on Slack as well.


Slack is making this one of the ways to sign in, not the only way, which I think is smart. On a desktop I don’t mind typing a password, and might actually prefer that to switching to my email app/tab.

Sign in with your phone number

As the next phase of smart phone growth comes from developing countries, a lot of these people have never used emails. SMS is the communication medium of choice here, and it makes sense: SMS is the native mobile medium of communication.


The SMS model for auth asks the user to enter his phone number in the auth screen and then sends that number an SMS with an access code (or on Android with the right permissions, just detect when an SMS from them arrives on the device).

I first saw this model on WhatsApp, but has since been getting more popular. Recently Twitter has even released a service called Digits to enable signing in via SMS.

Sign in with another signed in device

One of the drawbacks of SMS based auth is that it cannot be used on devices that don’t have SMS capability (like Tablets or PCs). To handle this situation a lot of services are now implementing a way to log in on such a device by scanning a QR code on that device. The code refreshes periodically and when the app running on the mobile phone scans the QR code, the PC session and the mobile phone session are paired on the server and the user is signed in on the non-phone device.


Services like WhatsApp and Flipboard have started using this method, and I am sure more will follow.

A slight variant of this is the Apple Watch setup flow, which does the exact same thing but uses a different animated graphic that does the same thing as a QR code, i.e. pass data to another device using an image (click on the image below to go to the video)

Apple watch setup

Sign in with your signed in browser session

iOS 9 and Android M both include a more direct way to use the system browser rather than just using embedded WebKit / WebView. iOS’s new Safari View Controller and Android’s Chrome Custom Tab will allow app developers to use the browsers as part of their native apps. This will also let the native app get access to the browser’s Cookie store which means that users signed into the web version of the app can then be logged in immediately upon new app install. This detailed post by LaunchKit goes into details of that user experience.

Bonus: Sign in on app install (Google only):

While the previous paragraphs list a lot of alternatives to using social login if all you want is an identifying id, social login still represents the least friction way of getting more information and connections for a user. One thing I recently saw was Google’s “Android app install after sign in” feature. The system lets you add an “install app” step after a Google sign in on your site. The neat thing though is that the installed app is immediately signed in as soon as it gets installed. I recently installed an app that used this feature and it was great to not be prompted to log in on mobile.

This post summarizes a lot of new ideas I have been seeing lately around sign in lately. If there are any I may have missed, please leave a comment below :)

Bonus 2: Sign in with Google’s Smartlock (Google only):

Another system that was brought up is Google’s Smartlock that basically manages credentials across app and web sessions. I have very little knowledge about this but its worth being aware of. I think Netflix uses this.

Getting around TestFlight’s “Duplicate iTunes Account” Error for Internal Betas

One of the iOS prototypes I had been working on recently reached a point where I was ready to run a small internal test with it. Looking around for tools to manage the process, most people I talked to mentioned TestFlight. I had used TestFlight before Apple’s acquisition to receive betas but never really ran the test process myself.

The process to add users to TestFlight is reasonably well documented. However, when trying to add one of my team members as an internal tester, we immediately ran into this error:

iTunesConnect error

Turns out that person was also added as an internal tester to a different account. For alpha builds, Apple not only limits the number of developers that can be added as internal testers but also mandates that they are not part of a different internal beta test group.

Theoretically, we could create a provisioning profile for this and other developer devices that we’d like to test on, but the auto updates via TestFlight are really convenient. Some teams I talked to had implemented their own test management server to handle this, but it seemed like a lot of work.

It turns out, getting around this is rather simple. Unlike the app install management system that uses device UUIDs which makes that almost impossible to install unsanctioned apps, having an app managed by TestFlight only requires that user to get access to the welcome email (with the app link) TestFlight sends out when a new user is invited.

So basically you do this:

  • Create a new iTunes account for the user using an email address that person has access to and has never been used for iTunes (or just create a new email address)
  • Invite that new account to the alpha test.
  • When TestFlight sends the invite email, get that email forwarded to the email address that user has on the iOS device. As long as the invite email is opened on the device, TestFlight will start managing the alpha test process as you had wanted.

The big “whew” moment here was that the TestFlight invite is (at least for now) not tied to the user’s iTunes account that he/she is using for the AppStore on that device. In fact, the invite email has no idea of whom the invite is for and can be used by anyone.

That said, the whole requirement of one user being able to participate in only one alpha is needlessly restrictive. Hopefully Apple changes this in the future.

The best standard is a killer application


I was reading a post recently by a friend, Mark, about the challenges of getting Wifi Direct working with multiple Android devices. As with most Android development, you are reasonably assured that your app will work on a wide variety of platforms as long as you work within the Android framework, but the moment you start working with hardware sensors, you get into wtf territory pretty quick (talk to anyone who has created a camera related app on Android).

The problem probably is that Google’s direction to OEMs probably mandates a few APIs that they must implement but leaves most of the details to them. And even this is just restricted to devices that Google actually can control. There are a lot of Android OEMs that don’t have any relationship with Google (Xiaomi, Amazon, etc).

To get these guys rowing in the same direction, you don’t need better documentation or rules, you need killer apps to be built on top of them. In the case of Cameras for example, I imagine it would be hard for an OEM to ship a product without making sure Facebook and Instagram work on the device.

Wifi-Direct’s problem is that there isn’t yet a killer app built on top of it. I think Android Beam uses it, but no-one really uses that feature (Beam itself was probably the wannabe killer app that would force NFC and Wifi-Direct adoption among Android OEMs).

It would be hard to imagine a startup or an independent developer building a killer app for it, basically betting their bank on a fractured technology ecosystem. If Google was serious about it, it would have to come from them. But Google’s direction now is to look increasingly at the cloud to solve these problems and so I imagine Wifi-Direct would be left to the side in favor of something powered by something like WebRTC.

This thinking also needs to be applied in the IoT market where there is are so many new standards for device to device communication (AllJoyn, Thread, Brillo, etc). However, without any real killer app in that world, it seems most of these are on the same road as Wifi-Direct.

The best standards emerge from successful products.

Google Maps Timelines and my 2007 maps hack

I just saw a blog post from Google announcing the timelines feature in the new Maps app for Android. The feature extends the previously available (though often hard to find) location history view with photos from Google Photos.

I am really glad this exists now. I have wished for something like this for a very long time. I even started making my travel maps back in 2007 manually using Google Maps “My Map” feature. In my case the photos were coming in from Flickr and embedded with text in an iFrame. I even started working on an app that would do this but lost interest halfway through (story of my life ;) )


The fact that its automatic is very convenient, though I wish I could add non-google data to this. Am also surprised that these timelines don’t integrate with the Stories feature of Google+ Photos Google Photos.

Notes from the 2015 Quantified Self Conference


The 2015 QS conference was at Herbst Pavillion / Cowell Theater right on Pier 2 in San Francisco.

If you can’t measure it, you can’t improve it. – Peter Drucker

A few years ago I was introduced to a growing subculture in the U.S. that was really interested in numerically measuring a variety of aspects of their lives like steps, sleep, environmental conditions around where they lived, etc. and attempted to draw correlations from this data to improve some aspect of their lives. This was before the current explosion of fitness devices and collecting this data was a lot more difficult, and yet these individuals went through enormous effort often wearing clunky self-made devices to get access to the numbers they were looking for. The behavior seemed, at least by conventional definitions, not normal.
Today, at least a part of this behavior has seeped into conventional user behavior with the rise of measuring devices like Fitbit, smart watches etc and the constant running of ads emphasizing the importance of people tracking their own fitness. But the QS community continues to break new ground in identifying interesting metrics about themselves and finding creative ways to collect them.
A couple of weeks ago, the QS community had their annual conference in San Francisco and I was fortunate to be able to attend it as Comcast Labs, the group I work for, was one of the primary sponsors.
The QS community is an interesting group of people that come together around their common interest of measuring personal data. I had assumed that it would be predominantly be full of technologists or statisticians, but I met people from a variety of backgrounds from artists to models to fitness instructors.
I feel I met 3 types of people there:
  • People doing it for pure curiosity, like measuring time spent on couches or watching TV, cataloging their travels or seeing if chat history could show when they fell in love with their now significant other.
  • People who were trying to deal with real or potential health issues like building apps to collect data to quantify effects of both disease and medication on their bodies
  • People who were using their their own data for artistic interpretations or visualization
The Data:
What was interesting was the sheer number of data points people were tracking. A lot of this data used to require medical grade equipment to measure but now can be measured with fair accuracy using off the shelf devices.
These included
  • Heart Rate Variability
  • EDA: electrodermal activity, also known as EDR or GSR, galvanic skin response
  • BMI
  • Blood pressure
  • Fat percentage
  • Macro Nutrients intake
  • Sugar intake
  • Hydration
  • Resting Metabolic Rate
  • Resting Heart Rate
  • Anaerobic threshold:
  • VO2Max
  • METs
  • EEG
  • Breathing patterns
Not all metrics were biological. There were also examples of people tracking environmental and social metrics that could influence their lives like:
  • Electric and magnetic fields in their environment
  • Expenses
  • Email volume and how it related to their stress levels
Questions and Answers
Getting data is only one part of the equation. The real challenge is to correlate this data to draw insights. There were a number of talks around people drawing such correlations which were interesting cause a few missed that old adage about correlation not being causation (Did you hear the joke about data proving pirates causing global warming? Cause if you plot the rise of piracy and global temperatures on a graph, they correlate pretty closely). The other challenging aspect is the whole Heisenberg Principle about the very act of measuring something changing what you are measuring.
Even so, the speakers at the event had some really interesting talks on a trying to answer a lot of questions via data, such as:
  • How does exercise affect metrics like blood pressure or mood?
  • How do different diets influence mood, health or different ailments?
  • How does zapping your head with controlled electric current affect your brain?
  • How does stress affect heart rate variability?
  • How much does it cost to eat healthy?
  • How happens to your expenses if you don’t have a place to live for a year?
You can see their entire lineup of talks here.
Most of the community uses Google spreadsheets to analyze their data, though there was also a talk by a developer at Tableau software about how he used that to analyze his data. But the community is small enough that right now there aren’t enough general purpose statistics oriented tools built for them. At this point just getting data in a non proprietary format like CSV is a challenge (most fitness related services like Fitbit, Google Fit or HealthKit offer their data via APIs but only a fraction of the audience here were software engineers). Other software tools like Beeminder, Zenobase, Gyroscope, Compass  RescueTime were also interesting to see. New wearables like Spire for tracking breathing patterns also piqued my interest but having acquired one, I feel like a second wearable is just one (heh, maybe even two) too many.

Spire is a wearable that clips around your waist and tracks your breathing patterns and guides you towards a more calm breathing pattern

In conclusion
The QS conference was quite an experience, specially since I wasn’t that aware of all the stuff happening there and everything felt new. While a lot of it felt a little “out there”, it was the same feeling I got 3 years ago when I first heard about these guys tracking their steps and hours of sleep. It’ll be interesting to see how much of this data measurement becomes commonplace in the coming years.