Estudo de impacto de refatoração de listas de telas do Regulariza Já

Data: ~~19/09/~~17/02/22

Autores:

Vinicius da Rosa Pereira
Lucas da Silva Andrade

1. Objetivo

Avaliar e mensurar as alterações necessárias de visualização no Regulariza Já

2. Justificativa

Visto que as listagens repetem dados, como o de município, múltiplas vezes, acreditamos ser confuso para os cidadãos entenderem as listagens

3. Justificativa

Atualmente a listagem de municípios na interface, não é feita pelo ID do município, mas sim pelos IDs dos projetos em execução, onde se houver mais de um projeto em execução por município, faz com que a lista de municípios seja visualizada dessa maneira:

O que acaba acarretando o problema de outra listagem, a de bairros, pois essa traz a lista de bairros dos projetos em execução, então ao duplicar a cidade, duplica também os bairros, trazendo a listagem desta forma:

Na parte de Front-end a listagem das opções é feita da seguinte maneira:

Onde percorre uma lista, com referência em projeto.Id, apresentando o nome do município na option.

Na controller que chama essa view, temos apenas a chamada de um serviço de listagem de projetos em execução:

Onde é feita uma busca, que retorna uma lista de ProjetoEmExecucaoDto, a Model da view mostrada anteriormente. Trazendo junto com as referências dos projetos, os períodos, bairros, ruas, municípios e responsáveis.

Tal listagem é feita nas partes do sistema em que se precisa selecionar o projeto em que o cidadão se enquadra, apresentada então, na parte de dados do imóvel, onde ele realmente faz a solicitação, e também na parte de ver projetos, onde apenas visualiza os projetos em execução.

Uma possível solução, seria a produção de consultas diferentes, como uma consulta que, ao invés de retornar os projetos em execução, retorne os municípios que possuem projetos em execução.

Então ao passar a o retorno da consulta de municípios, como model para a view, teríamos o corpo do <select> como a seguir:

De acordo com a solução proposta, teríamos então a partir daí, a referência do município desejado, e na teoria continuaríamos tendo o mesmo problema.

Imaginando o cenário de 3 projetos no município selecionado, temos o Projeto1 com o bairro A, Projeto2 com bairro A e B, Projeto3 com bairro A, B e C. Nesse cenário o mesmo problema seria recorrente, pois o bairro A se repetiria 3 vezes na option e o bairro B, duas vezes.

Pensando nesse problema, seria válida a criação de mais um tipo de consulta, que agruparia os bairros pelo nome, pois em cada projeto, terão IDs diferentes, então mostraríamos o nome apenas uma vez.

Parece uma boa solução, até chegarmos na seleção de rua, pois a nossa referência seria perdida, trazendo uma inconsistência no projeto em que faço parte, me impedindo de solicitar, ou atrapalhando meu entendimento do sistema.

Uma possível saída para esse problema, seria dar para o cidadão a possibilidade de selecionar o projeto que está disponível no município, e a partir do projeto selecionado, mostrar os bairros, ruas e lotes disponíveis.

O código do <option> ficaria semelhante a esse:

4. Conclusão

Analisando os pontos de impacto no código, podemos concluir que não serão muitos, a maior complexidade seria na construção das novas consultas, mudando as referências atuais, de projeto para município.

Uma das sugestões seria alterar a visualização da tela de “ver projetos” para ajax, mostrando uma interface diferente para o usuário, mais intuitiva, mas ainda apresentando a mesma problemática, a necessidade de selecionar o projeto.

Para que sejam feitas as alterações, será necessário um levantamento com o cliente, para saber se é disponibilizada alguma informação sobre os projetos e convênios, para o usuário, e se caso não seja disponibilizada, se seria uma dor maior, a necessidade de selecionar o convenio, do que a repetição de cidades nas opções.