Discussion - Onboarding

[thescurry]

Hello Team, this is a discussion ticket to kick off our onboarding efforts. Please review the onboarding flow and let us know if you have any questions or need clarification.

These additional onboarding screens start after the user picks a username, once that's done they see the location primer:

https://zpl.io/Vkmkdyq
https://zpl.io/agnZj1R

Followed by the accelerometer primer:

https://zpl.io/2j81Dyq
https://zpl.io/VxkM79J

Followed by notification primer:

https://zpl.io/boB5vAW
https://zpl.io/VxkM79J

Followed by the Find Friends primer:

https://zpl.io/adPzXql
https://zpl.io/29PwK8p
https://zpl.io/bWkNj91
https://zpl.io/2ZkDQD1

The find friends to follow screens may require an RN library to pull in the contact info, let's discuss that solution here as well if needed.

cc: @bengtan @aksonov @southerneer @irfirl

[bengtan]

The last zeplin ...

https://zpl.io/bWkNj91

The find friends to follow screens may require an RN library to pull in the contact info, let's discuss that solution here as well if needed.

That's a new feature, and depending on how it matches entries in the phone contacts list, may need a new server API.

So ... I think we need to talk about how it matches entries.

Is it matching purely by phone number? So the client sends all the phone numbers in the phone Contacts to the server and the server indicates which ones are existing tinyrobot accounts?

We should consider spinning this feature out into a separate ticket. It's also easier to develop and test if it's a stand-alone feature.

[thescurry]

Happy to spin this out into a separate ticket @bengtan. I guess we can do that once we get done discussing all the bits of this ticket.

[thescurry]

Adding @toland to the discussion as we'll probably need help from the backend team on this one. We are leaning towards digesting the contact list, presenting the user with a nice list of their contacts where they can simply choose who they wish to invite, press the invite CTA next to each contacts name and then that data gets passed to the server and we send the SMS invite from the server side. We should research what options are available to us to handle the SMS invite bits on the backend, I have already asked Phil to start looking into this part.

Also @bengtan we updated that screen to indicate "invited", please see: https://zpl.io/2ZkDQD1

[toland]

I did some research on server-side SMS this afternoon. Amazon SNS supports sending SMS messages. We used to use SNS for push notifications and eventually dumped it because it just made the process more complicated than it needed to be. Happily, sending SMS messages through the service appears to be much simpler. As far as I can tell from the documentation, it is a fairly bare-bones service, but I think it is enough for what we want to do.

The other big service in this area is Twilio. Their service appears to be much more full-featured than SNS.

Either service would probably work for us. Also, it doesn't look like the server-side code would be very complicated.

[bengtan]

Hold on ... I'm talking about something else. I might have misinterpreted the zeplin hence now I think we should clarify.

I interpreted the zeplin as follows:

1. The 'Find Friends to Follow' (FFtF) screen displays any phone Contacts which are also existing tinyrobot accounts. For each of these accounts, there is a button which allows the user to immediately follow (on tinyrobot) the account.

but I think you guys are thinking:

2. The FFtF screen displays any phone Contacts which are not existing tinyrobot accounts. For each of these contacts, there is a button which allows the user to send an invite (via sms or other) to the Contact.

These are two different things.

In my mind, 1 is more natural as part of onboarding. I speculate that any people who just signed up wouldn't want to invite other people via sms (ie. 2) until they've tried out the service first. Anyway ...

Please clarify whether the FFtF screen is meant for 1 or 2 or both.

---

In any case, we'll need a new client-server API to support 1 or 2. If both are needed, we might decide to implement a single API that supports both 1 and 2.

We are leaning towards digesting the contact list,

So the app is uploading the entire phone Contacts list to the server? Since this is privacy-sensitive, I think we should be explicitly conscious that we're doing this.

---

Thinking some more ... 1 and 2 (whichever is decided) are both useful as stand-alone features after onboarding. It's worth considering implementing them separately first, and then append them to onboarding afterwards.

[southerneer]

Based on convos with @thescurry it's more 2 than 1. In the current state of the app we don't have many users period so 1 would rarely apply. The main goal is attracting new users so we want to make it easy to send invites to people who don't already have the app. It also sounded like @irfirl and @thescurry had similar post-onboarding features that are still in the works.

[thescurry]

Yes, what @southerneer said (thanks). We need to create our userbase first, so for now I believe #2 is the route forward. 2'ish.

[southerneer]

