Selecting friends from whatsapp

[minaorangina]

From @minaorangina on December 20, 2016 11:28

Hi @rickardinho, We've been doing our research into how best to implement the Inviting Friends feature. We've come to the following conclusions.

• We've not found a way for a host to pre-select friends in Spark, for Whatsapp to then batch-send a message. The pre-populated message itself is doable. But there's no way of giving Whatsapp a list of numbers to send the message to.
• The contact list we receive from the device will be a mixture of mobile numbers/landlines etc. For things to work smoothly, we have to rely on people saving numbers in their address book accurately under the correct "Mobile" label. This is often not the case in reality, and it's very difficult to filter out landline numbers or find mobile numbers that have been registered under "Home" or "Work" or some other unusual label.

We've realised we're overcomplicating the feature. The main goal is to allow users to invite as many friends as possible, whether they have Spark installed or not.

A better solution would be for the host to be directed to straight to Whatsapp and select friends from there:

• Everyone receives same message with code for event. Those with Spark installed go straight to it. Those without follow link to download.
• Everyone signs up/signs back in, and enters code
• Everyone is added to event

Once you are in an event, future notifications could be in-app. But all initial invites will be via whatsapp message.

Benefits:

• Simplify flow for user. Most people are very familiar with whatsapp, and we won't have to build a whatsapp-style contacts list for users to select (which doesn't make much sense if whatsapp has a great interface for that already)
• Eliminate the issue of sorting through mislabelled numbers in the device's contact list
• No need to 'sort' between existing Spark users and new users, which was always going to be a complex feature to implement.

We'd love to know your thoughts!

Copied from original issue: DRDD2016/sparkn2#52

[minaorangina]

From @rickardinho on December 20, 2016 15:1

So I understand the problem. I think in principle I agree with your proposal, for those that don't have Spark... I.e. send a code via WhatsApp and select friends there.

How do you see this evolving when we might add in other invite/share options? I.e. invite via email or SMS or Facebook?

It's quite a departure from the way we designed it because we would then become reliant on other apps and are more of a companion app and cannot be used independently of WhatsApp.

I think my preference would be that we maintain Spark users in the Spark app... and people can use solely Spark if they desire to. But how would we identify a user's friends without some form of pre-existing contact list? Could we marry up Spark user database with the phone numbers/email addresses in a contact list? I've seen other apps show duplicate contact names with the email address or phone number shown underneath, eg:

Dave Rickard email@email.com Dave Rickard 07XXX XXX XXX Dave Rickard another.email@email.com

After all, it's for users to maintain their contacts app if this gets out of control, and not necessarily Spark.

[minaorangina]

(Apologies for the long one!)

Down the line, adding other invite/share options shouldn't be an issue if the idea is to select contacts from within those options (email address list, Facebook friends etc).

It is true that Spark would be reliant on WhatsApp, but as long as your goal is to be able to invite friends from as wide a circuit as possible, relying on external apps to invite people is a given.

On the point of users being responsible for maintaining their own address book: the issue here is that it is very complicated to build a feature that relies on unpredictable data. Code hates unpredictability, and it's the sort of thing that can cause errors very easily.

If we can't guarantee how well organised/maintained someone's address book is, we run into potential problems: e.g. "What happens if there are two phone numbers for one person, and the host selects the one that is not registered in the database?" "How do we separate mobile numbers from landlines?". Writing something that would handle all possible scenarios will be a challenge and would take time to get absolutely right, and I know you don't want the project to overrun too much. 'Hacking' together something that semi-works is also not ideal.

As mentioned, there's no way of pre-populating WhatsApp with selected users. A host would have to reselect people from WhatsApp after selecting internal friends. This duplication lengthens the event-creating process, whereas what we're suggesting would mean you invite people once only and you're done.

Looking at things from the end-user's perspective, the options here are:

• some users get an in-app (not push at this stage) notification about a new event, others get a WhatsApp push notification
• all users get a WhatsApp push notification about a new event

