Multiplexado

Dias atrás, o colega Luciano Lobato postou na lista ArqHP um texto muito interessante, resultante de uma Aula de Ted Nelson na PUC-SP. Infelizmente não consegui capturar a data que essa visita ao Brasil ocorreu. Achei esse texto muito bacana e resolvi anotar algumas coisas aqui para compartilhar com vocês.

Ted Nelson é o sujeito que recebe os créditos por ter cunhado o termo "hypertext" (hipertexto), publicando isso em 1965. Hoje, ele dá alfinetadas na maior implementação do conceito que ele mesmo criou: A World Wide Web, que foi desenvolvida muitos anos depois por Tim Berners-Lee.

Nelson tentou emplacar o tal do Projeto Xanadu, que foi fundado em 1960. Segundo Ted, o Xanadu é um modelo mais inteligente do que os softwares de hoje, que são meras simulações de papel.

Para ele, essa coisa toda de manipular "documentos", "arquivos", "pastas", "desktops" e "lixeiras" são exemplos de metáforas que prendem as pessoas, deixando-as presas a comparações e limitações.

É nesse bonde que ele coloca também a web, de Berners-Lee, que enterrou definitvamente o Xanadu. Na ótica do Nelson, a web é estruturada em estruturas limitadas chamadas "páginas", com os seus links de mão-única para a navegação entre elas.

Ted acusa esse modelo de ser simplista e de não favorecer o caminho reverso da informação. O interessante é se pararmos para pensar, as acusações dele fazem sentido. Tanto é que o conjunto de serviços aclamados como a tal da Web 2.0 é baseado nesse tipo de necessidade.

Como já diziam os antigos: A história sempre é escrita pelas mãos do vencedor. O Nelson perdeu essa batalha, e o Xanadu nunca saiu do papel. Contudo, fiquei maravilhado por poder acompanhar a ótica do perdedor, tendo a chance de ver o outro lado da moeda.

Vamos à algumas coisas que Nelson constrói em seu raciocínio:

Sobre o browser (navegador)

"Tentar compreender a estrutura em grande escala de páginas da web interligadas é como tentar olhar para o céu à noite (...) através de um canudo de refrigerante."

Sobre treinamento

"O chamado 'treinamento em informática' é uma ilusão: eles ensinam à pessoa as estranhas convenções e esquemas atuais (Desktop? Isso parece uma mesa de trabalho? Uma mesa vertical?) e dizem que é assim que os computadores são. Errado."

Sobre o mito dos laboratórios Xerox PARC

"A conhecida história sobre a Xerox Parc, de que eles tentaram tornar o computador compreensível para o homem comum, é uma enganação. Eles imitaram o papel e as máquinas de escritório conhecidas porque era isso que os executivos da Xerox conseguiam entender. A Xerox era uma companhia devoradora de papel (...)."

Sobre Steve Jobs

"Foi Steve Jobs quem orientou o trabalho da Parc para o mal. Ele pegou uma equipe da Parc e fez um trato com o demônio, e esse trato foi chamado de Macintosh."

Sobre os "tekkies"

"A visão tekkie é geralmente a mentalidade do trabalhador braçal: primeiro você faz este serviço, depois faz aquele serviço, tudo o que lhe mandarem; (...) quando você termina o trabalho que lhe atribuíram, passa para o próximo trabalho da lista."

Sobre o software de escritório ser desajeitado

"Pense em quanto tempo demora para abrir e dar nome a um arquivo e um novo diretório. Enquanto isso, o software de videogame é ágil, rápido, vivo. Por que isso acontece? Muito simples. Os caras que criam videogames gostam de jogar videogames."

Não deixe de fazer a leitura completa do texto.

Nelson, Theodor. (Consultado em Junho de 2006) "Libertando-se da prisão da internet". http://p.php.uol.com.br/tropico/html/textos/2674,1.shl

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!

Pode ser uma coisa muito reflexiva percorrer a web em busca de nossos próprios rastros no passado. Depois de uma passada lá no Web Insider ontem à tarde, lembrei de meus primeiros textos, que estão perto de completar cinco anos de existência.

Olha esse aqui:

13/11/2001
Novos mercados para o profissional Flash
http://webinsider.uol.com.br/vernoticia.php/id/1046

Foi o primeiro texto que tive coragem de publicar. Aconteceu graças ao apoio do Vicente Tardin, Editor e fundador do Web Insider. Ao Vicente, só tenho a agradecer pelo apoio e pelo espaço cedido.

Naquela epoca ainda não existia a blogosfera. Era muito difícil ser ouvido por muita gente. O Web Insider cumpria bem esse papel. E continua até hoje um dos principais veículos de informação especializada para o público de criação, tecnologia e negócios no mundo digital.

