Para uma pessoa entrar no sistema ela precisa ser convidada e possui CPF e Facebook válidos

[matheuslc]

O quê?

Precisamos de algum mecanismos para garantir que quem entra na ferramenta é uma mulher e possuí um CPF válido.

Problemas ainda não respondidos

• Como será a validação desse CPF?
• Como iremos distribuir os convites?

[matheuslc]

No cadastro, usuário precisa tirar uma foto na hora e enviar durante o cadastro. Iremos validar estas fotos na mão

[matheuslc]

CPF só para registro

[matheuslc]

Usuários serão convidados. Cada usuário terá 5 convites para distribuir.

[heitormurara]

Facebook requerido para cadastro.

[matheuslc]

Antes de ter isso precisamos ter o cadastro do usuário, logo, precisamos pensar nessa estrutura também

[richardbertozzo]

• Para convite acredito que podemos gerar uma URL que vai direto para a tela de cadastro do app, essa URL vai ser enviada por e-mail(podemos utilizar o sendgrid). A pessoa indica a pessoa pelo e-mail.
• Para o cadastro é uma boa ser apenas pelo Facebook, ou ter as 2 opções mesmo. Mas msm assim temos que pensa na estrutura conforme o Carmo comentou.

[matheuslc]

Boa @richardbertozzo! A URL pode ser composta por um ID pequeno único que daria até para o usuário colocar sem a URL (usando o id)

[matheuslc]

Cadastro de usuário, sugestão: Loga somente com o Facebook e pedimos/salvamos algumas informações na base em uma tabela User. Penso em uma estrutura simples como essa: User:

• first_name : String
• last_name : String
• cpf : Integer
• birthday : DateTime
• avatar_url : String

[matheuslc]

Teremos preferências, por exemplo de que quais notificações o usuário deseja receber? Imagino que podemos fazer no futuro e para esse MVP ta de boas.

[matheuslc]

@richardbertozzo O caso do link não ia ser ruim para abrir no app direto? A gente pode mandar um código e o usuário na hora de se cadastrar coloca esse código. A gente valida o código e continua.

[matheuslc]

Para a tabela de código eu imagino algo assim:

InvitationCode

• code : String (6 letras pode ser)
• owner : User (relacionamento com a entidade usuário que é o dententor desse código)
• used : boolean (já foi usado ou não)
• usedBy : User (relacionamento com a entidade usuário que usou esse código)

[matheuslc]

Automaticamente um usuário novo ganha 10 convites. Então, quando um usuário novo entrar a gente cria 10 entidiades novas de InvitationCode vinculando com o usuário novo criado.

[matheuslc]

@dieacetaria/backend uma dúvida galera, eu acho que valores vazios em uma tabela podem ser um insigth pra gente melhorar o design disso. Na tabela InvitationCode, o usedBy ficaria vazio até que um usuário de fato use ele. Você tem alguma sugestão pra gente lidar com isso?

Não tem problema ficar assim agora, é só uma provocação pra gente dar uma pensada.

[matheuslc]

Não precisamos de nenhum tipo de e-mail transacional para validar o usuário já que vamos usar o Facebook, certo?

[matheuslc]

Breaking Cards:

• Cria app no Facebook, inclusive o modo desenvolvedor
• Criar tabela User e InvitationCode
• Criar persistência no banco para os códigos. Nesse caso não precisa ser um CRUD, só criar ta show, não vamos editar, nem excluir.
• Criar gerador de códigos de convite
• Desenhar tela de cadastro
• Desenhar tela de login
• Criar tela de cadastro (que inclui um input para o código) / Android + iOS
• Criar persistência (CRUD) no banco para os usuários criados

O que acham galera?

[richardbertozzo]

@richardbertozzo O caso do link não ia ser ruim para abrir no app direto? A gente pode mandar um código e o usuário na hora de se cadastrar coloca esse código. A gente valida o código e continua.

Sim, da pra fazer assim. Só que seria mais maneiro, acredito que pode ser algo pro futuro. Esse código de convite colocamos um tempo de expiração?

[richardbertozzo]

@dieacetaria/backend uma dúvida galera, eu acho que valores vazios em uma tabela podem ser um insigth pra gente melhorar o design disso. Na tabela InvitationCode, o usedBy ficaria vazio até que um usuário de fato use ele. Você tem alguma sugestão pra gente lidar com isso?

Não tem problema ficar assim agora, é só uma provocação pra gente dar uma pensada.

Talvez ter o atributo de invitations_available, a se o usuário ainda tem convites. A sistema deixa ele gerar mais um convite e gera esse registro da invitationCode, mas deixando em branco o usedBy até o usuário ter cadastrado msm.

[heitormurara]

@richardbertozzo O caso do link não ia ser ruim para abrir no app direto? A gente pode mandar um código e o usuário na hora de se cadastrar coloca esse código. A gente valida o código e continua.

Concordo com isso.

[heitormurara]

Teremos preferências, por exemplo de que quais notificações o usuário deseja receber? Imagino que podemos fazer no futuro e para esse MVP ta de boas.

Acredito que pro MVP podemos seguir sem priorizar isso.

[heitormurara]

