🕎 🌤️ 🕐 Redesign de aplicativos - Visão interna 🤵🏿 👩🏽‍⚖️ 👨‍💻

Mobius bike é um serviço de aluguel de bicicletas e scooters desenvolvido para Tallinn (atualmente está planejada uma expansão geográfica).

A hipótese do primeiro lançamento é "um aplicativo de aluguel de bicicletas estará em demanda no mercado europeu". Em dezembro de 2019, a principal hipótese foi revisada e agora parecia assim: “o serviço de aluguel de bicicletas e scooters pode obter a distribuição máxima devido à conveniência do usuário final e do franqueado?” Para responder a essa pergunta, foi necessário implementar o seguinte:

realizar um trabalho de otimização da estrutura do aplicativo (interno - back-end e externo - design e front-end) para introduzir um novo tipo de transporte e possível dimensionamento no futuro
ajuste as condições de aluguel no painel de administração

Lyubov Nikiforuk - gerente de projetos

Telas principais da aplicação da bicicleta Mobius antes do reprojeto.Uma

das minhas primeiras tarefas como designer de produto foi preparar layouts para a introdução de um novo tipo de transporte - scooters elétricos. Depois de concluir os layouts, decidi fazer algumas alterações nos aplicativos de design e UX e criar um pequeno conceito de reprojeto. Mostrou novos layouts para a equipe. Eu recebi um feedback: os caras deram conselhos e compartilharam suas opiniões. Como resultado, várias telas principais foram digitadas.

A refatoração de código planejada para dois meses estava se aproximando e decidimos mostrar o novo design ao cliente para otimizar o código para a nova interface, a menos que, é claro, o cliente concordasse com o redesenho. Apresentamos layouts, explicamos como um novo design pode simplificar a interação com o aplicativo e quais benefícios ele trará para os negócios. E já no processo de apresentação, percebemos que o design "foi". O redesenho foi aprovado e agora começamos a refatoração com uma nova interface e o UX redesenhado.

Variantes das principais telas criadas durante o processo de reprojeto

Organização do trabalho

Como não tínhamos uma tarefa técnica claramente definida e nosso serviço foi desenvolvido junto com a empresa, tivemos que decidir como executar o trabalho: quais tarefas executar em primeiro lugar, como acompanhar o progresso e avaliar o resultado. Acima de tudo, o método ágil se adequou às nossas tarefas. A duração de cada sprint foi determinada em duas semanas. Todos os dias realizamos levantamentos - discutimos problemas atuais, compartilhamos idéias, resolvemos problemas. No final de cada sprint, foi realizada uma demonstração - eles mostraram ao cliente os resultados do trabalho realizado para o sprint.

Ágil em toda a sua glória

Teste de scooter em nosso escritório

Navegação

A primeira coisa que decidimos mudar foi a navegação no aplicativo. Em vez de um "hambúrguer", criamos um menu de guia inferior (navegação inferior). Você provavelmente percebeu que muitos aplicativos estão mudando para esse tipo de navegação. E isso é compreensível, pois o menu da guia simplifica o acesso às seções principais do aplicativo, mesmo que uma pessoa segure o telefone com uma mão. Mas esse não é o único motivo para usar esse tipo de navegação. O aplicativo foi desenvolvido no React Native, então tivemos que considerar os recursos desta plataforma:

(). , , , , , , . . . ,

— front-end

— «». — (bottom navigation)

, , UI-kit

Além de alterar a navegação, abandonamos os controles de escala na tela do aplicativo. Deixou o zoom com gestos. Janelas modais substituídas, diálogos e parte das telas por telas deslizantes. Novamente, porque é mais conveniente usar o aplicativo com uma mão - essa tela pode ser simplesmente "deslizada" para baixo e fechada.

Exemplos de telas deslizantes no aplicativo de bicicleta Mobius após o redesenho

Também simplificamos o processo de registro no aplicativo efetuando login no Google e no Facebook. Além de vincular cartões bancários, eles adicionaram a capacidade de pagar usando o Apple Pay e o Google Pay.

A tela para inserir o aplicativo e o pagamento usando o Apple Pay

Para facilitar a adição de novos recursos ao aplicativo no futuro, criamos uma biblioteca de componentes e descrevemos a aplicação e os princípios de interação.

Aplicações do kit de interface do usuário da bicicleta Mobius

Refatorando e mudando para GraphQL

Os principais objetivos do redesenho foram:

crie um sistema de componentes mais flexível e escalonável que permita facilmente adicionar novas funcionalidades, por exemplo, outro tipo de transporte, sem comprometer a aparência e a lógica geral de interação com o aplicativo
clarear e simplificar a interface o máximo possível
"Atualizar" a aparência do aplicativo

