Boas práticas na web e linhas de orientação

Introdução

Existe um conjunto de princípios consolidados, ou seja, de boas práticas no desenho de formulários web — a base de aplicações transacionais como as que desenvolvemos na Fundação para a Ciência e Tecnologia — que tem um impacto positivo na usabilidade e eficácia destas aplicações. A síntese destes princípios foi complementada com um trabalho de análise de dois portais (Concurso de Bolsas e Portal de Ciência e Tecnologia) e das suas aplicações mais importantes, possibilitando a identificação dos principais problemas existentes e a criação de linhas de orientação que permitam resolver ou mitigar esses problemas. Como qualquer outra parte do "Guia de Estilos" esta secção deverá ser progressivamente atualizada com conteúdos pertinentes.

Organização de formulários

Um dos princípios básicos para melhorar a experiência de utilização é solicitar apenas dados ou colocar questões que sejam essenciais. Ou seja, devemos encontrar soluções para reduzir o número de campos e, consequentemente, os dados a introduzir e o tempo dispensado para completar o formulário. As questões, ou etiquetas (labels), devem ser as mais sucintas e claras possíveis utilizando linguagem natural e um estilo consistente, independentemente do interlocutor ou unidade na estrutura organizacional de onde é proveniente.

E quais são as melhores formas de organização de um formulário? Esta é uma questão que naturalmente surgirá aos stakeholders e developers que estejam envolvidos no desenho de formulários para uma aplicação FCT.

Naturalmente, a resposta depende de alguns factores:

  1. Num formulário estabelece-se uma espécie de “conversação” com o utilizador que pode ser curta ou extensa consoante o contexto. Nos formulários extensos essa “conversação” abarca tópicos ou subtópicos diferentes, ou seja, informação que se pode organizar e agrupar;
  2. Se um formulário tiver uma estrutura que compreende poucos tópicos, é aconselhável utilizar apenas uma única página ao invés da segmentação em várias páginas;
  3. Quando o formulário compreende um amplo conjunto de questões que estão relacionadas com tópicos diferentes, deve-se optar por uma divisão em diversas páginas;
  4. Por fim, utilizar apenas uma página quando o formulário contém um conjunto de questões relacionadas com um único tópico.

Em alguns formulários, ou especificamente em determinadas secções de um formulário, pode surgir um grupo de questões que têm que ser colocadas simultaneamente, de forma sequencial, no sentido de terminar uma tarefa (exemplos: formulário de registo, de pagamento, etc.), noutros casos, o preenchimento pode ser não sequencial.

Hierarquia visual

Além da organização das aplicações em uma ou várias páginas, é importante realçar o papel de uma boa hierarquia visual na organização das várias secções dentro de uma página. As páginas de uma aplicação devem ter uma estrutura bem identificada através de grupos constituídos por campos relacionados e organizados numa sequência lógica que facilite a orientação e fluxo de realização da tarefa.

O uso correto de cabeçalhos e de espaço branco pode ser, geralmente, uma boa solução para facilitar a compreensão do utilizador sobre as relações entre elementos e a definição de clusters ou grupos. Sumariamente:

  • Identificação e espaços das secções bem definidos;
  • Criar hierarquia visual na página;
  • A disposição dos campos de um formulário deve ter um racional e uma lógica estabelecida;
  • Em caso de dúvida no uso de tamanhos de campos, recorrer sempre aos padrões e normas do guia de estilos;
  • O espaço branco permite organizar e dividir, é muito importante utilizá-lo de forma consistente;
  • Garantir que estes princípios são aplicados e não desvirtuados com a introdução de outros elementos. Trata-se de um exercício de simplificação.
Internacionalização

Na generalidade as diferentes plataformas da FCT, das mais antigas às mais recentes, não estão devidamente preparadas em termos de arquitetura e interface para suportar a internacionalização. Curiosamente o site institucional, pela sua simplicidade técnica, é o único que providência uma solução simples e com menos impacto na usabilidade.

Todas as aplicações web não têm uma arquitetura que permita disponibilizar uma boa solução para ter a interface em mais do que uma língua. Todavia, o esforço de desenvolvimento necessário para colmatar essa lacuna é, neste momento, demasiado alto.

Dessa forma a opção passa por tentar, junto dos clientes internos, definir a utilização de uma única língua em conformidade com as necessidades de comunicação com o público-alvo. Está longe de ser uma solução perfeita, mas é um compromisso razoável e uma opção significativamente mais sensata do que disponibilizar nos elementos de interface mais do que uma língua em simultâneo.

Caminho para a conclusão