O texto do link foi escrito no contexto do Macromedia Flash 5. Em 2001, Flash ainda era um super-herói para alguns. Para outros, era sinônimo de gráficos e animações que faziam os sites ficarem mais legais.

Era o auge da geração dos "Loadings" intermináveis... das "intros" elaboradíssimas... da expansão do plugin e da plataforma... dos trabalhos esculpidos artesanalmente nas timelines com cor-de-argila... e do Nielsen batendo forte no Flash através do seu famoso alertbox... E por aí vai...

Não existia ainda o conceito de Rich Internet Applications. Aqui no Brasil, ainda era muito raro ter gente dedicada à programação dentro do Flash - os programadores em ActionScript.

De paraquedas...

Eu trabalhava como Analista de Sistemas. Estava recém chegado do mundo dos CPD's, caindo naquela coisa doida que eram as recém surgidas Agências Interativas. Tentava justificar a nova empreitada com o Flash pelo meu interesse por gráficos, projetos de interface e novas alternativas para a camada de apresentação dos projetos. O Flash tecnicamente tinha tudo o que eu queria na época. Só faltava massa crítica no mercado para que criasse um volume maior de demanda.

No meio da confusão e do amadurecimento do mercado, aquela coisa que tinha escrito no texto depois acabou acontecendo de fato. As linhas meio que descreviam uma espécie de embrião do que hoje é conhecido aqui no Brasil como "Internet Rica". A própria Macromedia (hoje Adobe) tem programas de treinamento e certificação diferenciados para "developers" e "designers", divisão que eu ensaiava no texto.

Hoje em dia, o conceito de Internet Rica começa a ficar mais amplo e independente de plataforma. Temos muita coisa nova com uso dos conceitos do AJAX que talvez a médio prazo possam proporcionar o mesmo tipo de Experiência que o Flash entrega.

Tenho uma visão pessoal de que o Flash está em declínio para muito dos usos para qual foi adaptado, mas para outros, ainda continua bombando. Quer um exemplo? O fenômeno YouTube. Uma boa reflexão sobre Flash Vs. Ajax que o Fred postou no ano passado. Recomendo leitura principalmente pela análise imparcial que ele faz das alternativas.

Reflexos da escrita do texto

Essa empreitada com o Flash resultou em muita coisa boa. Eu trabalhava na AgênciaClick (2000-2003, depois 2004-2005). Fiz muitos amigos trabalhando lá. Aprimorei a preocupação que sempre tive com as interfaces dos projetos. Pude conhecer muitas pessoas muito bacanas que nem dá para listar aqui. Conquistamos muitas coisas legais desbravando um formato de trabalho que hoje é praticamente padrão. Sinto um pouco de saudades daquele contexto. =)

Levamos dezenas de prêmios nacionais e internacionais recebidos pelos trabalhos, praticamente todos fazendo uso de Flash. Dos que eu participei, foram dois Leões em Cannes (Ouro e Bronze), Shortlists em Londres, um Clio Awards, um Grandprix no Clube de Criação de Brasília, prêmios em Portugal, Nova Iorque, um bocado de Colunistas Brasília e São Paulo, Revista About outras premiações legais que guardo com carinho.

No futuro de novo...

Fiquei curioso para imaginar daqui a cinco anos, quando eu der uma olhada nesse site aqui. Meu filhão chegou, e de hoje à meia década, o pequeno já deverá saber brincar no computador. Será que as coisas que conversamos aqui sobre Experiência do Usuário estarão no chão de fábrica das empresas? Vamos ver no que dá, espero que sim... =) Se não tiver, não tem problema. Na vida, muito mais do que acertar o futuro, a gente tem que saber a valorizar o presente de cada fase que a gente vai passando.

Mais velharias digitais de minha autoria, garimpados do WebInsider:

13/11/2001
Metodologia é tudo. Planejamento Salva.
http://webinsider.uol.com.br/vernoticia.php/id/1073

11/03/2002
Dica para o desenvolvedor: pense ECMAScript
http://webinsider.uol.com.br/vernoticia.php/id/1195

Apresentação

Nessa série de textos, comentarei especificamente sobre Wireframes de um ponto de vista prático. Julgo mais do que pertinente falar sobre isso aqui, pois acredito que um bom Wireframe é peça chave para o tratamento da Experiência do Usuário.

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. Estou aqui de coração aberto para expor "sugestões" mesmo, e nunca tentar dizer "verdades absolutas". ;)

Obs.: Se você ainda não sabe o que é um Wireframe, recomendo visita prévia ao texto do Leonardo Oliveira no Web Insider, que é muito bacana.

O texto completo está dividido em 6 partes. A parte inicial já está embutida nesse pacote, e as outras serão colocadas aqui ao longo das próximas semanas.

Eis a lista completa das seis partes:

1. Alcance do escopo do Wireframe