Ticket breakdown:

1. Location primer + accelerometer make sense to work on together. Estimate: 8
2. Notification primer. Estimate 3
3. Find Friends...still in discussion. Looks like react-native-contacts is the way to go for third-party modules. Bonus: I'm friends with the guy who wrote it (he's still in LA afaik) so it would be easy to reach out if there are any questions.

[southerneer]

@irfirl @thescurry we definitely need a mock for a spinner while contacts are being pulled. It can take a few seconds just to get the contact list from the user's device for larger lists...especially if we include contact photos in the pull. And then we'll also have a network request to our back-end to process the records and return a list of existing and new contacts.

[bengtan]

It looks like I interpreted wrong, and we're doing 2, not 1. Okay.

---

presenting the user with a nice list of their contacts where they can simply choose who they wish to invite, press the invite CTA next to each contacts name and then that data gets passed to the server and we send the SMS invite from the server side.

Hmmm ... how about send the SMSes from the user's phone?

Pro:

• Free (for us)
• No need to build back-end SMS capability

Con:

• Might cost the user (for some countries and plans), which would discourage them from using it
• Might be limited in how many SMS we can send at one time.

---

Also, is the SMS invite one of those 'auto-invite' dynamic links, or just a hyperlink (ie. to the app store)?

If the former, do we send a unique link to each contact, or just generate one auto-invite link and send it to all selected contacts?

[irfirl]

@southerneer here is the loading screen for contacts: https://zpl.io/VQ9QDL5

[irfirl]

@bengtan SMS from the user's phone I'd assume would take the user out of the app into the text messaging screen which would be very annoying for users to invite multiple users. I think it should be one of those auto-invite links if it's not too much additional work.

[thescurry]

@bengtan Great question regarding the dynamic links. I think YES, if user A invites user B via his contact list... then if user B installs the app and signs up, they should be auto-friended to user A. Very similar to how inviting a user currently works with dynamic links.

[southerneer]

how about send the SMSes from the user's phone?

Yep, @irfirl hit on the biggest drawback...we can't batch send SMS's from a user's phone without a prohibitively tedious/slow UX.

is the SMS invite one of those 'auto-invite' dynamic links

We should definitely send dynamic links. @toland here you can find info about the Firebase Dynamic Link generator endpoint. I can send you our project's API key via Slack. I can also send you an example of the POST we make on the front-end since it's not super obvious what some of those parameters mean.

do we send a unique link to each contact

Since we have more control over the communication channel (i.e. we're sending SMSs to individual contacts) it would make sense to generate unique codes/links and treat them as one-time-use.

[irfirl]

Note for @southerneer
https://zpl.io/bPdleyl should replace the existing app-wide catch-all screen.

[bengtan]

I'm going to re-activate this discussion.

This is my summary of the current status so far:

Most of the onboarding screens are uncontroversial and client-side only. They are straight forward to implement, and half/most are done already.

There is discussion, API, and back-end changes needed for the 'find friends to follow' (FFtF) part at the end of the onboarding process.

Tentatively, (I believe) this is what happens for FFtF:

1. App retrieves all phone numbers out of the phone's contacts/phonebook.
2. App uploads all phone numbers to the server.
3. Server returns, for each phone number:
   3.1 Whether the phone number is already registered.
   3.2 If registered, whether the account-associated-with-the-phone number already has a user relationship with the onboarding user (and what type of relationship). [1]
4. App displays this list to the onboarding user.
5. From the list, the onboarding user may select
   5.1 One or more unregistered phone numbers to send an sms invite to,
   5.2 One or more already registered phone numbers to follow/connect/etc. [1]
6. App uploads list of 5.1 and 5.2 to server.
7. Server sends dynamic invite links to list of 5.1,
   7.1 Server creates/requests user relationships to list of 5.2.

We're going to need a server-client API for 2,3, and another API for 6.

[1] Items 3.2 and 5.2 may be dependent on, or impacted by, the user relationships model that is being discussed at https://github.com/hippware/collaboration/issues/8

5.2 and 7.1 together might be optional and omitted if we want to restrict FFtF to sms messages only.

[bengtan]

Back-end ticket:

New APIs for bulk phone number query, sms invite, user relation
hippware/wocky#2121

... but probably needs clarification of specification before it can proceed.

[bengtan]

@thescurry: Onboarding is almost done. I think this can be closed?

[thescurry]

@bengtan yes, I think you can close.