Interface web

Houve uma preocupação particular com a interface, decorrente da potencial falta de experiência com informática esperada dos usuários finais desse tipo de sistema. Isso se traduziu em uma dose de cuidado extra na elaboração das telas, procurando torná-las tão simples e intuitivas quanto possível.

Vale notar que, ao mesmo tempo em que houve uma preocupação com facilitar a navegação, era de nosso interesse manter também o código HTML reutilizável - de maneira a facilitar a criação das novas páginas e manutenção das antigas. A complicação, neste caso, vem do fato de que nem sempre o layout de uma página é ideal para todos os tipos de dados que se deseja apresentar. A elaboração de um layout padrão não foi, portanto, uma tarefa fácil.

Figura 3: Tela de cadastro de usuários do sistema.

Uma das soluções adotadas - grande facilitadora do desenvolvimento das páginas - foi o controle de layout. Trata-se de uma extensão do Velocity, que está disponível na página do projeto Jakarta. Convencionalmente, um template possui diretivas que indicam inclusões de código de outras páginas (usadas para reutilização de código que são comuns a muitas páginas, como cabeçalho, rodapé e menu). Há porém uma desvantagem que resulta justamente da necessidade de repetir a diretiva em todas as páginas que a utilizam, dificultando dessa maneira futuras alterações. Na solução adotada, por outro lado, o arquivo de template contém apenas o corpo de uma página, que é inserido em uma segunda página (de layout) automaticamente pelo sistema de templates.

Sem a adoção do controle de layout, os arquivos de template (extensão vm) seriam dessa forma:

#include(inc/header.vm)
<div align="center">
<img src="/images/workflow.jpg">
</div>
#include(inc/footer.vm)

A diretiva include, utilizada tanto para os arquivos header.vm quanto para o footer.vm, deveria ser adicionada a todas as páginas do sistema. A função do include é adicionar o código de outros arquivos no arquivo onde a diretiva é utilizada.

Utilizando o controle de layout, a página acima ficaria assim:

<div align="center">
<img src="/images/workflow.jpg">
</div>

Quando a página for requisitada, o sistema de templates ficará encarregado de processá-la, inserindo-a na página de layout, no local da diretiva $screen_content:

#include(inc/header.vm)
$screen_content
#include(inc/footer.vm)

Uma outra dificuldade encontrada no desenho da interface esteve relacionada à montagem de um processo. O objetivo inicial era o de permitir ao usuário montar um processo da forma mais intuitiva possível. Dessa maneira, exigir desse usuário conhecimentos de Redes de Petri coloridas foi algo que nos pareceu, inicialmente, ir em desencontro com a simplicidade buscada. No entanto, encontrar um mapeamento entre um esquema simplificado e uma Rede de Petri que preservasse a expressividade do modelo provou ser um desafio formidável para o qual, infelizmente, não encontramos soluções aceitáveis.

Embora isso possa parecer um problema, notamos que a criação de um processo certamente não é uma tarefa rotineira. Além disso, pressupõe-se que projetistas de processos sejam pessoas razoavelmente qualificadas e, dado que as Redes de Petri coloridas são intuitivas em dose moderada, imaginamos que o custo de simplificar a representação seria maior que o benefício.