a) Problemas de mau uso do prazo, com falta de dimensionamento prévio do volume de trabalho
b) Diferença de nível de detalhamento entre Interfaces
c) Ausência de telas importantes no projeto

2. Capacidade de manutenção rápida do Wireframe

a) Elementos globais desatualizados em muitas Interfaces
b) Anotações textuais desestruturadas em torno dos elementos que compõem as telas
c) Adaptação e uso de ferramentas inadequadas para o desenho das telas

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

a) Trapaça de uso de tamanhos inadequados para caber mais informação na tela
b) Trapaça na colocação de recursos de scrolling e de previsão de rolagem de conteúdo

Bonus round!

Quiz com Wireframe tosco de exemplo - Participe!

4. Mau uso de controles de Interface

a) Uso de controles de maneiras bizarras (caso checkbox/radio button e outras loucuras)
b) Trapaça no comportamento de controles de Interface
c) Uso inadequado de controles de Interface

5. Falta de apoio a padrões e novas técnicas de construção de interfaces

a) Ausência de informações sobre hierquização absoluta de elementos
b) Ausência de descritivos textuais para informações não-textuais
c) Mau aproveitamento de recursos disponíveis em cada plataforma

6. Outros

a) Ausência de revisão dos textos embutidos no Wireframe
b) Formatos de entrega de artefato "não-seguros"
c) Problemas de recuperação de versões e controle de mudanças executadas
d) Problemas de falta de rastreabilidade entre os demais artefatos que compõem um projeto

Wireframes - Soluções para problemas comuns

Parte 1 de 6 - Alcance do escopo do Wireframe
(As coisas tristes que acontecem quando não se faz algo que deveria ter sido feito)

a) Problemas de mau uso do prazo, com falta de dimensionamento prévio do volume de trabalho

Pode acontecer quando o executor do Wireframe deixa o prazo correr sem ter noção real de todo o volume do trabalho efetivo necessário para completar as suas atividades. O uso inadequado do prazo compromete a qualidade do projeto. É importante que o projetista tenha idéia da jornada que irá percorrer antes de dar o primeiro passo.

Muitas vezes, em projetos mal planejados, as interfaces acabam "dando cria". Quando ocorre esse fenômeno, Uma tela pode virar duas, três ou mais. Seu projeto cresce em progressão assustadora, e o seu prazo, normalmente permanece fixo.

Para não haver comida de bola no desenho do wireframe, os sitegramas são artefatos de entrada fundamentais. Eles permitem planejar o desenho do wireframe para que ele ocorra sem atropelos.

Aqui nesse site tem algum material sobre o Vocabulário Visual de Jesse James Garrett, que é uma alternativa que cumpre muito bem essa coisa de se ter um padrão bacana para desenho de sitegramas.

b) Diferença de nível de detalhamento entre Interfaces (inconsistência no detalhe)

Ainda na onda da falta de noção do tamanho do projeto, muitas vezes encontramos em Wireframes uma discrepância no nível de detalhamento entre as telas. Não estou entrando no mérito se o Wireframe deve ser simples ou complexo. Estou apenas clamando pela busca da consistência em um mesmo documento, nesse primeiro momento. As interfaces que têm a mesma importância devem ter níveis de detalhamento similares.

Em alguns documentos que já recebi, os projetistas detalham muito bem as primeiras telas e fazem as últimas na correria. Isso dá um resultado terrível em todos os sentidos e ainda gera retrabalho para as outras equipes envolvidas.

Esse tipo de ocorrência deve ser evitada. Wireframes consistentes são bons também porque podem interceptar mais falhas na fase inicial dos projetos. Se as coisas são feitas na correria, o Wireframe pode até atrapalhar mais do que ajudar. Para dar tudo certo, o projetista precisa estar muito comprometido com a qualidade do trabalho

c) Ausência de telas importantes no projeto (cadê a interface?)

Eis que alguém em determinado ponto dá falta de uma tela. E isso foi notado somente lá na etapa de codificação... Aí já era: Paramos o trabalho de desenvolvimento e chamamos o prototipador para dar vida ao que foi esquecido.

As maiores vítimas da síndrome do "Esqueceram de Mim" são as telas de fluxo alternativo dos projetos. Entendamos como "fluxo alternativo" nesse contexto tudo que trata exceções ou desvios enquanto o usuário realiza uma tarefa qualquer pela interface.

Bons exemplos de esquecimento são caixas de diálogo, interfaces de erro, tratamento de entidades de apoio, operações secundárias, interfaces de confirmação para operações e outras coisas mais.

A solução de Garrett - já citada na letra "a)" - permite um belo tratamento dos fluxos alternativos de navegação. Isso estimula o projetista a pensar nisso numa visão mais holística do projeto, antes de entrar no detalhe de cada tela.

É isso, obrigado e continue a leitura no próximo texto, que fala sobre a capacidade de manutenção rápida de Wireframes.