Regras e boas práticas de webdesign

De acordo com Preece [3], a usabilidade permite avaliar a qualidade de um sistema em relação aos seguintes critérios:

• Eficácia - Quão bom o sistema é a fazer aquilo a que se destina
• Eficiência - A forma como o sistema ajuda os utilizadores na realização das suas tarefas
• Segurança - Quão protegidos os utilizadores estão contra condições perigosas / situações indesejadas
• Utilidade - Até que ponto o sistema fornece o tipo certo de funcionalidade de modo a que os utilizadores possam fazer o que precisam ou desejam
• Facilidade de aprender - Quão fácil é aprender a interagir com um sistema
• Memorização - Quão é relembrar como utilizar um sistema, após aprendizagem.

De acordo com Nielsen, a Usabilidade é um atributo de qualidade que avalia a facilidade de uso de um interface de utilizador. A palavra “usabilidade” também se refere a métodos para melhorar a facilidade de uso durante o processo de design. A usabilidade é definida por cinco métricas [4] de qualidade:

• Facilidade de aprender: quão fácil é para os utilizadores concluir tarefas simples da primeira vez que encontram esse design?
• Eficiência: assim que os utilizadores tiverem aprendido o design, quão rapidamente conseguem executar tarefas?
• Memorização: quando os utilizadores regressam ao design após um período de não o usarem, quão facilmente conseguem recuperar a habituação?
• Erros: quantos erros é que os utilizadores cometem, quão severos e quão facilmente recuperam dos mesmos?
• Satisfação: quão agradável é usar esse design?

Comparando as duas abordagens, nota-se que são muito idênticas em todos os tópicos. Preece adiciona o critério da segurança para condições perigosas / situações indesejadas e da utilidade do site, enquanto Nielsen fala da satisfação da utilização de um determinado design e dos erros que os utilizadores podem cometer.

Segundo Lazar e Preece [5], a usabilidade está relacionada com a construção de interfaces de utilizador que sejam consistentes, controláveis e previsíveis, tal que sejam adequados e fáceis de usar. Usabilidade e sociabilidade podem construir comunidades digitais prosperantes.

Para melhorar a usabilidade de uma aplicação é necessário que a mesma tenha um interface bem desenhado. As “Oito regras de ouro de design de interfaces” de Shneiderman [6] constituem um bom guia de design para interacção.

A. Esforçar por garantir consistência

“Sequências de acções consistentes devem estar patentes em situações similares; deve usar-se terminologia idêntica em pedidos de informação, menus e écrans de ajuda; e comandos consistentes devem estar em uso por todo o sistema.”

B. Disponibilizar atalhos para utilizadores frequentes

“Com o aumento da frequência de uso, também aumenta o desejo do utilizador de reduzir o número de interações e aumentar a rapidez de cada interação. Abreviações, teclas de função, comandos ocultos e macros poderão ser bastante úteis a utilizadores avançados.”

C. Disponibilize feedback informativo

“Para cada ação do operador, deverá haver alguma resposta do sistema. Para ações mais frequentes ou pouco significativas, a resposta poderá ser discreta enquanto que, para ações mais importantes ou menos frequentes, a reação deve ser mais notória.”

D. Desenhe as janelas de modo a dar sensação de conclusão.

“Sequências de ações deverão ser organizadas em grupos com um início, meio e fim. O feedback informativo apresentado na conclusão de um grupo de ações dá ao utilizador a satisfação de um objetivo concluído, uma sensação de alívio, o aviso para descartar planos de contingência e outras opções da sua mente, e a indicação de que o caminho está livre para o próximo grupo de ações.”

E. Disponibilize uma forma simples de lidar com erros

“Tanto quanto possível, construa o sistema de forma a reduzir as hipóteses de o utilizador cometer um erro grave. Se um erro for cometido, o sistema tem que ser capaz de detetar o erro e disponibilizar mecanismos simples e fáceis de compreender para lidar com esse erro.”

F. Permita reversão fácil de ações

“Esta funcionalidade diminui ansiedade dado que o utilizador sabe que erros podem ser desfeitos, encorajando, dessa forma, exploração de opções pouco comuns.”

G. Ofereça uma sensação de controlo

“Operadores experientes desejam avidamente a sensação de controlarem o sistema e que o sistema responde às suas ações. Desenhe o sistema de forma a que os utilizadores sejam os iniciadores das ações em vez de reagirem.”

H. Reduza a carga sobre a memória de curto prazo

