Nesta sessão descrevemos uma compilação dos problemas encontrados nos servidores de predição estudados para a definição deste documento, separados pela Heurística Violada.
1. Visibilidade do status do sistema:
O sistema deve informar para o usuário o tempo que será necessário para predição. O servidor precisa informar ao usuário que a proteína está sendo gerada.
O sistema deve mostrar ao usuário a lista de Jobs.
O sistema deve informar como será o retorno da predição solicitada.
A mensagem de que a sequência da proteína foi enviada deve ser destacada para que o usuário tenha certeza de que submeteu a predição com sucesso.
O resultado da predição deve ser enviado por e-mail. Isso dificulta a utilização do servidor como parte de um workflow. O ideal seria oferecer uma página com os resultados que pode ser lida em tempos e tempos para determinar se a predição foi concluída.
A parte de registro no site não fica disponível até a hora da submissão da sequência. Isto deveria estar disponível na interface de uma forma mais evidente.
2. Compatibilidade entre sistema e mundo real:
A maioria das páginas não possuem botões ou ícones simbolizando ações familiares ao usuário como botão voltar, avançar, home, salvar etc., simbolizando ações familiares ao usuário.
Orientador: Prof. Dr. Osmar Norberto de Souza
Página 180 Última Atualização: 05/11/2014
Em uma situação real, o usuário pode desejar realizar mais de uma predição, o que não é permitido. Isso torna os sistemas limitados. No que se refere a sistemas, no mundo real espera-se que eles agilizem os serviços.
Excesso de menu e de informações, sem categorização. Isso atrapalha o usuário a focar-se na predição. 3. Controle e liberdade para o usuário:
Os sistemas não apresentarem botões de avançar, voltar, undo, redo (desfazer e refazer) dentre outros (se apresentam não são padronizados, os atalhos acontecem somente em algumas telas da interface). A maioria dos botões eram somente aqueles apresentados pelo navegador.
Há perca de dados de formulários quando ocorre um erro quando o usuário clica em botão voltar.
O usuário não consegue trocar a senha cadastrada, ou o modificar seu cadastro. Deve se dar a opção do mesmo poder modificar os dados cadastrados.
O sistema deve ser uma opção de sair do sistema (logon).
Mensagens de aviso ao usuário realizar uma ação devem ser priorizadas, a fim de evitar erros. Exemplo o botão “cleam form” ao ser pressionado deve pedir uma confirmação ao usuário, pois o mesmo apaga as informações digitadas pelo usuário.
4. Consistência e padrões:
As mensagens de erro não seguem um padrão. Algumas abrem em uma nova janela do navegador, em formato de texto, sem botões para conformação ou retornar ao estado anterior. As mensagens deveriam aparecer na mesma tela que ocorreu o erro, como padrão em qualquer sistema operacional.
Faltam botões ou botões com funções muito diferente são muito similares.
Os menus das interfaces não são únicos, padronizados, possuindo vários formatos, localização diferente conforme se percorre a interface. Manter um menu padrão durante toda interface.
Campos obrigatórios poderiam utilizar a simbologia usual que indica campo deste tipo. Isso agiliza a utilização por parte do usuário. Em algumas telas mensagens de usuário é incluindo links de navegação e outras não. Comportamentos diferentes para mesmas ações. Definir um padrão do que é necessário o usuário informar previamente para submissão de seu job. Por vezes é atrelada a conferência do e-mail, outras, que falta a senha, outras relacionadas a sequência informada.
Os campos obrigatórios devem ser sinalizados. 5. Prevenção de erros:
Os sistemas pedem a entrada no formato FASTA. Porém testes foram realizados em outros formatos, e mesmo assim o sistema aceitou ou a submissão ou o carregamento de um arquivo não compatível.
Mesmo com a sequência da proteína errada, o sistema está mais preocupado com a testagem do e-mail do que a submissão correta. Não há mensagens de erro ao se colar uma sequência de proteína no formato errado.
O sistema deve ter que realizar o login para poder enviar a predição, ou avisar o usuário previamente do mesmo antes de utilizar a ferramenta. Muitos erros aconteceram por causa do login do usuário.
O sistema deve dar ao usuário a escolha do tipo de predição da estrutura, modificando parâmetros de entrada. Há servidor que apresenta essa possibilidade, porém a funcionalidade ou está desabilitada ou não funciona.
Quando o sistema pedir uma senha para cadastro, o sistema deverá utilizar para quando o usuário quiser logar no sistema. Houve caso de que a senha cadastrada não foi utilizada em nenhum caso.
O cadastro do usuário deve ser único para todo sistema (erros ocorreram como, por exemplo, o usuário tinha um cadastro para enviar a predição e outro para participar do fórum de discussão.
Os avaliadores acham que o fato de que o sistema só aceita e-mail acadêmico não é uma boa forma de controlar o uso do sistema. Ocorreram testes com e-mails não acadêmicos onde o sistema aceitou o login, outros que aceitou e-mails não existentes (como [email protected]). A mudança nas permissões de e-mail poderá permitir que o sistema fosse aberto a outros estudantes ou professores, sendo utilizado também como ferramenta educativa.
Orientador: Prof. Dr. Osmar Norberto de Souza
Página 181 Última Atualização: 05/11/2014
Ao preencher o campo correspondente a sequência de forma indevida, o servidor deveria verificar o tamanho e a formatação da mesma e indicar a irregularidade. Isto só é feito depois de enviar a submissão.
As mensagens de erro devem ser apresentadas em destaque, no formato padrão (janelinha), na mesma janela, junto ao erro. O que ocorre muitas vezes é uma mensagem em vermelho, mas que pode ser confundida com outras mensagens de destaque na página.
6. Reconhecimento em lugar de lembrança:
Não há um caminho demarcado para saber onde o usuário se encontra em determinado momento.
Alguns menus apresentados com algumas funcionalidades como “Fragment libraries” ou Structure Prediction não tem explicações como são implementadas essas funcionalidades ou documentação adequada. O usuário pode não reconhecer o que significa ou a parte que ele está na interface.
Alguns termos têm links associados, mas é necessário abrir outra página para uma explicação de seu significado. Melhor seria ter uma ajuda rápida ao passar o mouse, ou símbolo de ajuda que explicasse o dado em uma linha.
7. Flexibilidade e eficiência de uso:
Somente usuários cadastrados podem utilizar dos sistemas.
O servidor solicita que o usuário apague seus Jobs depois de serem completados, de uma forma de economizar espaço em disco. No entanto apagar uma job é um processo composto por um conjunto de ações. Isto deveria ser uma ação única do sistema, integrada ao sistema de Jobs.
O usuário deve ter a opção de cancelar a predição enviada, pois muitos servidores só aceitam uma predição por usuário. O sistema não permite customização do processo submetido. Não fazendo a distinção entre usuários experientes e inexperientes. 8. Design estético e minimalista:
É utilizado muito texto para repassar informações aos usuários, geralmente diferenciados somente por títulos. Não há uma padronização nas telas, ficando o conteúdo confuso e com muita informação reunida. Priorizar o uso de atalhos, botões, mensagem, distribuição das informações de acordo com interesse do usuário, reunidas em blocos ou novas telas.
Menu com as opções de acesso as páginas, e junto ações para serem executadas pelo usuário. Isso polui bastante a interface. Opções poderiam ser mostradas somente quando clicado ou quando o ponteiro do mouse fosse colocado sobre itens.
Há informações em vermelho no meio do texto. Apesar de serem importantes, avisos poderiam ser apresentadas de outra forma, para não distrair os usuários.
9. Auxiliar os usuários a reconhecer, diagnosticar e recuperar erros: Possibilitar ao usuário a recuperação de senha, nome de usuário. Identificar se o usuário já é um usuário cadastrado no sistema.
Padronizar os avisos de erros. Os erros aparecem em diferentes formas na interface, em outras janelas, ou em formato texto igual ao de outras informações, como campos obrigatórios.
Em caso de erros não há a possibilidade de se voltar a o estado inicial.
Os erros não apresentam cores ou símbolos diferenciados a fim de chamar atenção do usuário.
Novamente a predição enviada deve ter a possibilidade de cancelamento. Em uma avaliação o usuário enviou uma submissão errada, além do sistema não detectar, ainda o usuário não conseguiu enviar outra até que essa fosse processada.
10. Ajuda e documentação:
A documentação dos arquivos de entrada e saída é muito superficial e em formato .txt, o que dificulta o foco somente em que tem interesse em configurar e visualizar.
Falta esclarecimento ao usuário o do porquê utilizar e-mail acadêmico e/ou que se pode enviar só um job por vez na documentação. Poderia haver uma ajuda contextual, para cada campo de entrada.
Orientador: Prof. Dr. Osmar Norberto de Souza
Página 182 Última Atualização: 05/11/2014
Os parâmetros apresentados nos resultados devem ser explicados, através de links e documentação adequada. Há muitos parâmetros como o que significa E ou H na predição da estrutura secundária, ou o que significa SignalP, C-Score, S-Score ou Y-Score, ou do parâmetro TM.
Sugestões
Este documento está em sua versão 1.0. Ao desenvolvimento desta pesquisa, novas funcionalidades poderão ser adicionadas ao conteúdo aqui descrito.