Numa página o “caminho para a conclusão”, ou seja, para o progressivo preenchimento e submissão dos dados deve ser claro. A utilização de alinhamento visual, sobretudo se não existir “ruído” resultante da introdução de elementos que quebrem esse alinhamento, é um auxiliar precioso.

Como é possível verificar, olhando para a Fig. 1, a linha de visualização num eixo vertical guia o olhar dos utilizadores. A ausência de pontos periféricos com um forte apelo visual ajuda a minimizar as distrações.

[Figura 1] Mapa de calor num estudo de eye-tracking que mostra o caminho para a conclusão.
Fig. 1 - Fonte: WROBLEWSKI, Luke, Web Form Design (2008)

Caso o preenchimento de um formulário tenha alguns requisitos, ou seja, caso esteja dependente do utilizador obter ou reunir determinada informação, estes devem ser enunciados na página inicial do formulário.

Em formulários com múltiplas páginas recomenda-se a utilização de indicadores de posição, estado e progresso. No desenho do layout do formulário é importante ter em consideração o comportamento de tabulação — utilizando na implementação front-end o atributo 'tabindex’ —, e as expectativas sobre o comportamento da tabulação por parte dos utilizadores sobretudo na adoção de layouts com multi-coluna.

Assim, nas aplicações web da FCT deve-se:

  • Ajustar a dimensão dos campos à quantidade de informação a inserir;
  • Colocar a label ou etiquetas no topo de um campo com um alinhamento à esquerda;
  • Utilizar 2 campos na mesma linha apenas quando existe uma relação entre os mesmos;
  • Evitar a utilização de mais do que dois campos na mesma linha;
  • Utilizar tabindex de modo a garantir que a ordem de preenchimento é a correta;

Alinhamento das etiquetas (labels)

O alinhamento das etiquetas no topo, conforme se recomenda aqui no "Guia", apresenta algumas vantagens face a outras alternativas de alinhamento (etiquetas alinhadas à esquerda ou à direita). A saber:

  • Minimiza o tempo de preenchimento;
  • Facilita a internacionalização (i18n) da interface;
  • Privilegia a acessibilidade por apresentar a ordem lógica de etiqueta/campo;
  • Adaptação mais fácil a plataformas móveis, por não exigir tanto espaço horizontal;
  • Melhor suporte para múltiplas resoluções.

A grande desvantagem é a maior ocupação de espaço vertical. Esta questão acaba por não ser muito preocupante uma vez que a maioria dos estudos indica que os utilizadores não se importam de fazer scroll.

Ajuda ao preenchimento

Pontualmente, será útil ou mesmo necessário providenciar ao utilizador alguma ajuda contextual. A introdução de ajuda deverá ser a exceção e não a regra. Ou seja, se os formulários das aplicações FCT não prescindem de uma ajuda constante talvez seja profícuo reflectir sobre uma questão importante — será que a abordagem à concepção do formulário segue a melhor estratégia? É possível introduzir melhorias na interface de modo a melhorar a compreensão do utilizador?

Actualmente em algumas aplicações web FCT existem páginas que apresentam problemas na apresentação de texto de ajuda e/ou informações pertinentes para o preenchimento dos formulários. Existem vários casos em que se utilizam as tooltips para colocar alguns textos extensos, afectando negativamente a legibilidade dos mesmos.

Tipologia de soluções de ajuda

Na verdade, não existe uma estratégia clara para lidar com esta questão. Assim, começamos precisamente por identificar e distinguir os diferentes tipos de ajuda de que os utilizadores necessitam:

  1. Esclarecer o utilizador sobre o significado de um termo, acrónimo ou símbolo menos familiar;
  2. Facultar instruções úteis no preenchimento de um determinado campo;
  3. Providenciar um texto informativo quando o tema ou tópico abordado é complexo e necessita de contexto adicional.

Para o ponto 1, pensamos que a solução mais interessante passa pela utilização do componente tooltip. O componente tooltip já existe na nossa biblioteca de front-end e é particularmente adequada para resolver este tipo de problemas. A solução proposta compreende as seguintes variações (Fig. 2):

[Figura 2]
Fig. 2 - Trigger para activar tooltip (esclarecimento sucinto de um termo ou acronónimo).

No ponto 2 a ajuda contextual é disponibilizada inline num posicionamento adjacente ao campo a que se refere. A frase deve ser concisa, incisiva e providenciar informação que coadjuva o preenchimento (Fig. 3).

[Figura 3]
Fig. 3 — Informação auxiliar que aparece debaixo do campo do formulário utilizando a tag small.

Por último, a solução para o ponto 3 reside em criar um equilíbrio entre a apresentação de um texto no fluxo de preenchimento sem ser particularmente intrusivo e acrescentar densidade. A opção passa pela adoção da noção de progressive disclosure em que o utilizador optar por mostrar ou ocultar a informação consoante a sua necessidade (Fig. 4).

