‘ - ‘ => O problema não se aplica nesta seção
‘ X ’ => O problema se aplica nesta seção
Quadro 4.2 – Análise no Virtus do critério Prevenção de erros segundo às recomendações de Nielsen
A seguir, será apresentado como se processou a análise do princípio heurístico reconhecimento em vez de memorização (parte n) na interface do Virtus.
n) Reconhecimento em vez de memorização
Segundo Nielsen (2001), definitivamente o usuário não deve ser obrigado a relembrar de uma parte do diálogo para poder dar seqüência à interação.
No mural virtual do Virtus, no entanto, esta recomendação não é atendida.
O usuário que deseja responder uma mensagem do mural tem que se lembrar da mensagem original (Figura 4.53) para poder respondê-la, uma vez que a tela para
inserção da mensagem de resposta (Figura 4.54) não é a mesma da que exibe a mensagem original.
Figura 4.53 – Tela de exibição de últimas mensagens postadas no mural
Figura 4.54 – Tela de inserção de mensagem no mural virtual
Ainda segundo Nielsen (2001), o sistema deve dar ênfase no reconhecimento e preterir que o usuário tenha que relembrar aspectos relativos à interação.
Porém, mais uma vez o conselho de Nielsen não foi seguido pelo Virtus.
Conforme já foi citado anteriormente, nesse sistema existem dois links com mesmo nome (Figura 4.35) e funcionalidades diferentes. Dessa forma, o usuário tem
que estar constantemente se lembrando que o ‘página inicial’ do menu superior indica uma coisa e que o ‘página inicial’ do menu lateral indica outra, caso contrário será levado ao erro.
Conforme foi sugerido anteriormente, uma solução possível para esse problema seria nomear estes links de forma mais sugestiva. O nome do link página inicial’ do menu lateral poderia ser trocado por dados da sala. Já o nome do link página inicial do menu superior ficaria mais sugestivo e intuitivo caso fosse trocado pelo termo sair.
Desta forma, o usuário não precisaria estar a todo momento memorizando a funcionalidade a que cada um destes links se refere, e conseqüentemente, os erros seriam evitados.
A seguir, será apresentado como se processou a análise do princípio heurístico flexibilidade e eficiência de uso (parte o) na interface do Virtus.
o) Flexibilidade e Eficiência de Uso
Segundo Nielsen (2001), o sistema deve fornecer aceleradores que permitam os usuários realizar as tarefas com mais rapidez.
No Virtus, no entanto, essa recomendação é reiteradamente desrespeitada.
Após cadastrar uma sala virtual, por exemplo, o usuário não consegue acessá-la rapidamente. O Virtus solicita ao mesmo que primeiramente faça uma procura pelo ambiente (isto é, pela sala) (Figura 4.55).
Figura 4.55 – Tela de confirmação de criação da sala virtual
Somente depois de encontrá-lo é que o usuário poderá acessá-lo.
Seria bem mais eficiente se o acesso ao ambiente fosse automático, sem a necessidade de busca, pois da forma que está o usuário é obrigado a efetuar pelo menos dois passos a mais (digitar o nome da sala e procurá-lo na lista de resultados da busca) do que o necessário.
O problema mencionado acima pode ser tornar ainda mais grave, quando ele se soma ao fato de não haver paginação no resultado da busca por salas.
A falta de paginação, por sua vez, é um dos grandes responsáveis pela baixa eficiência do Virtus.
Outro fator que dificulta a velocidade da interação para realização das tarefas é a ausência de um sistema de busca por documentos.
Quando se está navegando pela central de documentos, por exemplo, constantemente é necessária a visualização de algum documento específico. O mesmo pode ocorrer quando se está navegando por alguma outra seção da sala virtual. Porém, a opção busca por documento não se faz presente no Virtus.
Esta ausência de um sistema de busca por documentos (somada à falta de paginação) pode ser especialmente desastrosa para os usuários inexperientes, que em casos extremos, são levados a buscar – de forma manual – inúmeros arquivos até encontrar o seu.
Um processo reconhecidamente árduo, ineficiente e altamente custoso.
Ainda segundo Nielsen (2001), aceleradores, invisíveis aos usuários novatos, podem oferecer maior velocidade de interação para os usuários mais experimentados.
No Virtus há diversas formas de prover tais mecanismos de aceleração.
Uma delas seria, por exemplo, disponibilizar botões de edição e de remoção da agenda ao lado de cada uma na área de visualização da agenda de atividades, conforme sugere a figura 4.56.
Com isso, os usuários com o perfil de professor, sobretudo os mais experts teriam outros meios de realizar as tarefas de remoção e edição dos dados da agenda.
Conseqüentemente, o processo de realização dessas tarefas seria efetivamente acelerado.
Figura 4.56 – Sugestão de melhorias na seção agenda de atividades
Outra forma de oferecer atalhos no Virtus seria através da adição de algumas novas funcionalidades ao mural virtual.
A primeira funcionalidade sugerida seria proporcionar ao lado de cada mensagem do mural a opção ‘responder’ (Figura 4.57). Dessa forma, os usuários mais experimentados ganhariam uma opção a mais para poder enviar mensagens ao mural.
Figura 4.57 – Sugestão de melhorias na seção mural virtual
Ainda no mural, outra funcionalidade proposta seria oferecer a opção
‘responder ao autor’ (Figura 4.57). Através dela, o usuário poderia mandar uma mensagem individual diretamente para o email do autor da mensagem.
Com isso, a vida do usuário que enviou a resposta seria facilitada, pois ele não teria que saber obrigatoriamente qual o email do autor, nem ter que utilizar uma forma externa de envio de mensagens eletrônicas.
Para o autor também seria interessante, uma vez que ele poderia acessar a resposta diretamente através de seu webmail, sem necessariamente ter que acessar o Virtus, o que lhe pouparia tempo e esforço.
O Virtus também poderia disponibilizar um atalho que permitisse que o professor pudesse entrar em contato com o aluno diretamente através da área de gerenciamento de sala. Isto porque às vezes o professor quer fazer uma observação ou chamar a atenção do aluno com base no acompanhamento de suas atividades e não pode fazê-lo de forma direta uma vez que o Virtus não oferece tal funcionalidade.
Provendo esta opção, conforme sugere a figura 4.58, o professor poderia acompanhar e interagir com os alunos de forma mais eficiente.
Figura 4.58 – Sugestão de melhorias na seção gerenciamento de sala
A seguir, será apresentado como se processou a análise do princípio heurístico estética e design minimalista (parte p) na interface do Virtus.
p) Estética e Design Minimalista
Segundo Nielsen (2001), quando existem dois componentes que têm exatamente a mesma função, um deles deve ser eliminado.
No Virtus, por sua vez, os já tão citados links página inicial do menu esquerdo e do menu superior (Figura 4.59), embora não tenham as mesmas funções, contrariam a heurística minimalista por possuírem nomes idênticos, e por isso, um deles deveria ser eliminado.
Figura 4.59 – Links página inicial contrariando o design minimalista
Segundo Nielsen (2001), os diálogos não devem conter informação irrelevante ou raramente necessária.
Na área de inserção de arquivos da central de documentos, entretanto, essa recomendação não foi adotada, visto que o campo tipo de arquivo se mostrou redundante, uma vez que, se o usuário já escolhe o arquivo através da opção procurar (Figura 4.60), automaticamente o tipo de arquivo que será armazenado já poderia ser identificado, dessa forma, não havia necessidade de o sistema solicitar através do campo tipo de arquivo que o usuário indique qual a tipologia escolhida.
Figura 4.60 – Redundância do campo tipo de arquivo na central de documentos
A área gerenciamento de sala também apresenta problemas, sobretudo, por possuir uma enorme redundância de links para a função que exibe os detalhes da participação dos alunos (Figura 4.61).
Visando preservar a estética e o design minimalista, todos os links redundantes deveriam ser removidos. Somado a isto, os números ao lado de cada aluno se transformariam em links com a função de exibir os detalhes da participação dos mesmos no ambiente.
Figura 4.61 – Links detalhes em destaque
Ainda segundo Nielsen (2001), qualquer unidade extra de informação em um diálogo compete com unidades relevantes, diminuindo a visibilidade relativa.
Dessa forma, a repetição do termo ‘apagar a informação abaixo’ presente em todas as áreas de remoção (Figura 4.62) de itens do Virtus também se mostrou extremamente redundante, por isso mesmo deveria ter sido evitada.
Figura 4.62 – Redundância do aviso apagar a informação abaixo
A seguir, será apresentado como se processou a análise do princípio heurístico diagnóstico e recuperação de erros (parte q) na interface do Virtus.
q) Diagnóstico e recuperação de erros
Para que os erros possam ser reconhecidos é preciso que o sistema possua uma validação de dados minimamente eficiente.
No Virtus, no entanto, a validação não é adequada. O sistema raramente informa ao usuário quando um campo obrigatório não é preenchido ou quando é preenchido de forma incorreta.
Conforme mostra a seqüência de imagens presentes na figura 4.63, que será apresentada a seguir, o Virtus permite, por exemplo, que o professor insira uma mensagem nula na agenda de atividades (primeira imagem da seqüência), ainda confirma que a mensagem foi recebida com sucesso (imagem dois da seqüência). E para piorar, disponibiliza essa informação ausente (imagem três da seqüência). Mesmo problema apresentado na central de documentos.
Figura 4.63 – Seqüência de imagens na área agenda de atividades evidenciando problemas de validação
Em outras áreas cadastrais (mural virtual, biblioteca de links e lista de participantes), novos problemas foram detectados, visto que durante o cadastro das informações, toda vez que algum dado importante é deixado em branco o usuário se depara com a mensagem “o site não pode exibir a página” (Figura 4.64).
Figura 4.64 – Problema de validação na área de inserção de dados do mural
Este tipo de mensagem pode fazer com que usuários inexperientes fiquem perdidos no sistema.
O problema mencionado acima poderia ter sido resolvido se os desenvolvedores do Virtus tivessem se preocupado com as exceções, informando aos usuários que há a necessidade do preenchimento dos campos obrigatórios.
Outro problema relacionado à validação dos campos no Virtus diz respeito à opção apagar no módulo de edição.
Em todas as áreas que esta opção aparece, o usuário deve escolher qual item deseja apagar. Porém, se ele não escolher, o sistema emite uma mensagem confirmando que o item foi apagado com sucesso (Figura 4.65), mesmo que não tenha sido.
Figura 4.65 – Problema de validação nas áreas de remoção
O sistema deveria informar ao usuário, que este deve selecionar o item a ser apagado e só confirmar que foi apagado caso ele realmente tenha sido removido.
Ainda nas áreas em que a opção apagar aparece, outro problema foi constatado.
Caso o usuário escolha o item que deseja remover e selecione apagar, o sistema não exibe uma mensagem de confirmação para aferir se o usuário está realmente convicto que deseja apagar o item selecionado. Dessa forma, o sistema não consegue evitar que itens importantes sejam removidos acidentalmente.
Apesar de não validar os dados em várias telas, conforme foi explanado acima, os dois próximos exemplos visam mostrar que também existem áreas do ambiente onde a validação ocorre.
Na área de login do professor, por exemplo, o sistema informa quando a senha está incorreta (Figura 4.66).
Figura 4.66 – Validação na área de login do professor
Já na área de cadastro da sala virtual, por sua vez, o sistema informa quando o usuário deixa os campos obrigatórios nulos (Figura 4.67), solicitando o seu preenchimento.
Figura 4.67 – Validação na área de cadastro da sala virtual
Todavia, nesta mesma área, o sistema acaba por não fazer a validação de e-mail (Figura 4.68).
Figura 4.68 – O Virtus não faz validação de e-mail
Assim como a validação de dados, o processo de diagnóstico e recuperação de erros do Virtus também está muito aquém do ideal.
Apesar de Nielsen (2001) aconselhar: “para que os erros possam ser recuperados, isto é, corrigidos, fazem-se necessárias mensagens de erro que utilizem linguagem simples, clara e que sugiram uma maneira de resolvê-lo”. O Virtus, mais uma vez não o obedece, visto que as mensagens de erro neste ambiente praticamente inexistem.
Desta forma, qualquer tentativa de análise de qualidade das mensagens de erro do Virtus, conseqüentemente, de análise de diagnóstico e recuperação de erros, tornar-se-ia superficial.
Sendo assim, pode-se dizer que, no geral, o Virtus praticamente não reconhece os erros, dificilmente os diagnostica e muito raramente os recupera.
A seguir, será apresentado como se processou a análise do princípio heurístico ajuda e documentação (parte r) na interface do Virtus.
r) Ajuda e Documentação
No Virtus não há mecanismo de ajuda (Figura 4.69), propriamente dito, que auxilie o usuário na busca por informações que possam ser prontamente encontradas e que efetivamente o ajude mediante uma série de passos concretos que possam ser facilmente seguidos para concretização das tarefas.
Figura 4.69 – Ausência de help no Virtus
Há, entretanto, um guia do usuário [Barros & Martins, 2007], cujo conteúdo, apesar de ter se mostrado atraente e bem escrito, não atende a real necessidade do usuário, que é ter suas dúvidas sanadas no momento em que elas surgem.
O princípio heurístico apresentado acima (ajuda e documentação) foi o último dos critérios de Nielsen a ser avaliado na análise de usabilidade do Virtus.
A seção seguinte (seção 4.1.3) analisa se as regras de ouro sugeridas por Shneiderman (1998) estão ou não presentes na interface do Virtus.
A apresentação dessas recomendações e sua aplicabilidade no Virtus serão explanadas a seguir.
Recomendação 01: Seqüências consistentes de ações devem ser requeridas em situações similares.
No Virtus, o formato de data em padrão brasileiro (dia/mês/ano) é consistentemente utilizado em todo o sistema (Figura 4.70).
Figura 4.70 – Consistência no uso do formato de data
No entanto, o uso de rótulos indicativos nas mais variadas áreas do sistema não foi consistente. Uma vez que existem áreas em que há rótulo indicativo (Figura 4.3), porém, em outras, não (Figuras 4.4 e 4.5).
Recomendação 02: Terminologias idênticas devem ser usadas em prompts, menus e telas de help
Nos menus do Virtus foram utilizadas terminologias similares. Todavia, não há prompts nem telas de help no sistema.
Recomendação 03: A consistência deve estar presente também no uso das cores, nos layouts, nas fontes de caracteres e na adoção de letras maiúsculas e minúsculas.
As áreas de gerenciamento de sala (Figura 4.71) e de edição de dados da sala (Figura 4.72) utilizam cores de fundo que destoam das utilizadas em todo o sistema. Por questão de padronização seria mais indicado manter o fundo branco.
Figura 4.71 – Área de gerenciamento da sala
Figura 4.72 – Área de edição de dados da sala virtual
Recomendação 04: Exceções como a não exibição de senhas e a confirmação ou não de comandos de remoção devem ser compreensíveis e limitadas
O sistema não confirma comandos de remoção. Essa característica é consistentemente repetida em todas as seções do sistema em que há remoção de itens.
Com isso, caso o usuário apague um arquivo equivocadamente, não terá como recuperá-lo, o que eventualmente pode ocasionar perdas irreparáveis de informação.
A seguir, será apresentado como se processou a análise da regra habilitação de atalhos para usuários freqüentes (parte t) na interface do Virtus.
t) Habilitação de Atalhos para Usuários Freqüentes
Segundo Shneiderman (1998), a disponibilização de teclas de atalho ou de outras formas de acelerar o processo de interação é muito importante para tornar o sistema mais produtivo a usuários experientes.
Ainda segundo ele, é comum usuários freqüentes apreciarem e necessitarem de certas facilidades (abreviações, teclas especiais, comandos escondidos e macros9), que efetivamente aumentam a velocidade da interação.
O quadro 4.3 mostra como se processa a aplicabilidade dessas facilidades no ambiente Virtus.
Quadro 4.3 – Análise no Virtus do critério Habilitação de atalhos segundo às recomendações de Shneiderman
Facilidades Aplicabilidade no Virtus
Abreviações Não há
Teclas especiais Não há
Comandos escondidos Não há
Macros Não há
Pelos dados apresentados acima, constatou-se que o Virtus não oferece nenhuma das facilidades sugeridas por Shneiderman (1998).
Conseqüentemente, o receio e a insatisfação dos usuários mais experts tendem a aumentar, uma vez que terão que lidar com tempos de resposta mais longos que os recomendáveis e atualizações de tela mais lentas que as desejáveis.
A seguir, será apresentado como se processou a análise da regra feedback informativo (parte u) na interface do Virtus.
u)
Feedback Informativo
Segundo Shneiderman (1998), para cada ação do usuário deve haver uma resposta do sistema.
No Virtus, no entanto, nem sempre o sistema fornece resposta ao usuário.
Em alguns casos, o que se pôde notar foi a exibição de respostas (normalmente pouco específicas) oriundas do próprio navegador utilizado pelo usuário, uma vez que o sistema, quem efetivamente deveria provê as respostas necessárias, não o faz.
Na sala de bate-papo, por exemplo, o usuário não consegue acessar o chat. Em contrapartida, o sistema não provê resposta alguma, que indique claramente o porquê do problema.
9 Macros de teclado ou mouse permitem que seqüências curtas de teclas pressionadas ou ações do mouse substituam longas seqüências de comandos, automatizando tarefas repetitivas [Macros, 2007].
Já na área de gerenciamento da sala, o usuário não consegue executar a função desativar sala. Contudo, mais uma vez, o sistema não oferece resposta.
A ausência de feedback em determinadas situações no Virtus faz com que o usuário fique meio perdido sem saber o que está acontecendo, perdendo segurança sobre a execução das tarefas requisitadas, aumentando seu receio e sua desconfiança com o sistema.
Além dos problemas apontados acima, foi observado que durante mais de quatro meses – mais precisamente, entre julho e novembro de 2007 –, o portal do Virtus se manteve fora do ar, sem dar qualquer tipo de aviso ou feedback ao usuário.
Esse problema, além de ter se mostrado extremamente prejudicial a seus usuários, tende a deixá-los inseguros durante futuras novas investidas pelo sistema.
A seguir, será apresentado como se processou a análise da regra diálogos com encerramento evidente (parte v) na interface do Virtus.
v) Diálogos com Encerramento Evidente
Segundo Shneiderman (1998), as seqüências de ações devem ser organizadas em grupos com início, meio e fim bem definidos, com o objetivo de deixar claro para o usuário o que deve ser feito para executar algo e quando uma tarefa está concluída.
Transmitindo-lhe assim uma maior segurança para a realização dos próximos passos.
Ainda segundo Shneiderman (1998), o feedback informativo indicando término de um grupo de ações dá ao operador a satisfação de alcançar o objetivo, um sentido de alívio, o sinal para tirar os planos de contingência e opções da mente, e uma indicação clara para preparar o novo grupo de ações.
Os quadros 4.4, 4.5, 4.6 e 4.7 visam evidenciar – através de um conjunto específico de tarefas do ambiente – como a seqüência de diálogos e ações se processa no Virtus.
Quadro 4.4 – Evidência no encerramento da operação inserir na agenda Tarefa 01 – Inserir informação na agenda de atividades
Início O usuário acessa a área de inserção na agenda de atividades.
Meio O usuário insere os dados solicitados e confirma.
Fim O sistema não valida os dados, porém confirma que a operação
foi realizada com sucesso.
O encerramento é evidente?
Sim
Quadro 4.5 – Evidência no encerramento do inserir dados nulos na agenda Tarefa 02 – Inserir dados nulos na agenda de atividades
Início O usuário acessa a área de inserção na agenda de atividades.
Meio O usuário não insere os dados solicitados e confirma.
Fim O sistema não valida os dados, porém confirma que a operação foi realizada com sucesso.
O encerramento é evidente?
Sim
Quadro 4.6 – Evidência no encerramento da operação apagar na agenda Tarefa 03 – Apagar dados da agenda de atividades
Início O usuário acessa a área de remoção na agenda de atividades.
Meio O usuário seleciona as agendas que deseja remover da sala virtual e confirma.
Fim O sistema não valida os dados, porém confirma que a remoção foi realizada com sucesso.
O encerramento é evidente?
Sim
Quadro 4.7 – Evidência no encerramento do apagar sem selecionar na agenda Tarefa 04 – Apagar dados da agenda de atividades sem selecioná-los
Início O usuário acessa a área de remoção na agenda de atividades.
Meio O usuário não seleciona nenhuma das agendas e confirma.
Fim O sistema não valida os dados, porém confirma que a remoção foi realizada com sucesso.
O encerramento é evidente?
Sim
Analisando os quadros acima, pode-se constatar que apesar de todas as tarefas supra-citadas possuírem um encerramento evidente, isto necessariamente não garante que o processo como um todo se realizou de forma satisfatória.
Uma vez que houve confirmações de que certas operações foram realizadas com sucesso quando na verdade elas efetivamente não se processaram. Isto se deu, sobretudo, devido ao fato da validação de dados do Virtus ser fraca.
A seguir, será exibido mais um conjunto de quadros (Quadro 4.8 a 4.13) – e, tarefas – que almejam aferir como o encadeamento de diálogos se processa neste ambiente.
Quadro 4.8 – Evidência no encerramento da operação inserir na lista de participantes Tarefa 05 – Inserir um usuário na lista de participantes
Início O usuário acessa a área de inserção na lista de participantes.
Meio O usuário insere os dados solicitados e confirma.
Fim O sistema não valida os dados inválidos, porém confirma que a operação foi realizada com sucesso.
O encerramento é evidente?
Sim
Quadro 4.9 – Não evidência no encerramento do inserir dados nulos na lista Tarefa 06 – Inserir dados nulos na lista de participantes
Início O usuário acessa a área de inserção na lista de participantes.
Meio O usuário não insere os dados solicitados e confirma.
Fim O sistema mostra uma tela branca caso o usuário esteja utilizando o browser Mozila Firefox10 ou então, a mensagem ‘O site não pode exibir a página’ caso o navegador seja o Internet Explorer.
O encerramento é evidente?
Não
Quadro 4.10 – Evidência no encerramento da operação apagar usuários da lista Tarefa 07 – Apagar usuários da lista de participantes
Início O usuário acessa a área de remoção na lista de participantes.
Meio O usuário seleciona os participantes que deseja remover da lista e confirma.
Fim O sistema não valida os dados, porém confirma que a remoção foi realizada com sucesso.
O encerramento é evidente?
Sim
Quadro 4.11 – Evidência no encerramento do apagar usuários da lista sem selecionar Tarefa 08 – Apagar usuário da lista de participantes sem selecioná-lo
Início O usuário acessa a área de remoção na lista de participantes.
Meio O usuário não seleciona nenhum dos participantes e confirma.
10 Mozila Firefox é um navegador livre e multi-plataforma desenvolvido pela Mozilla Foundation (em português: Fundação Mozilla) com ajuda de centenas de colaboradores. [Firefox, 2007]