Mas, além de atualizar a interface do aplicativo, o lado visível do reprojeto, a transição da API RESTful para o GraphQL foi uma parte muito importante.

Simplificando, o GraphQL é uma sintaxe que descreve como um cliente (telefone / aplicativo) recebe dados de um servidor usando consultas especiais. Dependendo da solicitação, o servidor fornece esses ou aqueles dados.

Artyom Bukhtoyarov - desenvolvedor DevOps / Backend

O GraphQL possui três características principais:

permite que o cliente especifique exatamente quais dados ele precisa
facilita a agregação de dados de várias fontes
usa um sistema de tipos para descrever dados

O GraphQL atua como uma camada adaptadora entre a interface do aplicativo e os serviços externos. Isso permite transferir o processamento de muitas solicitações diferentes para trás. Ou seja, quando você conecta um novo protocolo de transporte, é necessário conectá-lo na parte traseira, e o layout recebe todos os dados de forma unificada do GraphQL. Assim, reduzimos a necessidade de trabalho de composição adicional ao adicionar um novo tipo de transporte e reduzimos o número de solicitações processadas no aplicativo.

Além disso, no processo de refatoração, destacamos as seguintes vantagens do uso do GraphQL:

documentação conveniente para o desenvolvedor
uma boa solução para o WebSocket, tanto para o back-end quanto para o front-end
O GraphQL facilita a navegação dos desenvolvedores na estrutura de código
um desenvolvimento mais flexível, em comparação com a API RESTful, permite adicionar algo novo de maneira mais rápida e fácil (no nosso caso, esse é um novo tipo de transporte)

Foi engraçado quando a primeira fechadura de bicicleta da China determinou sua localização geográfica na China, embora estivesse fisicamente em São Petersburgo. E o software para esse bloqueio foi criptografado e tivemos que procurar um método de descriptografia para fazer alterações nas configurações.

Inicialmente, quando tínhamos apenas um tipo de transporte, o servidor para conectar bicicletas trabalhava junto com o back-end principal. Em seguida, escolhemos o servidor para trava de bicicleta como um serviço independente que pode ser implantado em servidores separados - isso nos permitiu reduzir a carga no servidor principal e fornecemos oportunidades adicionais para dimensionamento. Para transferir mensagens entre serviços, usamos o RabbitMQ. E foi muito conveniente que ele tivesse um plugin para o mqtt - o protocolo no qual nossas scooters funcionam, o que facilitou a adição de um novo modo de transporte.

Pagamento no aplicativo. Inicialmente, planejamos adicionar cartões bancários no próprio aplicativo, mas, no final, decidimos por uma opção de redirecionamento para a página do banco e todo o processo de adição de um cartão já está ocorrendo lá. Esse método acabou sendo muito mais fácil de implementar.

Franquia e Administração

O proprietário do serviço tinha certos requisitos para o painel de administração do aplicativo. Como está previsto que o serviço seja vendido como franquia, cada franqueado deve poder editar o custo da viagem, parâmetros tarifários, assinaturas etc.

Por isso, redesenhamos o painel de administração para poder conectar novos proprietários de parques. Adicionadas funções diferentes - o proprietário do parque e o proprietário da rede. Fizemos uma seção inteira para adicionar e editar tarifas, assinaturas e multas com base no tempo. Em cada cidade, o dono do parque poderá definir suas próprias tarifas e alterá-las. Eles também tornaram possível moderar as alterações pelo administrador da rede. Expandimos a estrutura do painel de administração para adicionar novos tipos de transporte.

Problemas

Claro, houve algumas dificuldades. Desde então, nos recusamos a visualizar a rota na história das viagens. O módulo GPS na trava da bicicleta nem sempre transmite corretamente as coordenadas. E, em vez de uma linha de rota bonita, como em uma cena do Dribble, obtivemos o seguinte:

Aguardando a realidade do VS

Houve um problema na implementação técnica dos mapas do Google no React Native. O marcador no mapa precisa ser constantemente redesenhado para mudar sua posição no mapa. O redesenho de gráficos vetoriais em grandes quantidades não é otimizado e, portanto, com determinadas configurações, tudo ficou muito lento. E decidimos substituir marcadores vetoriais no mapa por marcadores rasterizados em formato png. Isso deu um aumento significativo na velocidade do aplicativo.

Muitas perguntas foram sobre a implementação do sistema tarifário e a assinatura. Tentamos fornecer casos diferentes: o que fazer se a assinatura terminar durante a viagem, se é possível comprar assinaturas diferentes para um tipo de transporte, se vale a pena fazer a renovação automática de assinaturas, como calcular o custo da viagem e assim por diante.

