"Hello" - A New Android Dialler with Facebook Profiles, Blocking and More

No sooner than I post about in-call services than none other than Facebook flex the power of the social graph and release Hello for Android.

Hello is intended to be a replacement for the Android telephone dialler app - to be successful, it must improve the experience of calling someone.  It attempts this feat by integrating a user's contacts on their handset with their Facebook contacts; using caller ID, it shows public profile information for the other party in a call; allows search of the open graph to find places and phone numbers; and, borrowing some of the functionality of Messenger, provides free calls to other users of Messenger or Hello and free texts to anyone on Facebook.

Caller Id Services

Caller Id is front and centre for the offering: if the other party in a call has a public profile on Facebook, you will see this in your Hello app and vice-versa:

• if your public profile contains your any of your phone numbers, and
• you call someone from any one of these numbers, and
• the person you call has the Hello app, then
• that person will see your public Facebook profile when their phone rings
• even if you are not friends. 

In short, Hello is simply exposing information that's already public, albeit in a novel way. 

Facebook hardly hides the fact that our profiles, including our phone numbers, are searchable.  The harvesting of this information has made the headlines time and again and, therefore, it seems impossible to believe that information about me - my picture and whatnot - is not already being routinely used by cold-calling marketing operations - the nuisance callers, that is.  Every time I consider this, I shiver, but this is the price I pay for using Facebook (and I have no friends on 'Ello).  My point being that we live with this without thinking about it - Hello serves to highlight what is already happening. 

Anyone who is offended by this should change their privacy settings as follows:

Years ago, mobile number verification was not enforced by Facebook, although in recent times strenuous efforts have been made to get users onboard with this.  Nowadays, if you add a new mobile number, verification is mandatory:

It is unclear how this is achieved for fixed line numbers.  I'm guessing landline numbers are harvested from business listings on the open-graph.  Therefore, there is the potential for someone else to attach a number to a false profile or to simply mis-enter a number (inevitably, this has happened).

In summary, Hello's Caller ID function makes use of public profile information and mobile numbers can be relied upon.  More on landline numbers, below.    

Call Blocking

Call blocking has been around since, well, forever.  The value that Facebook brings is in social call blocking.   It's pretty neat in 'Hello' and Facebook are giving it quite a high billing in their marketing material:

The image shows that 1218 users 'blackballed' an 800 number that has no attached Facebook profile. This social call blocking in action - the wisdom of the crowd at work.  Absent a profile, blocking results in the creation of an entity that is seen by everyone.

In and of itself, the public display of counts of users who have blocked a number has social implications.  Forget for a moment cold-calling and consider the implications of this feature amongst a group of friends.  Let's say there are a group of teenagers who form a tight clique.  There is a fall out, leading to one of the group being shunned by their peers.  The group blocks, en-masse, using the Hello app.  It does not matter whether the person being blocked has a public profile with attached phone numbers - once blocked, an entity for that number is created.

Recall that everyone using the Hello app sees the blocked number count and this means that there are social implications of blocking.  It's not hard to imagine a pretty bleak scenario where 
ostracisation and social stigma is spread as an unintended consequence of this feature.

That said, as someone who increasingly gets cold-called on their mobile, I appreciate this feature.  Genuine nuisance calls are a pain.  (As an Australian I would also like some means of reporting breaches of the ACMA Do Not Call Register, but that's probably a little too much to ask...)   

Facebook has provided a means to blacklist numbers.  You can bet that by the time you read this, the nuisance cold-callers will be actively seeking the most expedient work around - getting a new number, setting up a new profile and so on.

In summary, call blocking in Hello is useful, but, if I have understood it correctly, appears to open up the possibility of some unintended side effects.  

Search

Search - useful, right?  With the information Facebook have at hand, this aught to be vey useful indeed.  

In their demo, they search by name for an Italian restaurant.  The results show 10 thousand people like the restaurant (wow), the opening hours, the number of reviews, a rating and so on.  Google gives me more in their app...

What I did not see in Hello was how many of my friends like the place, how many have eaten there and how many have eaten there multiple times.  This is where Facebook can shine compared to Google, but it does not yet...

Conceptually, I also like the idea of being able to ask a friend who has eaten there for information "what's the wine list like?"  Because this is a phone, I aught to be able to call or message any of my friends who have been there.  Which is an interesting UX question given that I am in the results of a restaurant search.  

In a similar vein, can I search for 'Italian" and find local restaurants that my friends like? 

My point being that search could be truly awesome in this context.  It looks like a good starting point but the social angle needs to be worked further.

Messenger and Call Diversion to VoIP

The 'Hello' app contains elements of Facebook messenger.  Calls can be directed via the Messenger VoIP feature.  Texts can be sent avoiding SMS charges.  Who'd be a mobile operator?  It is several years now since I used my mobile directly for an international call...

What's Missing from Hello?

There are plenty of comments online and on Google Play about weaknesses in the app.  

First and foremost, it is not a replacement for the Android dialler and that makes using the app ungainly as a number of one star reviews attest.  Unless this core failing is addressed, Hello seems likely to remain in beta forever.

Beyond this, there are two simple features that I would add.  I have written about these before so I shall not spend too long discussing: 

1. Where are you?
2. Your Time

Where Are You?

The idea being that if the other party in the call is using "Hello", then they can share their location with me for a limited period of time, for example, the duration of the call, for five minutes, for a day or even forever.  

Your Time

This is about time zones.  Skype does some of this, but it could be a whole lot better.  My contact list and the dialler should show the local time for the contact - as I type this, it's 3:56am in Denver and so calling my buddy is not such a hot idea.   There is lots that Facebook could do with from address book time (he lives in Denver where it's 3:56am) to actual time (he's in New York where it's 5:58am).

This is a little thing, but I have many overseas friends and so perhaps I am biassed?

Hello - A Work in Progress

Hello, from Facebook makes great use of public profile information to provide caller ID services.  Number blocking is simple and social but possibly open to abuse.   Search is useful and could be much more so.  Directing calls via Messenger infrastructure is great, as is the integration of texting via Messenger rather than SMS.

As a beta product, the one great failing seems to be that the app is not a true replacement for the Android dialler app.  Until it is, I believe that it has not yet met the criteria for viability because it is clumsy.

Ultimately, in-call services need to be a core part of the telephony experience - only Xaiomi with miui are doing this.  Facebook should take note of what miui does - it is more polished than Hello.  Other handset vendors should take note - this shows the possibilities of an enhanced telephony app.

The Hello app is a completely separate beast from the stand alone Messenger app.  Over time, it seems that 'Hello' and 'Messenger' should be exactly the same app, with the dialler component able to replace the core Android dialler app.  Now that would be something.

In-Call Service Evolution

Recently, I was asked some questions about how I would improve the telephony experience on a mobile handset.  I made two suggestions:

1. Introduce mobile 'favicons' during a call, to the call history view and, more contentiously, to the contacts app.
2. Add a 'where are you' feature to the telephony app.  

These are ideas my colleagues and I mooted a decade ago.  Nothing new here then - I really have not given it that much thought since 2011.  Until now.

Given how close I used to be to these in-call services, my interest was piqued when asked abut telephony and so I thought I'd take a look at the state of play.  The last time I wrote on this was regarding the Thrutu app.  There has been a great deal of progress and, excitingly, at least one vendor has made these features a core part of the telephony app.  Sadly, Thrutu seems to have withered and died, so not an easy path...

 

Some Background

On most 3G networks, it is possible to have a simultaneous voice call and data session.  This core network feature enables a range of enhanced telephony features and, dating back to more than a decade ago, I worked on a range of apps that exploit these features.  For example, in Bullant's 2005 Call-Share app for Symbian S60 handsets I could share with the other party in the call:

• my location;
• a picture;
• a contact; and,
• a game.

These were all peer-to-peer services and Thrutu did a very good job of launching a commercial app that implemented these and more.

Taking a different tack at Phidget, we enabled a range of campaigns based upon the caller ID including:

• advertising;
• roaming support services like dialled number correction; 
• call interception for support services; and,
• called party free/busy through Exchange integration.

There are two sorts of app here:

1. One enriches the communication between two humans engaged in a telephone call, both of whom must have an enabling app; and,
2. One provides information about the other party in the call, but otherwise does not directly enhance the interaction between the two parties.

I continue to be surprised that no mobile operating system implements any of these enhanced telephony features.  Until now that is.  The second of these - Enhanced Caller Id - is gaining traction in the market as a core telephony service.  As noted, the first, as the Thrutu experience has shown, did not even survive.

 

Enhanced Caller Id

Xaiomi, now the world's third largest manufacturer of mobile handsets, is on an incredible upwards trajectory.  Their handsets are getting excellent reviews: the hardware seems to be well designed, well built, and, well specified - check out  Redmi Note 4G.  Oh, and the price point is nothing short of amazing. 

Xaiomi handsets run on Android and, like other hardware vendors, they are attempting to control parts of the software stack in order to create an ecosystem and lock in revenue after the point of sale.  Xaiomi's custom Android stack is called miui.

Amongst many other features, miui has enhanced caller ID baked into the telephony app.  The miui telephony app supports:

• unknown number lookup allowing call filtering;
• service number lookup (an enhanced mobile favicon that shows the company name and logo for the other party in the call); and,
• an in-call mobile IVR system - kind of a visual voicemail, but for IVR and similar to work by Nuance.

The key to these services is the underlying directory which maps phone numbers to icons, names, URLs and more.  No doubt it's the same directory that powers Xaiomi's various lifestyle services.

There does not seem to be a great deal written in English about these services.  But, from the information available, but it looks like the future of telephony has arrived on a truly mass market handset.  Miui's telephony features represent the first step from a major vendor down the road of in-call services.  There is much more that can be done, however. 

 

What's Missing from miui?

A Favicon and HTTP URL

As noted, miui supports 'service number lookup' - essentially a favicon for a telephone number.  I am intrigued as to why they have not taken the next step and made this interactive through the addition of a URL to a linked website with an associated 'favicon'. 

Such a telephony app would work as follows:

• As I dial a number or receive a call, a lookup service would be queried to find an exact match for the number.
• As soon as an exact match is detected, an icon that would be used to 'decorate' the telephone number entry field, rather like the URL entry field in your old browser.  (This would be particularly useful during slow, manual dialling because the it would enable a data session to be established and would give visual feedback whilst the user typed.)
• In the case of a dialled number, as well as the call establishment button, a secondary button would be enabled that allows the user to either make the call or to visit the associated website.
• The icon matching the other party's telephone number is shown in the call history view against that telephone number.  This icon might also be used to decorate a contact in the user's address book.

Earlier I noted that in Australia where I live, Sensis have launched an award winning app that does even more than this using the Sensis Yellow Pages directory - there are plenty of other examples of similar third party apps that provide similar services, such as CallApp.  (As a footnote I showed both Telstra and Sensis exactly this in 2009, but hey, no hard feelings...) 

Here, I made the case for a minimalist, incremental improvement to the caller-id service provided by the core telephony app.  The idea being to enhance the offering making it more useful, but keep a tight lid on scope so as to limit the impact on a core handset service.  

It follows that I think that, whereas as a third party app like Sensis or CallApp is great, but it may be a little over the top as a model for the core telephony service.

 

A Social Context In Call - Where Are You?

Bullant in 2005 and Thrutu in 2011 implemented a feature that allows two users engaged in a voice call to answer the all important question 'where are you?'  Since that time, iMessage and Google+ location sharing (and dozens of other apps) have gone some way to make this feature redundant.  Thrutu, though excellent for its time, has now vanished from Google Play.

I still believe that there is a place in the core telephony app for one in-call social feature - one that answers the question 'where are you?'  This will be used in many contexts including where the other party is not represented by an entry in my address book and, therefore, is excluded from the iMessage and Google+ services.

This is best explained through a use-case.  Last Friday, I received a call from a recruiter who had been given my number by a mutual acquaintance.  I was in the city and free and so agreed to meet him immediately.  I got, via SMS, directions to a cafe close to Wynyard Station.  Since there are many cafes close to Wynyard, this was of little help: two additional calls were required for me to home in on his actual location.

It so happens we both had an iPhone, so he could have gone to iMessage and shared his location.  It certainly would have been easier than the calls we made.  It would have been even easier if location sharing were exposed through the telephone app itself.

I argue that the utility of this feature and the frequency of its use is such that it is a contender for its own button on the telephone screen.  On an iPhone at least, the existing iMessage infrastructure and multi-tasking can take care of the rest.

 

In and After Call Advertisements - One Feature Too Many?

I am sure that Xaiomi have considered in-and-after call advertisements - they do not seem to have launched anything yet, however.  Here's an example of the sort of thing I am talking about - it's a demonstration campaign we at Phidget built for a pitch to an agency + UK operator:

The campaign works like this:

• The app detects an international call to a Singapore number.
• An in-call overlay is created that shows the time in Singapore, sponsored by the advertiser.
• When the user hangs up the call, the narrative continues - the handset screensaver shows a rich-media campaign linked to the call that has just completed.

The idea being that the in-call campaign was useful in and of itself and tied into an existing holiday-money promotion.

As noted, Calldorado is now making a business of exactly this style of service in-call, but in third party apps.  Amazon has, of course, sold an ad-supported Kindle and Kindle Fire since 2011 - my recollection is that they offered a $25 discount on the purchase price.

In early 2010, Vodafone UK ran a series of market research groups using our Phidget PACE ad campaigns.  As expected, users demanded quid pro quo for the introduction of advertising.  Fair enough except for the fact that our respondents felt they could reasonably expect two free movie tickets per month in exchange for having the service on their handset - that was unexpected. 

My point being that there is a gulf between users' perceived valuation of advertisements and the actual value generated by a service such as this.  Furthermore, ads in-and-after call, however well designed, were thought of as an intrusion of privacy.  Users lower on the socio-demographic spectrum were the only ones open to such a service, particularly women.

A search reveals that various users have reported that miui is reporting call details back to a Chinese server - which of course it must do to enable even the basic services offered by miui today - there is real privacy concern here that remains to be addressed.

In 2009, I put a straw man proposal in front of Vodafone UK.  I voiced out loud the suggestion that we implement an ad-words style system where we auction ad-slots based off of telephone numbers.  I illustrated my idea by dialling an Indian restaurant close to Vodafone HQ in Newbury, UK and showed an ad for a competitive restaurant.  The view was that an operator simply could not launch such a service.

Having been enthusiastic, beating the drum for this feature, my current view is that there is still a mountain to climb here.

Other In-Call Services

At Phidget, we built a range of in-call services whose value, I think, is self evident even today because they allowed a user to correct common problems.

In this example screenshot, a UK subscriber is roaming in Australia.  The user dialled a UK number from their address book and the in-call service detected that the call could not complete and provided a suggestion of how to correct the problem.

Unsurprisingly, in a trial of Australian subscribers, this feature was valued very highly.

In Summary

The 3G UMTS standard envisaged a world of simultaneous voice and data.  Multi-tasking users make use of this feature every day during telephone calls.  Xaiomi, with miui telephony, has finally directly made use of this feature in order to improve the core telephony experience.  The developers of miui should be congratulated on the restraint that they have shown - focusing on simple, core services that are of use to every user but never intrusive.

Services such as the Sensis app provide even more information to the user and are a useful install for those users who want the additional information provided.

Although previously a strong advocate of in-and-after call advertising solutions, I believe that these, if fully realised, will remain niche, providing a modest subsidy for users.  It is unclear to me whether they would be acceptable on a modern mobile device - particularly on larger screens where the battery penalty might be significant.

I believe that miui is the closest yet to an acceptable mass market in-call telephony solution.  With some additional minor changes, the feature could be made even more useful. 

Thrutu - In-Call and awesome - but not new...

Having been in the mobile industry for many years, it's interesting to see great new products come to market - things that can genuinely change the way we communicate with each other. One such product is Thrutu.
Thrutu uses the ability of the UMTS network to provide simultaneous voice and data session to provide an enriched telephony experience.

What do I mean by enriched? Well, imagine that you can see the location of the other party in the call? Or instead of reaching for a pen to jot down a phone number, this is simply shared from one phone to another.

This is Thrutu and it's available in Beta now for Android 2.1 handsets.

One of the reasons I am so enthusiastic about Thrutu is that I jointly invented and implemented an identical system in 2003/2004 when I was CEO of Bullant Software.

So why has Thrutu launched this and not Bullant? read on...

What was Bullant?

Bullant was a company based in North Sydney, Australia. We sold a product called the Bullant Remote - in essence a JavaScript VM for Symbian and MIDP handsets coupled with networked back end. The VM exposed most handset features - telephony included - to app developers. It made it possible to deploy applications on-demand to any handset equipped with the client. It was used in a variety of telco projects in Australia, Singapore, Japan and the UK. Bullant lives on as xumii.

The Call-Share Idea

In late 2003 or early 2004 I got an enquiry through our website from the Chief Trials Manager at Vodafone UK, a guy called Mike Howells. Mike and his team were looking at IMS applications and ideas around sharing content between handsets using a generic client.

After a face-to-face meeting in early 2004, I proposed a solution that would work on the existing Bullant client that leveraged the features of the soon to be launched UMTS network (but not SIP/IMS).

The product was called 'Call-Share'.

Vodafone Call-Share

Call-Share used the Bullant Remote for Series 60 handsets. The client started and connected to the network and then became dormant until a call was detected. If the call was on the 3G network, the client initiated a data-connection and passed the B-Party call details to a server. The server then attempted to determine whether there was a 'call rendezvous' between two handsets with the client.

On detection of a rendezvous, pCode was sent to each handset that was immediately executed and caused a UI to popup over the system Telephone application. This UI facilitated the sharing of a range of content types:

• My business card (with a nod to Palm OS).
  
• Any contact from my Address Book.
  
• A map showing my location.
  
• A picture (either captured live from the camera or selected from the handset Image Gallery.
  
• A multi-player game (Connect4 actually).
  

The app also worked on 2G. We had no 3G network when building and so, perforce, one of our developers simply created the data session as soon as the GPRS network was available on call-hangup. I'm not sure if Thrutu do this, but it turned out to be quite a neat trick.

Building the App

The app was designed by myself. The JavaScript components were built by Felix Castanar-Perez and Tom Hall. Brendan Babb and Matt Powell made sure all of the Symbian Client telephony interfaces were in-place and working properly. I built the Java based network back end to detect calls between handsets. The initial prototype was the result of eight weeks development.

Our biggest headache was detecting the handset MSISDN. We did not have an SMS gateway so we had to use the MCC/MNC from the IMSI to arrive at the canonical international form of the number in order to match calls. Thrutu seem to have the same issue which they solve by sending an SMS at install time.

Our second problem was location and mapping in the dark ages before GPS and Google Maps.

For location, Vodafone provided us with the UK Cell ID database. Since this was not exact, we allowed a user to navigate a cross-hair over a map of their locality. Once selected, the map popped up on the B-party handset UI. For maps, we did a selective trawl from Map24 in the UK. We got just enough map-tiles to cover the Newbury environs for demo purposes. Mapping worked surprisingly well...

The final issue was that we built this before the 3G network was launched in the UK. Luckily, we had Hutch in Australia to test with - although we never really got simultaneous voice and data working properly before we flew back to the UK.

Testing without 3G

I flew to the UK to present the finished app to the brass at Vodafone. I think this was about May 2005. At this stage, Vodafone had a barely functional 3G network. By a happy coincidence, they did have excellent coverage in Liverpool where I worked out some last minute niggles.

The app worked brilliantly on two shiny new Nokia 6630s provided by Vodafone. I flew to London (trains were not working) and presented the app at Symbian HQ and then to Newbury. I think they were impressed.

The app was subsequently demoed in Spain and, I think, Germany. Sadly, we could not get an OpCo to run with any further funding and so we shelved the app while we delivered Optus MyZooNow and SingTel's IdeasLive.

We subsequently hired Mike Howells from Vodafone UK to become our CTO in Australia. In a dog-and-pony show in October 2005 we took the Call-Share app to Helsinki to show Nokia, Stockholm to show the Ericsson IMS team and to various UK operators as well as one in Hong Kong and one in Thailand.

[Edit]What was Nokia's response? That it was very difficult to do anything with the Series 60 Telephone app.

In 2006 we took the app to Cingular in Atlanta and, rather embarrassingly, Verizon (more on that in a moment).

Of all the operators I demoed to, only Three UK expressed a strong-interest in the app. However, I don't know where that account got to.

Realistically, this is an off-deck app - we should never have tried to sell this directly to an operator.

Enriching Communication Sessions Anyone?

Mike and I took the IP we had created and he quickly wrote up a patent application entitled 'A SYSTEM FOR CONDUCTING MULTI-MEDIA COMMUNICATION SESSIONS'.

This was quite a departure from the original app and emphasised SIP and XMPP. We filed a claims with WIPO and PCT claim 12/187,378.

Share the Mobile Future?

Bullant raised a significant amount of money from CM Capital and Southern Cross Ventures in order to commercialise Call-Share and other apps in our portfolio. We merged with a US company and formed uiActive, whose "Share the Mobile Future" tag line was inspired by Call Share.

You can see our quote from the uiActive website via the Internet Wayback machine:

Enriched 3G communication sessions Intuitive user interface makes it easy to share applications and data (images, appointments, contacts, games, ring tones and locations) while talking.

So What Happened to the App?

Actually, I do not know for certain.

I stepped down as CEO in June 2006 when uiActive was formed and then left the company in January 2007. uiActive was subsequently renamed xumii.

At a guess, xumii did not pursue the patent application. (I assume this because after assigning the rights I was never contacted again in relation to this, one assumes the application was allowed to lapse).

xumii as a company took on and expanded greatly on ideas of mobile social networking - something they are doing very successfully to this day.

[Edit] Actually, on reflection, I suspect that the 2008 release of the iPhone 3G, SDK and App Store was the reason they dropped the app.

[Edit] The patent claim was filed in Australia in February 2006. A check of the patent database shows that the claim was allowed to lapse.

[Edit] I incorrectly stated that the US patent had been allowed to lapse. This is not the case. Apparently, it is still being argued, though the examiner has, thus far, rejected all of the claims due to prior art.

Do I use any of these Ideas?

I designed the PACE client in early 2008. It makes full use of simultaneous voice and data in order to minimise the battery overhead of moving campaigns to the handset. It also uses overlay windows drawn on the Telephony app to provide a range of value added telephony services such as roaming and voicemail support.

What was that about Verizon?

Note to self: It's best not to demo an app that relies on the simultaneous voice and data capabilities of UMTS to an operator who uses CDMA - which does not support simulaneous voice and data...

[Edit] I have been reminded that it was not actually me who attempted the Verizon demo. Fair cop - I used some artistic license - it was actually one of my colleagues.

I did make the same mistake with AIS in Thailand, but they are not quite the same as Verizon.

In the end...

The Bullant client was great because it was generic. What actually happened when content was shared was that an application was dynamically shared from the network and this app dynamically created the UI to view and interact with the shared content.

So, to engage in a shared game of Connect4, one user suggested the sharing and when the second user accepted the request, both handsets received the app from the network which then created the UI within the existing application window.

This is apropos of nothing, however, because the app was never launched to a mass market. Thrutu have done this. It may not be new, but it is brilliant. IMHO, it is the killer telephony app on 3G. I wish them all the best for this and I hope they get it pre-installed on every Android handset. I also wish the team good luck with iPhone - frankly, I will be amazed if they are able to put this into the Telephone screen although it is an obvious and valuable enhancement to FaceTime.

[Edit] I just got asked why I didn't build this myself. The answer is I could not due to my severance agreement with uiActive.

[Edit] I just got asked why try and sell to an Operator. There were no app stores in 2007 - Operators were our best chance at hitting the mass market. As I said, we did take this to Nokia, but did not get a bite...

[Edit] Why no screenshots?
I'll see what I can dig up from the information that was public.