Multiplexado

Este é o terceiro texto da série onde eu falo sobre Wireframes do ponto de vista prático. Se você não leu os textos anteriores, recomendo consulta ao índice.

Como já disse anteriormente, vale ressaltar que o caráter desses textos leva uma carga pessoal muito grande. Estou aqui apenas para aprender e dividir - sinta-se à vontade para concordar, discordar ou apresentar outros pontos de vista. Novamente, vamos lá:

Parte 3 de 6 - Discrepâncias no aproveitamento de espaço da tela - fator de "acochambramento"

(Soluções contra a síndrome do "Coração de Mãe" - Nem sempre cabe mais alguma coisa no Wireframe)

a) Trapaça de uso inadequado para caber mais informação na tela

A divisão de tarefas no projeto de interfaces é uma coisa muito proveitosa. Mas como qualquer coisa na vida, isso não deve ser levado ao extremo. Quando o profissional se isola em sua disciplina, muitas vezes acaba superestimando o seu papel e prejudicando toda a sequência de etapas posteriores do projeto.

Um caso que ilustra a situação acima é quando o projetista tenta distribuir os elementos no Wireframe de maneira não-realista. Colocar quantidades excessivas de elementos e contêineres muitas vezes atende o anseio de clientes, mas cria problemas sérios para equipes de design.

É sedutor reduzir as fontes ou redimensionar controles para tudo ficar bonito no Wireframe. Mas isso não resolve o problema do volume de informações. Apenas empurra a agonia para a próxima fase do projeto.

Um bom artefato de design, entre outras coisas, deve aproveitar razoavelmente as potencialidades do meio. Além disso, deve contornar bravamente as limitações tecnológicas que cada tipo de meio normalmente oferece.

Não é justo esperar o milagre de que o designer faça o mundo caber em retangulinhos de resoluções variáveis. Não esqueçamos as necessidades atuais de acessibilidade para dispositivos. O nosso horizonte não mede mais 800 x 600 pixels. Ele pode ser muito menor ou muito maior do que isso.

Para o alcance da qualidade, é fundamental que o designer não receba como artefato de entrada wireframes entulhados de informações "acochambradas", reduzidas, espremidas, adaptadas.

Para a solução desse problema, o projetista precisa estar atento que algumas condições de volume informacional podem ser resolvidas com alternativas melhores de navegação e de distribuição de informações entre níveis.

O cliente também precisa entender que a priorização de algumas áreas resulta em encolhimento natural de outras. Todo mundo quer aparecer com a mesma relevância, mas nem sempre isso será possível.

Em alguns tipos de projeto, a própria plataforma de implementação pode oferecer recursos de tratamento desse problema, como vemos no caso do Ajax, só para citar um exemplo. Pode ser favorável ao usuário refinar as informações sob demanda, como acontece com as mensagens do Gmail - exemplo clássico.

Só precisamos de cuidado para que esses recursos possuam alternativas acessíveis para todas as pessoas. Alguém aí já tentou acessar o Gmail via software ledor de tela? Eu já tentei. É praticamente impossível de navegar e ler mensagens. Inclusive na versão "Somente HTML" do mesmo. Presteza zero da interface. Essa coisa do mito do Gmail como o case perfeito do Ajax é pano para manga para um texto exclusivo, que devo escrever em breve. Como pode o maior "case" de Ajax do mundo não implementar o conceito de graceful degradation?.

O projetista também precisa quebrar a barreira do isolamento e entrar em contato com designers e programadores, com a finalidade de checar a viabilidade técnica dos seus projetos. Não é feio perguntar, pedir opiniões. Esse tipo de integração pode evitar retrabalho para todos. Em caráter multidisciplinar e com respeito mútuo entre as equipes, quem ganha é o usuário final do que está sendo produzido.

b) Trapaça na colocação de recursos de scrolling e de previsão de rolagem de conteúdo

A possibilidade do controle de rolagem de conteúdo (scrolling) foi um recurso muito explorado um tempinho atrás. Todo projeto "moderno" tinha que ter uma barrinha de scroll customizada. Todos os problemas de redação de conteúdo agora tinham uma solução idiota: Muito melhor do que corrigir um texto ruim era colocá-lo espremido dentro de um scrollzinho.

As atuais premissas de acessibilidade desmontam um bocado a cultura do scroll customizado. Nem sempre um recurso despadronizado e caseiro conseguirá implementar todas as características de acessibilidade incorporadas por um controle padronizado, que funciona de maneira mais integrada com os sistemas operacionais e browsers disponíveis. Essa simplicidade é que garante o melhor entendimento da interface por softwares assistivos, suportando um maior número de condições adversas de uso.

Sempre que possível, o projetista deve evitar cair nesse tipo de solução clichê para tratar volume de conteúdo. É um outro caso de aculturamento de clientes. O aumento da qualidade dos textos, com a busca da linguagem e objetividade corretas, pode ser uma solução bem mais inteligente para esse tipo de problema.

Novamente, até o próximo e obrigado por estarem acompanhando a série!