[Figura 4]
Fig. 4 — Utilização de progressive disclosure para textos informativos mais extensivos. A utilização deste método permite manter a página com menos elementos e por conseguinte menos densa conferindo, ainda assim, ao utilizador a possibilidade de ter a informação que pretende consultar sempre disponível.

O texto encontra-se oculto por defeito e é exibido quando o utilizador clica em INFO, voltando a colapsar após um novo clique. Acreditamos que o custo de interação não é elevado e que a experiência de utilização sai beneficiada pelo maior controlo do utilizador.

Qualidade dos textos de apoio

Na análise a algumas das maiores aplicações do Portal de Ciência e Tecnologia (PCT) encontramos textos informativos onde não existe uma uniformidade no estilo e, por vezes, falta alguma objetividade e capacidade de síntese.

Embora a Divisão de Serviços Informáticos não seja a área responsável pela comunicação pode eventualmente:

  1. Sensibilizar outras unidades organizacionais com competências nesta área, como é o caso do Gabinete de Comunicação, para a existência do problema;
  2. Propor um conjunto de diretrizes a adoptar que ajudem a mitigar esta problemática.

Temos indicações que o Gabinete de Comunicação fará os possíveis para colaborar com a DSI no sentido de desenvolver ações de formação sobre escrita na web e, se necessário, participar através da revisão dos textos.

É importante colocar algum enfoque na qualidade e homogeneização estílistica dos conteúdos, assegurando que são adequados ao canal web. Esta não é certamente uma competência exigível a um developer ou um designer, mas existe um conjunto de diretrizes cuja adoção podemos incentivar:

  • A escrita deve ser séria, mas não pomposa;
  • O estilo de escrita não deve transmitir emoções;
  • Os conteúdos textuais devem ser escritos num português e/ou inglês claro, sem utilização de jargão técnico que é pouco familiar aos destinatários;
  • A escrita deve ser incisiva e evitar frases longas. O conteúdo torna-se mais fácil de ler e percorrer naquilo que normalmente se designa por "leitura diagonal";
  • A maioria dos utilizadores num contexto web são motivados e/ou orientados à concretização de objectivos, o que faz com que os utilizadores mais interactivos leiam poucas palavras e revelem alguma impaciência, procurando sempre passar para a página seguinte ou concluir a tarefa em questão;
  • Quando fazemos referência a números devemos evitar colocá-los por extenso porque demoram sempre mais tempo a ser processados cognitivamente.

Tamanhos, grupos e campos obrigatórios

O tamanho dos vários campos de um formulário influência a percepção do utilizador sobre a quantidade de informação que pode introduzir. O sistema a implementar nas nossas aplicações garante flexibilidade e pontos de “ancoragem” à grelha de modo a garantir menos volatilidade no alinhamento dos campos.

No processo de passagem de uma fase de desenho à implementação é imperativo a equipa certificar-se de que o tamanho do campo é suficiente para o conteúdo a introduzir.

Os grupos de campos conferem estrutura ao formulário e permitem uma “leitura” rápida das páginas. Um grupo é essencialmente formado por um conjunto de campos que se encontram logicamente relacionados, sendo utilizado um cabeçalho e espaço branco (ou espaço negativo) para delimitar visualmente cada grupo e ao mesmo tempo contribuir com visibilidade à sua posição na hierarquia visual da página.

A indicação de obrigatoriedade de preenchimento é um tema recorrente e onde se nota, porventura, alguma falta de bom senso. Não é invulgar encontrarmos formulários com todos os campos assinalados como obrigatórios. Nesses casos a melhor estratégia é informar o utilizador no início do formulário de que todos os campos são de preenchimento obrigatório ao invés de assinalar cada campo com um asterisco ou qualquer outro tipo de marcador gráfico.

No que diz respeito à indicação de campos obrigatórios ou opcionais, as regras a adoptar devem ser as seguintes:

  • Se a maioria dos campos no formulário são obrigatórios, deve-se assinalar os campos opcionais;
  • Se a maioria dos campos no formulário são opcionais, deve-se assinalar os campos obrigatórios;
  • Em ambos os casos, o indicador deve estar associado às etiquetas e não aos campos.

Valores por defeito, máscaras de input e blank state

Em alguns casos, é exequível diminuir o número de decisões e de inputs do utilizador fazendo uso de valores por defeito (smart defaults), ou seja, ter alguns campos de um formulário pré-preenchidos com dados ou seleções, acelerando o preenchimento e a conclusão do mesmo formulário. Uma utilização conscienciosa de valores por defeito pressupõe algum conhecimento (que pode ser obtido através da análise de logs ou analytics) sobre o universo de utilizadores, o seu intuito e/ou contingências impostas num determinado domínio de negócio.

