Multiplexado

Este é o segundo texto da série onde eu falo sobre Wireframes do ponto de vista prático. Se você não leu o texto anterior, 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. Então, vamos lá:

Parte 2 de 6 - Capacidade de manutenção rápida do Wireframe

(Soluções para facilidade de manutenção em projetos de maior porte).

a) Elementos globais desatualizados em muitas interfaces

O Wireframe deve ser um documento vivo. Não deve apenas ser construído, aprovado e abandonado. Precisa ser atualizado durante todo o ciclo de vida do projeto, com a intenção de refletir as alterações e evoluções feitas à cada etapa.

É muito claro que do ponto de vista gráfico, o desenho do Wireframe não precisa e nem deve parecer com o projeto implementado. Os designers devem ter liberdade suficiente para trabalhar o design das interfaces de acordo com as prioridades de sua disciplina.

No entanto, sob a luz da arquitetura de interfaces, o projeto final deverá refletir todos os fundamentos informacionais que forem projetados no Wireframe. Isso inclui as características de hierarquização, organização e peso da informações. Mesmo que alterações sejam decididas em fases mais avançadas do projeto, é importante que exista algum mecanismo de rastreabilidade que faça com que sejam atualizados os Wireframes e todos os demais documentos arquiteturais utilizados durante o projeto.

Dentro de uma ótica de facilitar a manutenção do Wireframe, sempre é positivo evitar a execução de trabalho braçal para o projetista. Ficar alterando pequenas coisas em grande número de telas é uma tarefa desagradável que pode ser contornada de algumas formas:

• Quando possível, estabeleça zonas descritivas que defina tudo que é global em separado (cabeçalhos, menus, rodapés, etc). Ao detalhar as interfaces internas (miolo), deixe entendido no Wireframe que aquele é um módulo que acontece dentro de uma estrutura global que está documentada em outra parte do documento.
• Mensagens de diálogo e caixas de erro podem ser aplicadas em um fundo rachurado ou semi-transparente. Não precisam ser colocadas sobre telas de verdade. Isso dá até um maior poder de reuso para esse tipo de interface, já que não se torna necessária a repetição do desenho quando a mesma mensagem ou diálogo acontecer em outro contexto.
• Sempre que possível faça uso de recursos de agilizem as alterações de larga escala nos projetos. Um exemplo? Se usar o Visio, crie stencils dos elementos globais. Se for PowerPoint, Impress ou Draw, use bem o recurso do "Mestre". E assim suscetivamente para cada ferramenta. Busque sempre os melhores recursos para adiantar a manutenção do seu trabalho. Se você tem a necessidade de atualizar 400 telas quando o cliente pede para mudar simplesmente o nome de um sistema, seu Wireframe tem problemas.

b) Anotações textuais desestruturadas em torno dos elementos que compõem as telas

Um problema muito sério acontece quando o Wireframe é desenhado sem nenhum documento de apoio (como um sitegrama ou outro documento de navegação). O projetista começa a anotar regras dentro do próprio Wireframe, definindo as premissas do o projeto em tempo de desenho.

Esse tipo de hábito torna a regra de apresentação muito difícil de entender. Existe uma dependência excessiva de toda a equipe por uma boa redação do projetista da interface, para que ele explique como as coisas que ele projetou deverão se comportar na tela. Qualquer mal-entendido gerará erros, retrabalho ou necessidade de reuniões explicativas.

Uma boa saída é deixar a responsabilidade de descrição do fluxo de navegação para um documento externo do tipo sitegrama, e deixar dentro do Wireframe somente anotações relativas à elementos de composição de tela. Não se mistura o que é descrição de navegação do que é descrição de comportamento de elementos.

Procure também estruturar um padrão de anotações de regra que seja unificado para você e para sua equipe. Dados importantes para o funcionamento da interface não devem ficar jogados em balões e setas descritivas espalhadas em várias copias de uma mesma tela.

Pense que essas informações devem ser facilmente localizáveis e recuperáveis pelas equipes de desenvolvimento e testes, que farão uso efetivo desses dados. Pense que o documento do Wireframe deverá proporcionar uma boa leitura tanto para o cliente quanto para quem implementa o produto na ponta de cá.

c) Adaptação e uso de ferramentas inadequadas para o desenho das telas

Temos muita gente que hoje defende a prototipação em papel. Eu também sou a favor de independência de ferramentas e favorecimento de conceitos e padrões. A inteligência de um bom projetista extrapola a ferramenta que ele usa.

Com essa ressalva já feita, o que estou falando nesse caso é de se evitar a adaptação de ferramentas ineficientes para o desenho de telas. Isso pode produzir um comprometimento da produtividade da equipe e reduzir qualidade do trabalho final.

Quer um exemplo? Já vi um grande número de empresas utilizando o Microsoft PowerPoint para o desenho de Wireframes. Esse é um formato horrível, pois adapta um software originalmente feito para apresentação de slides em projetores. Trata-se de tentar matar "canhão" com tiro de "mosca" (o ditado está invertido de propósito). O uso do PowerPoint para desenho de Wireframe extrapola as possibilidades da ferramenta e causa uma série de problemas aos times envolvidos.

Do exemplo do PowerPoint podemos citar:

• Dificuldade de localização de telas dentro do documento.
• Travamentos do software ao manipular arquivos de tamanho grande.
• Corrompimento e inutilização de arquivos após o crash da aplicação.
• Falta de precisão na manipulação de elementos na tela.
• Problemas de agrupamento e sobreposição dos itens na tela.
• Dificuldade de alinhamento e posicionamento das coisas na tela.
• Qualidade inferior na impressão dos artefatos (versão impressa).

Entre muitas outras...

Alternativas? Ivo Gomes sugere o Microsoft Visio, o OmniGrafite, o Adobe Ilustrator ou o Adobe InDesign. Além dessas aí, existem outras ferramentas gratuitas ou pagas que podem te auxiliar melhor nesse processo. Pesquise a que melhor se encaixa na sua proposta de trabalho, pensando sempre em tornar os seus artefatos bem fáceis de manter.

Continue a leitura no próximo texto, que fala sobre discrepâncias e trapaças no aproveitamento da tela pelos Wireframes. Muito obrigado!