“Os limites de processamento humano que usam memória de curto prazo obrigam a janelas que sejam simples, consolidação de apresentação de múltiplas páginas, redução do número de movimentos de uma janela, e que tempo de treino suficiente seja disponibilizado para a aprendizagem de códigos, mnemónicas e sequências de ações.”

O site analisado neste artigo, seguiu o modelo de Nielsen e foi avaliado segundo as regras deste. Embora sendo um modelo com mais regras é mais simples de compreender e de trabalhar.

Jakob Nielsen escreveu um conjunto de 10 regras [7], que são melhor compreendidas como conselhos, e deverão ser tidas em conta no desenvolvimento de um interface de utilizador:

A. Visibilidade do estado do sistema

“O sistema deve manter o utilizador informado sobre o que se está a passar, através de feedback apropriado, num prazo razoavelmente curto.”

Ao longo de todo o site, existem poucas ou quase nenhumas explicações destinadas a permitir ao utilizador saber onde está, qual a função de certas opções e o que fazer para interagir naquela zona. Este tópico vai de encontro com a terceira regra de Shneiderman, que se refere a disponibilizar feedback informativo.

B. Correspondência entre o sistema e o mundo real

“O sistema deve usar a linguagem do utilizador, aplicando palavras, frases e conceitos familiares ao mesmo, em vez de termos nativos do sistema. Deverá seguir-se as convenções aplicadas no mundo real, dispondo a informação de uma forma lógica e natural.”

Esta segunda regra fala da linguagem utilizada. Conclui-se que o sistema aplica o conceito corretamente. A linguagem utilizada é de fácil compreensão para o utilizador a que se destina apesar de os termos serem, em alguns casos, técnicos. De realçar que este site é para ser utilizador por pessoas de uma área específica e com conhecimento desses termos técnicos.

C. Liberdade e controlo do utilizador

“Os utilizadores frequentemente escolhem funções de sistema por engano e irão necessitar de uma “saída de emergência” para saírem da zona onde chegaram sem terem que seguir um processo complexo. Suporte para desfazer e refazer uma ação é uma boa ideia.”

Caso o utilizador escolha uma opção errada e queira sair basta clicar noutro menu. Contudo não existe nenhum botão que permita ao utilizador voltar à página inicial, ou retroceder sem utilizar o botão existente do próprio browser.

D. Consistência e padrões

“Utilizadores não devem ter que perceber se diferentes palavras, situações ou ações significam o mesmo. É importante seguir-se convenções de plataformas.”

Tal como Nielsen, Shneiderman também sugere uma regra relativamente a este tópico, “esforçar por garantir consistência”. A construção e aplicação de padrões é o método mais fácil para realmente se conseguir garantir essa consistência.

Todos os botões, links ou quaisquer outras formas de aceder a qualquer opção são iguais em todo site. Contudo não foi aplicada nenhuma convenção de plataformas em específico.

E. Prevenção de erros

“Mais importante que boas mensagens de erro, é um design cuidado que em primeiro lugar evite a ocorrência de erros. A política seria eliminar-se condições suscetíveis de erros ou verificá-las e apresentá-las com uma opção de confirmação antes da execução efetiva da ação.”

Tanto Nielsen como Shneiderman (“Disponibilize uma forma simples de lidar com erros”) abordam este tópico da mesma forma. Com o uso da framework utilizada (OWF), a propensão para ocorrência de erros é mais reduzida.

F. Reconhecer em vez de relembrar

“Minimizar a necessidade de o utilizador recorrer à memória ao tornar objeto, ações e opções visíveis. O utilizador não deve ter que relembrar informação de uma parte do diálogo para outra. Instruções para uso do sistema deverão ser visíveis ou fáceis de consultar sempre que apropriado.”

O site não dispõe de informações suficientes direcionadas para o utilizador com o objetivo de melhorar a sua utilização e reduzir tempos de espera relacionados com má utilização.

G. Flexibilidade e uso eficiente

“Aceleradores (invisíveis ao utilizador novato) podem frequentemente tornar mais rápida a interação dos utilizadores mais avançados de tal forma que o sistema pode servir quer utilizadores inexperientes, quer experientes. Deve-se permitir ao utilizador afinar ações frequentes.”

Como sétima regra, não existe qualquer tipo de acelerador implementado no site para melhorar a usabilidade do utilizador.

H. Estética e design minimalista

“Diálogos não deverão conter informação irrelevante ou raramente necessária. Qualquer pedaço de informação a mais numa janela compete com a informação relevante e enfraquece a sua visibilidade relativa.”