Não precisamos de nenhum tipo de e-mail transacional para validar o usuário já que vamos usar o Facebook, certo?

Acho que não precisamos.

[heitormurara]

Breaking Cards:

• Cria app no Facebook, inclusive o modo desenvolvedor
• Criar tabela User e InvitationCode
• Criar persistência no banco para os códigos. Nesse caso não precisa ser um CRUD, só criar ta show, não vamos editar, nem excluir.
• Criar gerador de códigos de convite
• Desenhar tela de cadastro
• Desenhar tela de login
• Criar tela de cadastro (que inclui um input para o código) / Android + iOS
• Criar persistência (CRUD) no banco para os usuários criados

O que acham galera?

Boa! Creio que seja por aí mesmo.

[heitormurara]

@dieacetaria/backend uma dúvida galera, eu acho que valores vazios em uma tabela podem ser um insigth pra gente melhorar o design disso. Na tabela InvitationCode, o usedBy ficaria vazio até que um usuário de fato use ele. Você tem alguma sugestão pra gente lidar com isso? Não tem problema ficar assim agora, é só uma provocação pra gente dar uma pensada.

Talvez ter o atributo de invitations_available, a se o usuário ainda tem convites. A sistema deixa ele gerar mais um convite e gera esse registro da invitationCode, mas deixando em branco o usedBy até o usuário ter cadastrado msm.

A ideia do atributo invitations_available é que esteja dentro da entidade de usuário? Isso não quebra a ideia de a entidade ser somente uma entidade?

Sobre a abordagem para gerar convites, achei interessante. Caso adotada, podemos trabalhar com tempo de expiração para os convites – como tu comentou antes.

[pikonha]

@richardbertozzo O caso do link não ia ser ruim para abrir no app direto? A gente pode mandar um código e o usuário na hora de se cadastrar coloca esse código. A gente valida o código e continua.

Eu acredito que como primeira impressão o convite podia abrir em uma página web (pwa talvez) pra mostrar a nossa cara, pra pessoa já se sentir confiante com a gente. Validaria nesse site e encaminharia pro download do app ou pra página de responsáveis.

[heitormurara]

@richardbertozzo O caso do link não ia ser ruim para abrir no app direto? A gente pode mandar um código e o usuário na hora de se cadastrar coloca esse código. A gente valida o código e continua.

Eu acredito que como primeira impressão o convite podia abrir em uma página web (pwa talvez) pra mostrar a nossa cara, pra pessoa já se sentir confiante com a gente. Validaria nesse site e encaminharia pro download do app ou pra página de responsáveis.

Acho que pode ser no app mesmo, fazer tipo como é feito em onboarding, saca? Quando a pessoa abrir o aplicativo, mostra alguns estágios antes de mostrar a tela de inserção de código – em um desses estágios pode ter uma tela com um link pra uma página web que fala mais sobre o projeto, também.

[matheuslc]

@picolloo @heitor-murara massa, curti, bom ponto. Importante a gente dar contexto e dar interesse para a pessoa querer usar.

@richardbertozzo não colocaria tempo de expiração, faria igual ao nubank, tu tem 10 convies teu é isso, primeiro que usar invalida ele

[heitormurara]

@matheuslc no cadastro a pessoa poderia cadastrar uma senha também para casos de desinstalação do aplicativo, restauração do celular, etc. ela poder relogar na aplicação informando CPF/senha, não?

[heitormurara]

Telas:

• Onboarding (funciona como uma tela de boas-vindas)
• Validação de código
• Cadastro
• Login

[richardbertozzo]

@picolloo @heitor-murara massa, curti, bom ponto. Importante a gente dar contexto e dar interesse para a pessoa querer usar.

@richardbertozzo não colocaria tempo de expiração, faria igual ao nubank, tu tem 10 convies teu é isso, primeiro que usar invalida ele

Show, pode ser. Mas no NuBank se tu manda um convite e o cara não aceitar o convite já foi usado, então acho q podemos levar essa ideia em consideração.

[richardbertozzo]

@richardbertozzo O caso do link não ia ser ruim para abrir no app direto? A gente pode mandar um código e o usuário na hora de se cadastrar coloca esse código. A gente valida o código e continua.

Eu acredito que como primeira impressão o convite podia abrir em uma página web (pwa talvez) pra mostrar a nossa cara, pra pessoa já se sentir confiante com a gente. Validaria nesse site e encaminharia pro download do app ou pra página de responsáveis.

Acho que pode ser no app mesmo, fazer tipo como é feito em onboarding, saca? Quando a pessoa abrir o aplicativo, mostra alguns estágios antes de mostrar a tela de inserção de código – em um desses estágios pode ter uma tela com um link pra uma página web que fala mais sobre o projeto, também.

Entendi, então primeiro a pessoa se cadastraria pelo facebook e depois inseria o codigo de convite? Ou adicionaria o codigo antes do cadastro do Facebook?

[heitormurara]

Primeiro valida o código, depois cadastra. @richardbertozzo

[heitormurara]

No cadastro, usuário precisa tirar uma foto na hora e enviar durante o cadastro. Iremos validar estas fotos na mão

Mantemos isso no cadastro, certo?