Arquitetura da Informação

O projeto Cubezilla criado pelos alunos da pós-graduação Faber-Ludens/Fisam/UnC foi premiado no desafio da Mozilla Labs na categoria voto popular. O desafio era repensar as abas do navegador, que já não dá conta dos hábitos de navegação dos usuários, porém, nossos alunos foram além: redefiniram a metáfora de navegação para o navegador. Ao invés de navegar uma pilha de documentos, navega-se um cubo Rubik. Veja no vídeo abaixo:

Leia mais.

Vocês lembram das análises heurísticas dos portais de universidade né? Pois bem, agora comparei a arquitetura da informação do website da UFPR com similares. A análise heurística foi fácil porque é mais fácil encontrar defeitos na capa do livro do que no seu conteúdo, ou melhor, na sua organização.

Como nunca tinha lido nada sobre esse tipo de análise, fiz umas buscas tentando encontrar algum procedimento semelhante à análise heurística, mas que não fosse apenas uma lista de verificação (checklist), para que me desse margem à comparações mais qualitativas.

Por coincidência, poucos dias antes, Louis Rosenfeld havia publicado o que parece ser as primeiras heurísticas para a Arquitetura da Informação de websites:

• Página principal
• Interface de busca
• Resultados da busca
• Navegação global (site-wide)
• Navegação contextual

Apesar de boas, elas estavam direcionadas mais para uma estratégia de baixo pra cima do que cima para baixo. Explico.

Como estou analisando os websites do lugar de quem vê de fora, não tenho acesso aos procedimentos utilizados para a construção do website, a tal da estratégia de baixo para cima (ou no inglês bottom-up). Não sei os metadados, o algoritmos das buscas e etc. Porém, posso analisar o website à partir daquilo que vejo, penetrando até onde der. Isso é de cima para baixo (top-down). Posso analisar os rótulos, os menus de navegação, os agrupamentos, a hierarquia e vários outros aspectos da arquitetura.

Leia mais.

Ô coisa chata de fazer! Mas, como fazer o re-design de um site sem conhecê-lo como a palma da sua mão? Quero propor uma nova organização para o website da UFPR, mas antes preciso saber exatamente o que estarei organizando. Para isso, fui clicando em todos os links que haviam na página inicial e nas secundárias e anotei todos os pedaços de conteúdo que encontrei (content chunks, em inglês).

Se por acaso, estivesse arquitetando um website que ainda não existe, iria entrar em contato com todos os manda-chuvas do projeto (stakeholders) para descobrir o que eles pretendem colocar dentro do website. Seria mais trabalhoso, mas não haveria escolha.

O Inventário de Conteúdo tem só 5 páginas porque economizei verbo. Poderia ter sido mais descritivo em cada item, mas já que esse inventário foi escrito só para mim e não para ser compartilhado com uma equipe, nem discutido com manda-chuvas, escrevi só o necessário para ativar minha memória. Em cima desse documento, rabiscarei rótulos e agrupamentos menores. Depois, acho que vou usar um método chamado Diagrama de Afinidades (affinity diagram) para criar agrupamentos maiores. O objetivo é chegar na taxonomia principal do website. Falarei mais disso na sequência.

Leia mais.

Na medida em que vou aprimorando meus conceitos de projeto de websites, fica cada vez mais claro o que isso significa. Estou fazendo a arquitetura da nova versão da FlashMasters usando uma abordagem bottom-up (de baixo para cima, bem fundamentada) e a documentação que estou produzindo pode servir para ilustrar o que digo.

A primeira coisa que fiz foi levantar no papel todo conteúdo que tinha no site, ao mesmo tempo que mapeava a navegação atual. O Inventário de Conteúdo está neste TXT. Em seguida, listei todos os assuntos abordados ao mesmo tempo em que tentava mantê-los dentro de grandes-áreas: Design, Programação e Operação de Software. Feito isso, comecei a agrupar os conteúdos que eram correlatos e a esboçar algumas classificações que serviriam de base para a navegação e modelagem do banco de dados.

Como vocês podem ver no esboço, identifiquei todos os tipos de conteúdo que o site continha, de uma perspectiva mais de modelagem de dados. O primeiro impulso foi criar a navegação baseada no agrupamento desses tipos de arquivo, por exemplo uma seção só para arquivos de exemplo (.FLA, .SWF, etc).

Leia mais.

Terminei e analisar o resultado das entrevistas com os usuários do site da UFPR. As conversas foram muito elucidativas, sinto que comecei o projeto com o pé direito. Ao contrário do que pensava, os usuários não acham o site tão ruim e relataram não ter problemas com ele. É possível que haja sentimentos subjetivos em jogo, como orgulho e auto-estima, mas já é suficiente para sublinhar que as mudanças não poderão ser drásticas, já que o modelo atual é satisfatório. Como disse um professor de História, "ele só precisa agrupar melhor as informações semelhantes".

O tempo para fazer perguntar e anotar as respostas não passava de 5 minutos, mas todo mundo sempre tinha uma história para contar, uma sugestão a fazer. Em média foram 15 minutos bem gastos em cada entrevista, totalizando +-10 horas de trabalho, fora transporte.

Para projetos sérios de webdesign esse método tem um custo benefício muito bom, principalmente porque a amostragem poder ser bem menor do que a minha (34 usuários). Acredito que 4 entrevistas mais longas ou 8 rapidinhas são suficientes para perceber opiniões semelhantes e padrões de comportamento. Não dá um dia inteiro de trabalho e pode ser feito por telefone.

Leia mais.