Como resultado, decidimos pela seguinte opção de classificação: o tempo de viagem é dividido em segmentos desiguais e cada intervalo de tempo é cobrado separadamente. Por exemplo, os primeiros 15 minutos da viagem custam € 2, se você pedalar por mais de 15 minutos, mas menos de meia hora, o custo da viagem será de € 3,5, de 30 minutos a uma hora - € 5, etc. E para facilitar a navegação das tarifas pelo usuário, decidimos visualizar o cálculo de custos e o transformamos em uma barra de progresso. Agora o usuário pode ver como o custo da viagem muda em tempo real.

Visualização de custos na forma de barra de progresso

Telas com tarifas e assinaturas

Alguns usuários acharam a opção de não pagar pela viagem: adicionaram um cartão bancário, depois o excluíram e viajaram de graça. Quando descobrimos isso, começamos a bloquear € 1 para verificar nossa solvência e removemos a capacidade de remover o cartão durante a viagem ou se há uma dívida não paga.

Também às vezes havia problemas com a conclusão da viagem. Para concluir o passeio de bicicleta, você precisa fechar a trava, que transfere informações para o servidor. Mas o castelo nem sempre transmitia dados a tempo. E, no final, as pessoas poderiam acumular dívidas de várias centenas de euros para viagens supostamente inacabadas. Decidimos checar grandes quantidades manualmente e remover a gravação automática para eles. Quase não houve queixas, uma vez que na Europa poucas pessoas têm alertas por SMS. Na Rússia, seria diferente.

achados

A parte dianteira

Uma das principais características do desenvolvimento do React Native é o rastreamento do desempenho dos componentes. Para evitar uma diminuição nos fps, vale a pena:

monitore o número de renderizadores (redesenhados). Um componente deve ser redesenhado apenas se os novos dados que chegam realmente precisarem alterar o estado da interface
use animação Animada nativa do pacote React Native padrão usando a chave useNativeDrive na configuração da animação ou o pacote Reanimado
revise o código JS de pacotes ou componentes adicionados ao projeto. Nem todos os pacotes disponíveis podem ser otimizados ou corretamente, usando os recursos do React Native. Também em desenvolvimento no React Native, vale a pena considerar as diferenças de plataformas. O mesmo código no iOS e no Android pode funcionar de maneiras completamente diferentes

A força do React Native pode ser chamada de versatilidade. Não há necessidade de ter duas equipes de desenvolvimento diferentes no iOS e Android. Além disso, com frequência, você pode implementar conceitos de design que são mais difíceis de desenvolver em plataformas nativas.

A fraqueza do React Native não é sua natividade completa. Você deve garantir constantemente que você não sobrecarregará o encadeamento JS. A dor de atualizar e instalar pacotes nativos até a versão 0.60 até o autolinker ser introduzido.

Processo interno

A mudança para o GraphQL na maioria dos casos simplificou o desenvolvimento da API. Tornou-se mais claro para o desenvolvedor e o cliente.

Vantagens do GraphQL:

é possível documentar automaticamente a API e é muito conveniente
permite um trabalho mais flexível com a API. O cliente seleciona apenas os dados de que precisa no momento
suporte imediato para soquetes da Web, o que foi muito importante, pois geralmente atualizamos dados em tempo real
podemos escrever facilmente tipos escalares, se necessário, e reutilizá-los mais tarde

Fraquezas do GraphQL:

mais difícil de fazer recursos por tipo de paginação. Eu tenho que aplicar tecnologias adicionais
Fora da caixa, não há espaço para nome. Você precisa cuidar da separação da API. Ao mesmo tempo, há suporte para campos descontinuados, o que simplifica ainda mais a vida do desenvolvedor
você precisa monitorar os níveis de aninhamento para consultas. Você pode escrever uma solicitação com muitos aninhamentos e aguardar muito tempo por uma resposta

Interface

Ao trabalhar em um redesenho, você deve se lembrar de que não deve fazer design por causa do design. No nosso caso, a nova interface tornou possível simplificar a interação do usuário com o aplicativo, inclusive se uma pessoa segura o telefone com uma mão. Levamos em conta os recursos do React Native e, para reduzir o aninhamento, passamos de um "hambúrguer" para a navegação inferior. Também é necessário estabelecer a possibilidade de dimensionar a estrutura do aplicativo. Criar uma biblioteca de componentes e aplicar o design atômico pode ajudar aqui.

Planejamos introduzir a gamificação (obter bons bônus por quilômetros percorridos), um tema sombrio, conectando-nos a contatos telefônicos e notificando amigos que viajam por perto e introduzindo novos modos de transporte. Mas o mais importante é que o redesenho deve ser justificado: para beneficiar os negócios e simplificar o trabalho com o aplicativo para o usuário.

Redesign de aplicativos - Visão interna