[Figura 5] Escolha de smart defaults numa aplicação de marcação de passagens aéreas.
Fig. 5 - Exemplo de um valor por defeito "inteligente" numa aplicação de marcação de passagens aéreas.
Máscaras de input

Dependendo da aplicação podem existir casos em que é necessário a entrada de dados estruturados de acordo com um determinado formato. Os exemplos clássicos são os formatos de data ou, por exemplo, no comércio eletrônico do número de cartão de crédito.

Quando existe a necessidade de obter dados com uma determinada estrutura é aconselhável utilizar técnicas que permitam minimizar o erro.

Uma das abordagens, com maior esforço de engenharia, seria incrementar a tolerância de formato, ou seja, aceitando que os dados pretendidos fossem introduzidos numa série de formatos. Outra abordagem seria a utilização de máscaras de input.

O formato da máscara deve ser visível desde o início e coerente com o processo de entrada de dados. Se os dados introduzidos assumem um formato visualmente diferente daquele que é indicado na máscara, é natural que o utilizador fique confuso.

Por outro lado, a máscara pode inclusivamente ser restritiva e não permitir a inserção de um determinado conjunto de caracteres que não fazem parte dos dados a introduzir (ex: uma máscara de um campo numérico pode inibir a introdução de dados alfabéticos).

Blank state

Tipicamente, na maioria dos projectos, os designers e developers estão preocupados com a introdução de dados, negligenciando de forma não intencional o desenho da interface quando ainda não existem dados introduzidos (blank state). No PCT existem algumas secções de formulários em que:

  1. É expectável a introdução, por parte do utilizador, de um determinado conjunto de dados e a forma como providenciamos essa informação ao utilizador é através da repetição de uma mensagem irrelevante (i.e., "empty slot");
  2. É visível no ecrã uma parte do componente da interface utilizado — como, por exemplo, o cabeçalho de uma tabela — embora, como ainda não exista dados introduzidos, o componente esteja vazio.

Ambas as opções preconizam uma abordagem errada ao estado vazio. No primeiro caso, em vez de tornar visível na interface a falta de informação uma mensagem com um "contador" dinâmico seria tão ou mais eficaz. No segundo caso, o componente ou parte do componente não devia ser visualizável se ainda não existem dados uma vez que as opções de interface utilizadas para apresentar determinada informação são irrelevantes para o utilizador final, sendo preferível existir uma mensagem que indique explicitamente que ainda não foi introduzida qualquer informação neste campo.

Ações primárias e secundárias

Tal como nas aplicações de desktop em que o utilizador é chamado, no âmbito de uma determinada interação com o sistema, a confirmar (ação primária) ou cancelar (ação secundária) uma tarefa em curso, nas aplicações web também são as ações que permitem o desfecho de um formulário.

Assim, denominam-se como primárias todas as ações que contribuem para a conclusão do preenchimento (ex: “guardar”, “continuar”, etc.) e como secundárias todas as outras opções — as ações secundárias típicas permitem “retroceder”, “voltar ao início” ou “cancelar” de modo a corrigir determinadas opções.

Uma vez que as ações secundárias têm, não raras vezes, consequências no progresso do utilizador é crucial garantir que existe uma distinção visual entre ações primárias e ações secundárias. A distinção e o menor ênfase visual dado às ações secundárias têm como objectivo diminuir o número de potenciais erros.

É, igualmente, uma boa prática posicionar as ações primárias no alinhamento dos campos de input de modo a reforçar um claro “caminho para a conclusão”.

[Figura 6] Exemplo da distinção visual entre uma ação primária e secundária.
Fig. 6 - Exemplo da distinção visual entre uma ação primária e secundária.

Notificações de erro e sucesso

No guia de estilos existe uma tipologia de notificações para quatro situações específicas:

  • Uma notificação de erro quando ocorre um erro porque o utilizador não inseriu um ou mais dados que o sistema não aceita (ex: má combinação de utilizador/palavra-chave);
  • Uma notificação de sucesso quando existe, por exemplo, um “envio” de dados bem sucedido e é importante confirmar que a operação efectuada com êxito;
  • Uma notificação de aviso quando existem determinados dados cuja coerência ou acuidade é duvidosa, mas que não são impeditivos de concluir um determinado processo ou operação;
  • Uma notificação de informação que veicula informações importantes para a actividade do utilizador.

Nesta secção vamos sobretudo abordar as duas primeiras, sendo as mais comuns e basilares no feedback de qualquer sistema.

