Veja a seguir uma dica de UI/UX para aplicações Web Client do Magic xpa, durante a execução de tarefas mais demoradas. 
O Magic xpa é uma plataforma para criação de soluções para o mundo corporativo.
Seja qual for a personalidade do Magic xpa que esteja usando (Desktop, Enterprise Server, RIA (Mobile) ou Web Client), no final, o foco são soluções de uso corporativo.
E neste tipo de ambiente, claro, tarefas complexas muitas vezes precisam ser executadas. Tarefas que demandam tempo para concluir.
Se você já leu nosso post anterior:
Transferindo Arquivos para o Servidor
Você viu como pegar arquivos locais/da rede e transferir para Magic xpa Server., usando interfaces (UI) Web Client.
Mas transferir arquivos é sempre a parte mais simples do processo. Se ele (arquivo) foi carregado para algum lugar, é quase certo que o motivo disso é porque ele precisa ser processado.
Precisa ser lido, validado, internalizado nas bases de dados, atualizar informações e disparar processos (WorkFlow, SystemFlow, etc…).
Um conjunta de tarefas que podem demandar um tempo maior e “perceptível” ao usuário, para completar.
Tomando como base o exemplo do post acima, e se esta carga de arquivo disparasse rotinas ‘batches‘ para o seu processamento, que demandassem uns 30segs para concluir?
Já é característica do Magic xpa Web Client exibir automaticamente um spinner:
para o usuário, quando seu acesso até o Magic xpa Server está levando alguns segundos e ainda não concluiu.
Mas qual a experiência do usuário se ele ficar 30segs olhando um spinner na tela, sem poder clicar em nada?
Ele sempre terá certeza que está executando algo que vai concluir, ou poderá interpretar que algo “travou” e precisa ser abortado?
Não dá para saber como cada usuário vai reagir, mas se preocupar com este tipo de situação é essencial na fase de design das interfaces. E ajuda a evitar alguns “atendimentos” no futuro.
Se você é um frequentador assíduo do blog Magic Brasil, deve ter lido este nosso outro post um tempo atrás:
Os Desafios do Mundo “Mobile” para os Designers de Aplicações
Embora tenhamos falado à época do “RIA” e “Mobile” no Magic xpa, o enfoque era o mesmo: como não deixar o usuário com a impressão de “interface lenta” ou “interface travada” durante a execução de tarefas que por sua natureza, demandam um pouco mais de tempo par concluir.
Naquela publicação falamos sobre dividir a tarefa em “partes”, e ter um feedback visual ao usuário em cada parte executada/concluída.
*Nota: curiosamente, estas divisões aumentam o tempo total da(s) tarefa(s). Mas na psicologia do usuário, é mais confortável ver três partes de "12", que uma parte de "30".
Agora, vamos usar o mesmo conceito, só que com Web Client.
Vamos partir do pressuposto que podemos quebrar nossa longa tarefa de importar o arquivo recebido em três partes (subtarefas).
Iremos atualizar o usuário sobre a execução e andamento de cada uma destas partes, e ao final, ainda podemos mostrar o tempo total que estes processamentos levaram.
*Nota: Muitas vezes é factível dividir uma rotina longa em rotinas menores, mais curtas. Isso também é "refactoring".
Este projeto exemplo está construído com o Magic xpa 4.7.2 e o Angular 10.
Veja aqui o que é necessário de pré-requisito para executar um projeto Web Client.
Vamos começar criando um programa do tipo Web Client Não Interativo:
Por ser não interativo, ele não permite que o usuário interaja com ele (assim como o RIA Não Interativo), mas ele é executado do lado “client” da aplicação (neste caso, no WebBrowser) e por não ser “batch”, permite que tenha uma tela (interface) definida e exibida. A questão da interface (tela) é crucial neste caso.
Este programa terá 3 parâmetros:
[input] Mensagem Usuario = O texto que queremos exibir ao usuário final da aplicação
[input] Comando = A instrução do que o programa deve executar
[output] Tempo Total = Será atualizado com o tempo total que esta execução levou para completar
A tela dele será do tipo “Overlay“, para ser exibida como uma espécie de popup na página:
E nela teremos apenas um Label, que mostra um conteúdo dinâmico cfe. o parâmetro “Mensagem Usuário” que foi recebido:
Não vamos esquecer de definir que desejamos ver esta tela “aberta“:
Agora, vamos abrir com o VSCode a página HTML gerada para este novo programa. E nela, vamos adicionar um progressbar do Angular, para dar um pouco de movimento à página (além do texto estático que será exibido).
Para tanto, teremos de fazer algumas (4) edições.
Alteração 1
Vamos criar o arquivo “<form magic>.component.css” na mesma pasta dos demais, e incluir algumas informações de CSS3:
::ng-deep .mat-progress-bar-fill::after {
background-color: #9af1e0;
}
::ng-deep .mat-progress-bar-buffer {
background: #05527c;
}
.Label1Class {
align-self: center;
margin-top: 10px;
margin-left: 10px;
}
Alteração 2
Vamos editar o arquivo “<form magic>.component.ts“e adicionar a referência ao nosso CSS criado, além de ajustar algumas características desta tela.
Queremos que a tela não feche se o usuário clicar fora dela, que a barra de títulos não seja exibida, além de mudar o seu tamanho (dimensões):
styleUrls: ['./OperacaoDemorada.component.css']
private static readonly showTitleBar: boolean = false;
private static readonly width: string = "600px";
private static readonly height: string = "60px";
private static readonly shouldCloseOnBackgroundClick = false;
Alteração 3
Vamos editar o arquivo “magic.gen.lib.module.ts” e adicionar (import) a referências aos módulos do Angular que possuem as definições das classes para os objetos progressbar:
import {MatProgressBarModule} from '@angular/material/progress-bar';
MatProgressBarModule,
Alteração 4
E para fechar, editamos o arquivo “<form magic>.component.html“, que já tem toda a interface definida e vinculada com o programa Magic xpa, para adicionar o progressbar:
<mat-progress-bar mode="buffer"></mat-progress-bar>
Estas alterações farão com que sempre que este programa (Web Client Não Interativo) quando chamado, abra uma tela retangular no centro do WebBrowser, com um texto dinâmico e um progressbar, onde o usuário não tem permissão de interagir.
Do lado do Magic xpa , este programa utiliza o parâmetro “Comando” para saber exatamente o que fazer, ou seja, qual programa/tarefa “batch“ deve ser executada no servidor.
Como dividimos nossa tarefa longa em 3 partes, temos aqui 3 opções:
Fechando a estratégia, quando tivermos de executar aquela tarefa mais longa, vamos invocar este programa.
Vamos fazer isso 3x, uma para cada parte (subtarefa), com uma mensagem diferente ao usuário:
Testando tudo
Agora, sempre que o processo longo tiver de ser disparado, o usuário não verá um spinner apenas na sua tela, por 30segs.
Ele verá uma sequência de passos:
Quanto mais “partes” pudermos quebrar uma determinada tarefa, mais fluída será a sua execução diante dos olhos dos usuários, se dermos os devidos feedbacks visuais a ele.
Aquela sensação boa de que a coisa está andando. (●’◡’●)
Baixe deste endereço o projeto exemplo que foi utilizado aqui, e pratique você também.
Para receber os artigos do Blog Magic Brasil em primeira mão no seu email, registre-se aqui