Seeing as push notifications are not being implemented this time round, internal users would never know about events they are invited to, unless they explicitly opened Spark up - as in the web app experience. So an indirect benefit would be that more people would be informed of new events straight away. It's also worth noting that users can (and often do) completely disable notifications on their phone for certain apps.

Just to understand your point of view: what is your main motivation for connecting the contact list with the database? Is it just to be able to inform existing users of a new event inside Spark? Is it to somehow build a network of friends within Spark? If it's the latter, this is effectively building a social network within Spark.

It's worth remembering we're only talking about the initial stages of inviting to a brand new event. Once that's done, all other event activities and notifications will take place within the Spark ecosystem.

[minaorangina]

@rickardinho by the way we are happy to chat on the phone tomorrow if necessary

[minaorangina]

From @rickardinho on December 21, 2016 8:58

Okay, I think I can see benefits to your suggested approach. Presumably if it's just a URL with a code parameter, then this can be shared via any means (I.e. a user could copy this from the WhatsApp message and send via Facebook or email, etc). So even though we might only build WhatsApp sharing for now, they would have another way to invite more friends via other networks. They could also take advantage of pre-existing groups.

My main concern is that anyone who could get hold of the code could invite themselves to events and the host loses control if the invites are managed outside of Spark.

Also, in the current version it's quite neat and I know who I've invited. As a host, how would I know how many people and who I've already invited to an event with your suggested approach?

The other concern I have is that we envisaged people turning off WhatsApp notifications and keeping Spark notifications as WhatsApp suffers from more "text diarrhoea" as banter fills up the stream... which is kindof the point of Spark. It's the one notification you want to leave turned on and keeps event communications separate.

Finally, even though it's not in scope for this sprint, I see push notifications as the very next thing we will implement before going live in app stores. The app doesn't function without it.

Any ideas on how to solve the issues above? I want to avoid creating another social network if at all possible, but it's how to achieve it in a neat way that continues to have the necessary functionality.

Happy to have a call later today but I will probably be able to respond quicker here this morning.

[minaorangina]

@rickardinho Regarding your concerns about anyone getting hold of code and inviting themselves: as long as a host can invite external people, this is a problem that exists regardless of the approach we take. One solution in a future sprint could be to give hosts the power to remove unwanted people from events.

In terms of knowing who you've invited - this problem also still exists. You can't pre-select people inside Spark from the contact list to then bulk-send the WhatsApp message, as they don't provide an API to do so. This means the host cannot have a complete list of invited people, no matter what approach we take. You will see who you've invited once people enter the code and join the event. But before this happens, there will never be a complete list.

We're a little concerned about the host's user experience when creating a new event, which must be as simple and user-friendly as possible. At the moment, this is how the host's experience looks:

1. Host sees their contact list and selects people (with potentially unreliable data)
2. Host hits Invite button, list is sent to server to find matches with existing Spark users (unreliable data, can't guarantee accurate matches)
3. Server finds, say, 10 existing users, the rest do not exist.
4. Host hits Invite rest of friends via WhatsApp button. Host is redirected to WhatsApp and sees their entire WhatsApp contact list
5. Host must manually select the remaining unmatched users from memory (as mentioned, we can't send a list of message recipients to WhatsApp)
6. Host sees list of invited users, but only the 10 matched people will be on it. There's no way of knowing who was selected in WhatsApp

From the host's perspective, inviting friends is quite a lengthy process that involves selecting friends twice. Most likely, the host will either forget someone in WhatsApp or accidentally invite them twice. Plus we still have the fundamental issue that we can't guarantee accurately matching people if the contact lists provided are disorganised.

In the current web app, thanks to the Facebook API you can select from a list of friends in a quick an easy way. This isn't something we can replicate without the Facebook API at this stage.

You mentioned envisaging people turning WhatsApp notifications off in favour of Spark. In theory, this is as assumption of how you think your users will behave. Any features we build have to come from evidence gained from user testing.

Of course, there's lots to consider for future iterations, but at this stage, the main goal is for you to have a robust MVP that will gain new users and traction. To do this, we'd advise focusing on a smooth, uncomplicated user experience so people will come back to the app.

Let us know your thoughts. Anita and I will work on the authentication side of things until things are more clear here.

[minaorangina]

From @rickardinho on December 21, 2016 14:18

I think you're right. I think you should proceed with your approach, with the following considered:

1. Ideally one click from the URL to go to Spark app (if already logged in, then straight to the event, otherwise to log in screen, then event). Ideally they wouldn't have to enter the code manually.

2. In future sprints we might build in either the delete from event feature, so just bear this in mind for the design.

3. Make sure we don't do anything in the design which prevents adding people from contacts in future and managing invitees within Spark (I.e. don't limit us for future add-on if we get feedback that this is what people want).

From my review how others do it, Facebook events, WhatsApp and Cluster all use the contact list to allow invites of either existing users, new by email or by phone number (and allow duplicate contacts to be invited), but Cluster also allows your approach too to invite people from WhatsApp/web link URL.

I appreciate though that they may have spent a lot of time and money getting this working which for now is not what we should prioritise.

Thanks for bringing this up as its a key thing for us to get right. For now you are right, go for the simplest that gets the most traction. :)