Ben Schneiderman fecha o livro Designing the User Interface com um bom debate sociológico situando o designer de interface como elemento importante na construção de um mundo melhor. Ele identifica as 10 pragas da era da informação:

1. Ansiedade - medo de estragar o computador, perder dados, parecer burro
2. Alienação - quanto mais se usa o computador, menos se relaciona diretamente com outras pessoas
3. Info-excluídos - aqueles que não tem acesso perdem empregos ou oportunidades de estudo
4. Impotência do indivíduo - contra as grandes coorporações impessoais o que podemos fazer?
5. Velocidade e complexidade avassaladora - a cada dia as regras do jogo mudam e as tecnologias tem de serem atualizadas
6. Fragilidade organizacional - uma pessoa só pode causar um blakout de energia elétrica, ou mesmo destruir um terminal de computador e prejudicar milhares de pessoas
7. Invasão de privacidade - a facilidade de armazenar, trasnferir e consultar dados torna a violação da pricadidade das pessoas mais fácil
8. Desemprego e obsolência - assim como aumenta a automação, alguns cargos se tornam dispensáveis e as pessoas são mandadas embora
9. Falta de responsabilidade profissional - é mais fácil culpar o computador ou uma organização impessoal pelas nossas limitações e falhas
10. Deterioramento da imagem da pessoa - computadores inteligentes ameaçam um dia substituir o homem, em todas as suas habilidades

Com certeza há mais problemas, mas achei a lista dele muito abrangente. Tocou nos pontos fundamentais. Para ele, as soluções são:

• design centrado no ser humano
• organizações interativas
• educação
• prêmios de responsabilidade social
• conscientização pública
• legislação
• estudos avaçados

Sempre acompanho o registro de todas as buscas que foram feitas nesse blog, mas desde que coloquei a caixa de busca lá em cima, no canto direito, o número de buscas aumentou 5 vezes. Esse negócio de seguir padrões é realmente útil, hein? Tinha colocado lá embaixo, com um tamanho gigantesco justamente para zombar da recomendação do Jakob Nielsen. Redimido de minha rebeldia, descobri que muita gente não acha o que procura nos arquivos desse blog simplesmente porque ele ainda não tinha um registro de sinônimos.

Alguém buscou uma vez "rastro do mouse" de três combinações diferentes, mas não achou nada. Os post que ele buscava era esse: movimento do mouse rastrado e, em nenhum lugar do texto constava a palavra "rastro". Pesquisei e descobri que o Movable Type tem um lugar que você coloca palavras-chaves para cada post, mas nunca tinha visto isso na interface. Está escondido por padrão. Para habilitar, basta clicar no pequeno link "Customize the display of this page", embaixo do formulário de novo post. Agora não frustro mais quem digita uma palavra errada, como Jackob Nielsen ao invés de Jakob Nielsen.

Durante a pesquisa, acabei descobrindo uma extensão que permite agrupar posts por palavras-chave. Agora ao lado do final dos posts, temos uma caixa vermelha com outros posts que provavelmente vão dar continuidade à leitura. Movable Type é o que há!

Paulo Renato escreveu um artigo no Webinsider dando uma boa introdução na arte de criar menus de navegação. Ele conseguiu resumir bem os principais pontos que alguns bibliotecários reformados (leia-se Arquitetos da Informação, hehehe) se esmeram em complicar. Existe toda uma ciência da informação por trás do que eles chamam de taxonomia (esse negócio de categorizar e criar rótulos), mas acredito que não precisamos de tanto preciosismo para um mero menu de um website institucional com menos de 20 páginas. Quando a quantidade aumenta, são úteis. O manual básico de sobrevivência está no artigo do Paulo. Se você se apaixonar pelo assunto (eu me apaixonei), sugiro começar a ler artigos específicos sobre.

Nem sempre podemos fazer a reunião de briefing direto com o cliente. Ficamos à mercê do contato comercial e, como não será ele quem vai ter que quebrar a cabeça para inventar algo, em geral, eles não se dão o trabalho de sentar com o cliente e fazer um bom briefing (existem exceções, mas eu ainda tô pra conhecer um pessoalmente). Caso, haja a possibilidade do designer conversar direto com o cliente, melhor. Tem até um livro inteiro só para dar as dicas no assunto.

Uma vez eu recebi um briefing sensacional. O diretor da agência me entregou um cartão da empresa e disse: "Ó, faz um site aí. Eles querem essa logo animada, bem grande na home". O resultado não poderia ser pior. Aprendi a lição. No próximo job, fiz questão de sentar com o cliente para especificar o briefing. Percebi que não era tão fácil quanto parecia e tivemos uma nova novela na agência, mas dessa vez benigna. Nos sentimos no controle e o projeto acabou dando certo, embora tenha havido um bocado de retrabalho e o prazo tenha estourado.

Eu consegui, mas sei que muitas agências não permitem esse contato, ou por questões de tempo ou por questões de filosofia empresarial. De qualquer forma, ainda existe a possibilidade de inventar um briefing. Não quero dizer que você deve ler mentes, mas pode se basear no que já ouviu falar sobre o projeto, nas instruções verbais iniciais, em pesquisas gerais de marketing e sua experiência pessoal.

Ao invés de ficar esperando marcar uma audiência com a direção da Universidade em que estudo, resolvi criar o briefing direto com o meu professor orientador da disciplina. Veja como ficou o exemplo de briefing fictício e pegue a manha.

[ Atualização ] A pedidos, disponibilizo um briefing real de um pequeno projeto que fiz: Briefing Mercado da China [DOC] e o Website final

Leia mais.