O design do interface deste site possui é simples e direto, fornecendo poucos meios de distração. Contudo possui poucas informações para o utilizador.

I. Ajude os utilizadores a reconhecer, diagnosticar e recuperar de erros

“Mensagens de erro devem ser expressas numa linguagem simples (sem códigos) e indicar com exatidão o problema, sugerindo uma solução de forma construtiva.”

Na nona regra é pedido o uso de linguagem simples para as mensagens de erro. Neste momento, o site não possui qualquer tipo de mensagens de erro ou feedback para o utilizador.

J. Ajuda e documentação

“Apesar de ser preferível que o sistema possa ser usado sem documentação, poderá haver situações em é necessário fornecer ajuda e documentação. Qualquer informação deverá ser fácil de pesquisar, focada na lista de tarefas do utilizador, descrever passos concretos a executar e não ser demasiado longa.”

A aplicação desta regra é feita pela existência da secção FAQ’s (“perguntas frequentes”) no site. Esta secção oferece, ao utilizador, informações sobre a página com um conjunto vasto de perguntas e respostas.

Para além destas regras, Nielsen compilou um conjunto de 10 erros [8] típicos específicos do desenvolvimento web. Para melhorar as conclusões deste trabalho, a análise do site também contemplou a verificação da ocorrência desses erros:

A. Má funcionalidade de pesquisa

Motores de pesquisa demasiado literais reduzem a usabilidade de um site pois, na sua maioria, não permitem uma grande variedade de formas de pesquisa. Muitas vezes estes motores de pesquisa não possuem uma forma de prioritizar os resultados, sendo pouco úteis para os utilizadores.

Neste caso em específico, a análise deste erro não é aplicável pois não site não possui um motor de pesquisa. Contudo será um tópico a manter sob vigilância para o caso de no futuro essa função seja implementa.

B. Ficheiros PDF para leitura Online

A utilização de PDFs online quebram a dinâmica de navegação do utilizador. Os PDFs são ideais para quem pretende imprimir. Nielsen indica que navegar PDFs ou imprimi-los a partir do browser é difícil por os browsers não o suportarem nativamente. No entanto, esta parte, hoje em dia, já não se aplica, dado que os browsers evoluíram consideravelmente e conseguem já tratar PDFs nativamente de forma bastante confortável.

No caso deste projeto, o site apresenta vários documentos em PDF, mas como casos específicos. São os documentos fornecidos pelo professor, cuja intenção é realmente serem impressos ou poderem ser guardados consultados off-line, sem dependência do site. Por outro lado, Nielsen indica claramente que os PDFs devem ser reservados para impressão ou para distribuir manuais e outros documentos grandes. Na realidade, é justamente este o propósito da existência de PDFs no site, estando toda a restante informação dinâmica disponível em HTML, embutida no mesmo meio visual que as restantes páginas.

C. Não mudar a cor dos links já visitados

Para os utilizadores, é muito útil saberem que páginas é que já visitaram e as que ainda estão por aceder. Se a opção de mudança de cor do link visitado não estiver implementada, o utilizador perde a noção do que já fez, tendo, por vezes, de revisitar páginas. Pode também ocorrer o oposto, em que o utilizador está à procura de uma localização que já visitou, e não tem forma de filtrar as que ainda não visitou para diminuir o espaço de pesquisa.

Este erro não é cometido no site do RemoteLab. Após um link ter sido acedido, este muda de cor, dando a informação de que aquele link já foi acedido.

D. Texto não percorrível

Os sites não devem possui texto muito pesado a nível de leitura (grandes quantidades de texto corrido). Este tipo de texto torna-se cansativo e desagradável de ler. Para uma melhor experiencia de utilizador, deve-se escrever textos pequenos, utilizar mais listas, palavras-chave e subtítulos.

Neste caso, este tipo de erro não é encontrado. A escrita utilizada no site é curta e de simples leitura. O site não se encontra carregado de texto que leve o utilizador a desistir de o utilizar.

E. Tamanhos fixos das fontes

Nielsen refere que é um erro impedir o utilizador de escolher o tamanho da fonte mais confortável, devendo-se usar tamanhos de letra relativos e não fixos.

No entanto, esta é uma regra a que é difícil fugir, não só por muitas vezes poder desfigurar um design que noutros aspetos estaria usável, como também por várias vezes um tamanho fixo ser necessário para responder a necessidades específicas do tipo de sistema. Este site é um desses casos, em que a necessidade de introduzir elementos de mais baixo nível e de controlo de outros dispositivos remotamente obriga à utilização de, em certos locais, fontes de tamanho fixo.