Os tópicos anteriores abordam medidas e boas práticas para tornar o desenho de formulários mais eficiente, com resultados positivos na usabilidade e facilidade de utilização. De certa forma, são práticas “preventivas” em relação ao erro, no entanto, por mais robusto que seja o sistema e se tenha em conta os principais cenários de utilização, é impossível eliminar totalmente o erro humano.

[Figura 7] Indicação visual da ocorrência de um erro.
Fig. 7 - Indicação visual da ocorrência de um erro numa validação por página.

Quando ocorre um erro é fundamental que o utilizador tenha conhecimento dessa ocorrência. Dessa forma, a prioridade é comunicar claramente que ocorreu um erro usando uma mensagem visual com forte contraste que é persistente até ser explicitamente fechada pelo utilizador (Fig. 7).

Normalmente as equipas atribuem importância à identificação visual do erro, mas subvalorizam a mensagem escrita. Os conteúdos textuais têm de ser vistos como uma parte relevante da interface sendo imperativo ter algum cuidado na sua redação. Assinalamos de seguida alguns aspectos relevantes:

  • ser explícito, sucinto e com relevância semântica (utilidade);
  • não conter erros de ortografia, sintaxe ou construção gramática;
  • ser coerente com o estilo de comunicação escrita de toda a aplicação;

Assinalar o erro é insuficiente. É necessário informar o utilizador sobre o tipo de erro, onde é que este se encontra e, finalmente, facultar informação accionável que o permita corrigir. O texto das mensagens deve utilizar a linguagem natural e não mensagens crípticas decorrentes do modelo de implementação.

Podem, como é óbvio, ocorrer vários erros sendo que todos os campos envolvidos devem ser assinalados utilizando a mesma linguagem visual.

A maioria dos formulários nas aplicações da FCT são longos, com múltiplas páginas e um quadro de validação final de erros. Nesses casos, quando não existe uma validação por página, a indicação dos erros existentes e a localização no formulário é normalmente deficiente — a usabilidade melhoraria significativamente se a indicação do campo com erro tivesse um hyperlink, permitindo ao utilizador ir directamente para o campo em questão. Uma validação por página, em campos preenchidos, permitiria minimizar os erros que transitam por validação final ao mesmo tempo que seria significativamente mais fácil providenciar uma indicação indiviual do(s) campo(s) envolvido no erro.

E quanto ao sucesso? É inútil notificar o utilizador sobre o sucesso de cada interação com o sistema. Contudo, todas as operações que envolvam introdução, alteração ou remoção de dados devem providenciar um feedback claro e dissipar qualquer dúvida sobre se operação foi efetivamente realizada.

Layout e linguagem visual

A linguagem visual tem influência na clareza da interface, na leitura, na usabilidade e na capacidade de orientar o utilizador para a concretização de uma determinada tarefa. Todos estes factores influenciam objectiva e subjectivamente a experiência de utilização.

Tendo em conta esta perspectiva, não é difícil perceber que o último redesign do PCT demonstra uma excessiva preocupação com a "personalidade" visual e falha no apoio ao design de interação e arquitectura de informação. Nos outros portais em análise existam também diversas fragilidades, mas o fundamental é salientar que não existe actualmente um estilo coeso e um vocabulário visual comum a todo o universo de aplicações web da FCT.

A linguagem visual proposta no âmbito da elaboração deste guia de estilos procura resolver a excessiva densidade gráfica aplicada nos elementos e componentes que estão nos formulários do PCT. O recurso à frame-work de elementos, componentes e padrões permitirá, se eficaz, uma linguagem visual universal no universo web da Fundação.

Grellhas e viewports

Os viewports mostram-se obsoletos em quase todas as aplicações. No último ano, período de Julho 2013 a Julho 2014, apenas 4,79% dos visitantes do Portal de Ciência e Tecnologia com computadores de desktop ou portáteis tem uma resolução de 1024x768 pixeis. Todos os outros visitantes apresentam uma resolução superior sendo 1366x768 pixeis a resolução mais expressiva com 13,51%. A tendência de aumento das resoluções de ecrã é persistente e as resoluções mais baixas tendem a desaparecer.

Desta forma, a grelha de 960px utilizada na primeira versão do portal deve ser substituída por uma grelha de maior dimensão (por exemplo, 1070px) já incluída na biblioteca de componentes do Guia de Estilo. A grelha da frame-work Foundation tem, adicionalmente, a particularidade de ser responsive e estar preparada para funcionar em viewports de aparelhos móveis, como smartphones e tablets, que apresentam já um inequívoco crescimento em termos de visitas.

