O aplicativo evoluiu bem e as funcionalidades estão todas praticamente implementadas, mas como tudo foi feito em um padrão MVP (
https://en.wikipedia.org/wiki/Minimum_viable_product) , os ajustes foram tantos que uma remodelagem precisa ser feita no front-end, consequentemente organizando também o back-end.
Sobre front-end, optamos por migrar a plataforma para jQueryMobile. Dessa forma o aplicativo deve ter uma interface mais amigável, evitando rolagens horizontais em todas as etapas, dispondo também de uma visualização que preencha melhor a tela, além de evitar problemas em navegadores de quaisquer dispositivos.
Os ícones agora serão gerados no formato de cada dispositivo utilizando o
http://realfavicongenerator.net/ (no formato atual ele apresenta um erro de favincon nos tablets, Windows e qualquer iOS quando adicionado como webapp.
O formulário será desmembrado em 3. Isso permite uma usabilidade mais objetiva dos recursos, evitando forms sequenciais, que não podem ser acessados isoladamente e atalhos solicitados pelo cliente dentro de um mesmo form.
- - - -
MENU 1- Atualizar dados do consultor
Neste form, viria apenas os dados do corretor. Quando atualiza, simplesmente atualiza os cookies. Com isso, os dados do corretor não precisam ser solicitados no form lá na frente (mas também, não pode deixar ele enviar proposta sem alimentar este form primeiro).
MENU 2 - Enviar orçamento (para possível cliente)
Neste form, pedir apenas dados do veículo do cliente, cep e placa. Com isso, o form fica mais enxuto, ao terminar já envia o orçamento para o cliente, avisa a corretora que um orçamento foi emitido e guarda o CSV orçamento da placa com os dados iniciais (explico adiante o motivo). O orçamento vai para o cliente com cópia para a empresa ok?
MENU 3 - Cadastrar adesão (de orçamento já feito ou não)
Neste form, é o mesmo que já fizemos até agora, e seguirá em etapas (usando o recurso de etapas do jQuery Mobile), mas ele não precisa pedir dados do corretor novamente, nem fazer aquela pergunta no fim sobre enviar documentos em seguida (explico adiante).
Para agilizar o trabalho, o primeiro campo seria a solicitação da placa. Se ele já tiver feito orçamento antes, apenas digitaria a placa e conseguimos buscar boa parte dos dados via CSV de orçamentos.
MENU 4 - Enviar Documentos (de Adesão já feita)
No formato atual, limitamos o consultor a usar o form de envio das imagens apenas se ele envia em seguida. Isso complicou muito a questão deles integrarem o form com um sistema, pois se não enviar as imagens, vai ficar incompleto. O ideal aqui, seria um form onde ele apenas informa a placa e acrescenta os dados.
- - -
Feito isso, em 4 versões o APP fecha com jQuery mobile, sem rolagem horizontal em hipótese nenhuma, funcionando nos navegadores nativos dos dispositivos Android, iOS e Windows. Um webapp profissional, sem nenhuma cara de improviso ou amadorismo.
- - - -
Para facilitar inclusive portar todo o front-end para um aplicativo compilado, todos os submits devem ser feitos sem redirecionar para arquivo PHP (utilizar submit em iframe por exemplo ou alternativa similar). Desta forma, o PHP fica totalmente separado do front-end. Mover todas as libs como a de envio de email para a pasta INC.
- - - -
Para facilitar troca de parâmetros um arquivo PHP pode conter todos os parâmetros da aplicação:
Assinatura de email da empresa (aceitar html)
Assinatura de email da consultor (aceitar html, troca só o nome ao enviar orçamento)
-
Títulos de todos os emails enviados
-
Dados de email da empresa / smtp
Dados do Mailchimp
-
Textos do regulamento (aceitar html)
Textos dos emails de resposta (aceitar html)
-
+ algum eventual parâmetro que surgir
- - - -
O projeto deverá ser publicado para testes em FTP fornecido.
Delivery term: July 28, 2015