F. Títulos de página com fraca visibilidade em motores de pesquisa

Nielsen argumenta que os motores de pesquisa são uma das formas mais importantes de descobrir sites e atrair visitantes.

No entanto, apesar de tal ser uma presunção aceitável, no caso deste projeto, essa necessidade não existe. Este site é para ser acedido por uma população explicitamente definida que será informada da sua existência por outros meios (nomeadamente, as cadeiras de redes e o site do ISMAI), e não por elementos externos, pelo que a visibilidade em motores de pesquisa é absolutamente irrelevante.

G. Elementos que pareçam anúncios

Visitantes de um site que tenham alguma experiência de navegação na Internet já se habituaram a alguns elementos que identificam imediatamente (consciente ou inconscientemente) como sendo anúncios. Ter num site elementos importantes mas que apliquem construções ou hábitos de design típicos de anúncios é contraproducente, distraindo o utilizador e levando-o a ignorar informações potencialmente importantes. Dessa forma, é de evitar elementos como banners, certos tipos de animações (nomeadamente, elementos a piscar), e pop-ups.

Não foi aplicado, neste site, nenhum dos conceitos a evitar referidos neste ponto, ainda que, com a evolução do mesmo, seja previsível que, para bem da funcionalidade, a aplicação controlada de pop-ups previsíveis pelo utilizador venha a ser esperada.

H. Violar convenções de design

A consistência é um dos mais poderosos princípios de usabilidade - quando as coisas se comportam da mesma forma, os utilizadores não têm que se preocupar com o que irá acontecer. Eles saberão o que irá acontecer com base nas experiências anteriores. Quanto mais as suas expectativas forem satisfeitas, mais controlo sobre o sistema eles sentirão que têm e mais o apreciarão. Quanto menos o sistema se afastar das reações que o utilizador esperava, mais ele se sentirá inseguro. Nielsen também propõe estas conclusões com base na suposição de que o utilizador médio passará a maioria do seu tempo noutros sites, o que quereria dizer que esse utilizador iria avaliar a sua passagem por um site com base na experiência obtida nos outros e que quaisquer desvios à expectativa formada tornará o site mais difícil de usar e levará o utilizador a abandonar.

Neste caso não só as convenções são mantidas, apesar de a especificidade de certas funcionalidades presentes no site, poderem potencialmente pedir que algumas das convenções sejam tornadas irrelevantes. Em alguns aspetos, é esperado que o site funcione mais como uma aplicação do que como um site típico.

I. Abrir novas janelas de browser

A abertura de uma nova janela do browser é geralmente contraproducente por remover alguma sensação de controlo das mãos do utilizador, nomeadamente, a nível dos botões de retroceder, dado que o utilizador nem sempre tem a hipótese de reparar que uma nova janela foi aberta, ao invés de simplesmente ter avançado para outra ligação.

No caso do RemoteLab, no entanto, todas as ligações que causem a abertura de uma nova janela, estão claramente marcadas como tal, sendo acompanhadas de um símbolo que hoje em dia se tornou já padronizado para essa indicação (um pequeno ícone simbolizando duas janelas sobrepostas). Estando o utilizador à espera que este site siga as convenções a que já se habituou, então certamente saberá interpretar o símbolo apresentado, que não só se tornou difundido mas também apresenta um forte nível de intuitividade.

J. Não responder a questões dos utilizadores

Não responder aos utilizadores caso estes necessitem de ajuda é o mais grave fracasso de um site. Não fornecer as informações os utilizadores procuram ou deixá-las ocultas ou mal posicionadas, pode levar a que os utilizadores abandonem o site e as tarefas que estavam a realizar.

O site tem como objetivo dar todas as informações possíveis aos utilizadores para que a sua utilização seja completamente autónoma e, em caso de alguma dúvida, existe uma secção para perguntas e respostas frequentes, havendo sempre, também, a possibilidade de entrar em contato direto com o professor.

[3] http://www.sharritt.com/CISHCIExam/preece.html#ch1

[4] https://www.nngroup.com/articles/usability-101-introduction-to-usability/

[5] https://www.researchgate.net/profile/Jennifer_Preece/publication/228559621_Social_considerations_in_online_communities_Usability_sociability_and_success_factors/links/543bc55e0cf204cab1db2b58.pdf

[6] http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html

[7] Nielsen, Jakob, 1999, https://www.nngroup.com/articles/ten-usability-heuristics/