Uma grelha maior oferece uma maior flexibilidade de soluções na concepção das interfaces do utilizador e na apresentação de informação. A recomendação para utilização de uma grelha maior não se limita ao PCT, mas a todas as web properties da Fundação. Desta forma, pretende-se:

  • Aplicar, sempre que possível, a nova grelha disponível no guia de estilos em todos os novos websites ou aplicações da FCT;
  • A oportunidade de requalificar, sempre que possível, as soluções de desenho e layout em projectos já existentes.
Incoerências e falhas utilização de elementos, componentes e terminologia

O funcionamento e a previsibilidade das interfaces têm de ser estudados para tirar o melhor proveito de como utilizar os elementos nas aplicações.

Em alguns casos verificamos incoerências visuais que só podem resultar de: a) pressão e prazos demasiado agressivos ou b) falta de ponderação sobre as diversas possibilidades, componentes e padrões que existem para resolver um determinado problema na interface.

Desde o esquema de cores, tipos e tamanhos de letra, posicionamento de labels, são exemplos que podem ser dados para verificar algumas dessas incoerências, os casos das aplicações do PCT, avaliação de unidades e programas de doutoramento, mostram alguns destes problemas. É imprescindível que a equipa de desenvolvimento tenha alguma disciplina e resiliência na reutilização dos elementos e na aplicação das diretrizes definidas.

Por exemplo, muitas das aplicações web da FCT são inconsistentes nas páginas de validação. Essa inconsistência é notória na abordagem, estrutura, componentes e terminologia utilizada.

Affordances visuais

O termo affordance é utilizado para descrever a influência que a aparência visual ou forma de um objecto, físico ou digital, tem na percepção de como podemos interagir com ele. No design digital, por exemplo, a forma tridimensional dos primeiros botões em interfaces gráficos tinham como objectivo invocar as características de um botão enquanto objecto físico. Este modelo conceptual foi evoluindo ao longo do tempo, mas a importância das affordance na eficiência e usabilidade não diminuiu.

É necessário continuar a “informar” os utilizadores sobre a forma como podem interagir com uma interface. O design visual é crucial na construção da affordance, mas também pode subvertê-la. Quando se introduzem elementos inovadores ou menos convencionais, deve-se testar a forma com as affordance servem o propósito com os utilizadores.

Em algumas das nossas aplicações web falhamos na aplicação do conceito de affordance não existindo uma distinção entre campos normais e desactivas de um formulário. Neste caso, o campo desactivo é idêntico ao campo normal, confundindo o utilizador.

Esta problemática só pode ser resolvida se a affordance visual for reforçada e tiver uma utilização coerente das soluções. Visualmente é importante existir uma clara distinção entre os campo normais e desactivos e na utilização de links (Fig. 7).

[Figura 8] Os campos desactivados, não se distingue dos campos normais.
Fig. 8 — À esquerda o exemplo de um formulário com campos desactivos que não têm qualquer distinção visual. À direita, os novos elementos com a affordance correta que facilita a distinção.

Algumas diretrizes importantes para a aplicação da affordance correta:

  • Assegurar que se utilizam as classes que invocam a formatação visual adequada para cada elemento da interface;
  • Links e menus de navegação devem comportar-se de igual forma sobre as aplicações da instituição, relativamente à função e cor, com affordance visual representada no guia de estilos.
  • Uniformização e representação visual clara sobre os 3 estados ou ações dos botões.
Menor densidade, maior leitura

Entre as várias razões para elaborar uma nova linguagem visual para as web properties encontra-se a necessidade de simplificar o excesso cromático, menos linhas e, de forma geral, simplificar a maioria dos elementos de forma a reduzir a sua preponderância visual conforme foi salientado anteriormente. Nesta proposta a "mancha gráfica" é mais contida e utilizam-se alguns elementos e conceitos de design de interação que aumentam a legibilidade, reduzem o ruído visual e utilizam padrões reconhecíveis.

Articulando este novo vocabulário visual, uma organização correta dos formulários e opções eficazes e intuitivas no design de interação é possível melhorar substancialmente a legibilidade no preenchimento dos formulários.

Assim, incentivamos os nossos developers a:

  • Pensar antecipadamente no fluxo de uma tarefa e no caminho para a sua concretização;
  • Reflectir sobre a organização de uma aplicação antes de iniciar a escrita de código;
  • Minimizar a disponibilização de grande blocos de texto usando a técnica progressive disclosure;
  • Utilizar os elementos e componentes de UI definidos pela equipa de design;
  • Solicitar sempre que necessário a colaboração dos designers para resolver um problema ou estilizar um componente que não esteja incluído no "Guia de Estilo".

Progressão e validação