[minaorangina]

@rickardinho Ok great!
Just one small point to raise: URLs in the native environment are different from normal web URLs, so we don't think it would be possible to direct the user straight to the event. But we will do some research to see if there's a way around this at all.

[minaorangina]

From @rickardinho on December 21, 2016 17:0

At least if it could open the app to the feed if the user is already logged in, they should then see their latest event invite at the top of the feed.

[minaorangina]

Hi @rickardinho So we're looking into getting people into the event from the text message they receive. You said you'd prefer it to be a one-click thing without entering a code.

If it were possible, this could only apply to users who have Spark already. Those who don't would have to install/sign up, in which case entering a code would need to happen, as they wouldn't be taking a direct route into the app from the url.

With this is mind, is the one-click feature still something you'd like us to pursue during this particular round of work? My feeling is that it might be more time-efficient to build the 'Enter event code' feature (which we can't avoid), and perhaps enhance the app at a later date with a one-click feature for pre-existing users?

[rickardinho]

@minaorangina, that sounds fine to me. When do you now expect the finish date to be? Dave

On 23 Jan 2017 1:05 p.m., "Mina" notifications@github.com wrote:

Hi @rickardinho https://github.com/rickardinho So we're looking into getting people into the event from the text message they receive. You said you'd prefer it to be a one-click thing without entering a code.

If it were possible, this could only apply to users who have Spark already. Those who don't would have to install/sign up, in which case entering a code would need to happen, as they wouldn't be taking a direct route into the app from the url.

With this is mind, is the one-click feature still something you'd like us to pursue during this particular round of work? My feeling is that it might be more time-efficient to build the 'Enter event code' feature (which we can't avoid), and perhaps enhance the app at a later date with a one-click feature for pre-existing users?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DRDD2016/native/issues/38#issuecomment-274483029, or mute the thread https://github.com/notifications/unsubscribe-auth/ARFD9LN6Fzwy4xN41XysGgP6uXVzTVRGks5rVKWbgaJpZM4Lgacm .

[minaorangina]

Here's an idea of a new screen for entering an event's code. The invitee would be directed to the correct event after entering the code:

[minaorangina]

@rickardinho We're aiming for some point next week. Hoping to finish up the remaining front-end bits today or tomorrow

[rickardinho]

Looks good and simple.

On 23 Jan 2017 1:12 p.m., "Mina" notifications@github.com wrote:

Here's an idea of a new screen for entering an event's code. The invitee would be directed to the correct event after entering the code: [image: screen-shot-2017-01-23-at-11 42 02] https://cloud.githubusercontent.com/assets/8915092/22205031/fdad74b8-e16c-11e6-869f-17d87da41c76.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DRDD2016/native/issues/38#issuecomment-274484370, or mute the thread https://github.com/notifications/unsubscribe-auth/ARFD9HDzcGUcjPMlbw2qHLMpK9EZH9Gdks5rVKc2gaJpZM4Lgacm .