Existem duas soluções a serem utilizadas nos formulários das aplicações web FCT. Tipicamente estes formulários são extensos e estão organizados em várias páginas.

Actualmente, na maioria dessas aplicações a submissão dos dados é explícita e depende da ação do utilizador. Em alguns casos, a submissão oscila entre os seguintes modelos:

  • O guardar de dados campo a campo, como é o caso do Roteiros de Infraestrutura
  • O guardar de dados dos campos preenchidos, no final de cada página da aplicação.

A utilização destes modelos divergentes de progressão/submissão ocorre em formulários de candidatura que são estruturalmente semelhantes. Tendo em consideração que muitos dos utilizadores podem ser comuns considera-se importante existir uma abordagem consistente que não coloque em causa o modelo mental do utilizador.

A progressão é normalmente não-sequencial, mesmo em formulários que estão divididos em várias páginas. Dessa forma, confere-se ao utilizador a possibilidade de preencher faseadamente e ao seu ritmo, por exemplo, uma candidatura. Neste tipo de aplicações existe uma validação final que assegura:

  • O preenchimento de todos os campos que são considerados obrigatórios;
  • A correcção de erros validados pelas regras de negócio.

Mesmo neste caso, as páginas de avaliação dos formulários de candidatura são, também elas, diferentes. Não existindo um modelo previamente concebido, que seja facultado à equipa de desenvolvimento, o resultado — até pela pressão constante e os prazos agressivos a que a engenharia está sujeita — incorre em implementações pouco articuladas e, uma vez mais, pouco consistentes.

Deste modo, no que diz respeito à interface da validação final, procurou-se uma solução que possa ser transversal, mais legível e direccionada para um auxílio tangível na resolução do erro. Algumas questões que foram endereçadas:

  • Normalização da terminologia usada (ex: Validation em vez de Commit and locking);
  • A informação apresentada na página de validação deve estar no idioma do restante formulário;
  • As funções dos botões necessários no interior do painel devem ser explícitas, quer na representação visual, quer no texto utilizado;
  • A iconografia (alerta, erro e aviso) deve estar em conformidade com a iconografia utilizada nos alertas e notificações existentes no guia de estilos.
[Figura 9] Modelo em baixa fidelidade proposto para a validação de formulários de candidatura.
Fig. 9 — Proposta de modelo, em baixa fidelidade, para a validação de formulário de candidaturas.

Este modelo pode, eventualmente, ser adaptado para coexistir com um modelo de validação por página — préviamente abordada — onde existe uma retroação "imediata", após a ação primária (normalmente, "guardar" ou "guardar e continuar"). A validação (campos obrigatórios e erros) por página é um modelo mais transversal, abarcando um conjunto mais alargardo de aplicações enquanto que validação final é mais adequada a formulários de candidatura ou qualquer outro que implique a introdução de um conjunto considerável de dados em vários passos.

Edição e interfaces de modo

Não existe um modelo standard para o fluxo de criação e edição de dados nas aplicação da FCT.

Em algumas aplicações mais antigas, a edição realiza-se numa página dedicada para o efeito, mas no PCT a edição de dados é feita de acordo com dois modelos distintos: um onde se recorre à utilização de janelas modais; outro, mais esporádico, onde a edição é realizada inline ou seja, na própria página. Não existe um racional claro relativamente aos cenários em que se deve utilizar um ou outro modelo.

As janelas modais apresentam algumas vantagens:

  1. Evitam a necessidade de carregar uma nova página, algo que tipicamente desagrada os utilizadores;
  2. Permitem disponibilizar conteúdos com alguma dimensão como imagens e vídeos, evitando que estes ocupem espaço na página;
  3. São adequados para formulários curtos que utilizam poucos campos, como é caso de logins, páginas de registos ou formulários de contacto.

Mas também têm algumas desvantagens:

  1. É um modelo relativamente limitado para aplicações transaccionais com formulários extensos;
  2. Podem, em algumas situações e dependendo da implementação, ocultar informação de contexto que é útil e necessária para conclusão da tarefa;
  3. Levantam alguns problemas de acessibilidade para utilizadores com o javascript desactivo sendo necessário conceber uma boa solução de fallback;
  4. Requerem algum esforço de desenvolvimento se existir variabilidade na extensão de conteúdo a exibir.

Tendo em conta a informação enunciada, qual é o modelo de edição de dados proposto?

  • Utilização de janelas modais para formulários com poucos campos (até 4 campos);
  • Edição de formulários extensos (mais de 4 campos) numa página própria para edição, sem interface de modo.
[Figura 10] modelo de edição para janelas modais e sem interface de modo
Fig. 10 — À esquerda, modelo para edição em janela modal. À direita, modelo para edição sem interface de modo.
Opções de input desajustadas

Por outro lado, existem também opções de input de dados que, em alguns casos, são desajustadas para o tipo de dados a introduzir. A título de exemplo: a forma de inserir palavras-chave nos formulários tem de ser fácil, simples e de modelo único. A solução utilizada para a introdução de palavras chaves, no PCT, com recurso à janela modal não é adequado. No IF utilizou-se uma opção mais simples onde o custo de interação (número de cliques) é inferior.

Linguagem e terminologia

A escrita é parte integrante do processo de desenho de interfaces e, consequentemente, na usabilidade de um sistema de informação. Nas aplicações web da Fundação existem alguns problemas relacionados com a linguagem, redação de conteúdos e a escrita de interfaces. Não se utiliza um vocabulário controlado, algo mais comum nas ciências documentais, nem particular rigor na utilização dos melhores termos para as etiquetas (labels) dos campos, botões, secções e sistemas de navegação.

É necessário fixar alguns princípios de escrita, zelar pela manutenção de uma terminologia e incentivar os profissionais da DSI à sua utilização consistente e coerente.

Tal como previamente mencionado na secção de ajuda ao preenchimento, existem uma série de princípios que se podem aplicar para melhorar a comunicação escrita:

  • Utilização de voz activa;
  • Minimizar a duplicação de conteúdos e disponibilizar apenas conteúdo relevante para os utilizadores;
  • Os textos devem ser informativos e específicos. Por exemplo: não devemos utilizar o termo pesquisar quando nos referimos a filtrar;
  • As etiquetas dos botões de ação primária e ações secundárias devem reflectir o seu comportamento. Por exemplo, num formulário com várias páginas em vez de utilizarmos o termo “Guardar” ou “Continuar” é mais esclarecedor utilizar “Guardar e continuar” quando é esse o comportamento do sistema
  • A terminologia utilizada nos elementos e componentes da interface devem ser utilizados de forma consistente.

Com o intuito de facilitar a reutilização dos mesmos termos para ações que são comuns, agregou-se numa pequena tabela os termos em inglês e português:

Inglês Português
Add Adicionar
Back Retroceder
Call Candidatura
Cancel Cancelar
Continue Continuar
Delete Apagar
Download Descarregar
Edit Alterar
Lock Lacrar
Optional Opcional
Overview Visão Geral
Print Imprimir
Save Guardar
Search Pesquisar
Submit Enviar
Reset Limpar
Required Obrigatório
Upload file Adicionar ficheiro

Barreiras técnicas

A experiência de utilização de uma aplicação não é apenas influênciada pela estratégia de conteúdos, a arquitectura da informação ou o desenho (visual e de interação) mas também pelas decisões técnicas e pela qualidade de implementação. A título de exemplo: uma aplicação lenta, com problemas de performance, não proporciona uma boa experiência de utilização.

Na verdade, existem possivelmente várias dimensões deste problema:

  • Prazos muito curtos que influenciam negativamente a qualidade de desenvolvimento, de implementação e a quality assurance;
  • A inexistência de modularidade do código que dificulta o reaproveitamento de código testado, atrasando significativamente o desenvolvimento e introduzindo alguma volatibilidade na implementação;
  • Adaptar livremente as maquetas da interface provenientes da equipa de design.

A comunicação e a colaboração entre colegas é cada vez mais importante que na DSI, dado o carácter multidisciplinar e as competências envolvidas na actual concepção de aplicações e serviços digitais.

Qualquer que seja a aplicação a ser desenvolvida é fundamental que os developers ponderem o impacto das suas opções técnicas na interação com o utilizador e que lhes sejam dadas condições para prosseguir com uma abordagem estruturada.

Entre os vários aspectos a ponderar, salientamos algumas problemáticas comuns:

  • Como podem organizar a informação numa página de forma a melhorar a usabilidade e ajudar o utilizador a concluir a sua tarefa;
  • Aferir se já existe algum padrão definido para um determinado tipo de problema;
  • Valorizar a consistência providenciado soluções similares para problemas idênticos;
  • Ponderar o impacto de uma determinada solução na usabilidade e experiência de utilização — “se eu fizer uma “operação” nesta página, relativamente extensa e que implique o reload da mesma, o que posso fazer para que o utilizador não perca o contexto do campo onde está (como acontece quando é remetido para o ínicio da página) ?”
  • Avaliar se estão a utilizar o melhor componente para a visualização de determinado tipo de informação e que alternativas existem;
  • Definir, divulgar publicamente e manter actualizada a informação sobre quais são os agentes do utilizador (browsers) suportados nos sistemas de informação da FCT;
  • Garantir que código é válido e segue as boas práticas da indústria.