ZeroSeis | Wireframes em XHTML

Wireframes em XHTML

Ao que tudo indica, o uso do XHTML para produção de wireframes vai em breve se tornar padrão, substituindo o Visio e outros softwares gráficos, como Illustrator e InDesign.

O interessante disso é poder entregar ao designer gráfico—ou visual designer—a estrutura das páginas pronta (com e classes, DIVs e IDs definidos). Assim ele trabalha de uma forma parecida com o que se faz no CSS Zen Garden. Ao mesmo tempo, a parte de programação server-side também pode começar a ser desenvolvida.

Gene Smith dá uma breve introdução e no Boxes and Arrows um artigo maior fala sobre o assunto.

Tags: wireframes, arquitetura da informação, xhtml

Update (28/06/2006): Finalmente encontrei o link que desencadeou esse post. É uma apresentação feita por Christina Wodtke e Nate Koechley na conferência Webvisions 2004.

Comentários

Não é assim tão simples, arquitetos da informação normalmente não sabem HTML, na minha opinião nem precisam saber, o escopo de conhecimento deles precisa ser muito mais abstrato, menos técnico.

O mesmo com designers, que precisam saber tudo, menos a especificação do CSS 2 na ponta da língua.

Saber montar XHTML + CSS é tarefa do profissional que onde eu trabalho se chama “interface”, meu cargo, um meio-de-campo entre o Designer e o Engenheiro.

É exatamente por isso que o trabalho pode ficar bem dividido e cada um cuida de uma parte específica do desenvolvimento, normalmente gerando uma qualidade-final bem maior.

É lógico que esta regra não é absoluta e nem todas empresas podem destacar uma equipe de 10 profissionais altamente especializados para desenvolver um site que no final vai render 2000 reais…

Bom, esse é o workflow atual da sua empresa. Lembre-se como essa nossa área de atuação é dinâmica e como surgem novas formas de se organizar e trabalhar.

Se o arquiteto da informação sabe rotular o conteúdo, organizar e representar tudo no Visio ou InDesign (que tivemos que aprender um dia), porquê não aprender marcação XHTML—que não é difícil—e eliminar ou, pelo menos, adiantar uma etapa do processo?

Se você der uma olhada no Google, verá que são os próprios AIs que estão propondo isso (vi na internet uma apresentação excelente—um Powerpoint talvez—, mas não consegui reencontrá-la).

Claro que não é unanimidade, mas por tudo que já li por aí, esse é o caminho. Também não acho que se aplique a qualquer projeto, talvez não valha a pena para projetos muito pequenos.

Quem vai mostrar qual de nós está certo é o tempo e o mercado.

Quer apostar? ;-)

Eu acabei de terminar a concepção dos wireframes de uma aplicação enorme. São 250 ecrãs que foram desenvolvidos usando o OmniGraffle. No total, foram 2 semanas de desenvolvimento e validação de protótipos.

Se eu tivesse concebido os wireframes em XHTML provavelmente ainda deveria ir a meio dos ecrãs. O desenvolvimento em XHTML é mais lento porque é necessário programar enquanto que no OmniGraffle (ou Visio) basta arrastar os objectos.

É claro que no futuro se os wireframes estivessem em XHTML seria muito mais rápido fazer o desenvolvimento da aplicação, no entanto há prazos que têm que ser cumpridos nesta fase inicial (nem todos os clientes estão conscientes da importância da fase de análise e os prazos normalmente são curtos) e como tal é necessário encontrar uma forma de apresentar as páginas de forma rápida e facilmente alterável.

Será que tal metodologia não acaba restringindo o poder de criação do branding designer? Alias, esse é um dos riscos apresentados pelo Leonardo Oliveira no Webinsider e discutido mais profundamente pelo Fred http://www.usabilidoido.com.br/
quanto_mais_simples_o_wireframe
_melhor.html

Ivo: acredito que apesar da criação dos wireframes talvez demorar mais, reduz-se o tempo gasto nas etapas seguintes, como você mesmo disse. Acho que é uma questão de adaptação na hora de fazer o cronograma. Se a princípio começarmos a fazer desta forma em projetos menores para ganhar experiência, talvez dê para aplicar o método em projetos maiores no futuro.

Eu confesso que não sou um expert no assunto e estou falando sem ter experimentado. Neste post tentei somente relatar o que tenho lido por aí.

Eduardo: na verdade essa metodologia dá mais liberdade ao visual designer que o processo de wireframe no papel. O arquiteto da informação coloca os elementos no XHTML em ordem de importância e com classes e IDs definidos semanticamente, sem nenhuma referência a aparência.

Sem falar que não deve ser um processo “engessado”. O designer gráfico deve poder ajudar e dar opinião na produção dos wireframes, que também podem sofrer alterações na hora da produção do CSS.

Alguns arquitetos da informação já faziam wireframes com esse conceito, mas ainda no papel, apresentando somente os elementos que iriam entrar em cada tela. Dan Brown chamou de “page description diagram” num artigo do Boxes and Arrows.

Recentemente também escrevi um artigo sobre wireframes no meu blog e reparei que nos comentários, tal como aqui, parece que se dá mais importância ao trabalho do designer gráfico do que às funcionalidades presentes no wireframe.

No meu ponto de vista o wireframe serve para testar se as funcionalidades servem para colmatar as necessidades dos utilizadores e não para facilitar a vida ao designer. O ponto principal do wireframe é saber se os passos e os ecrãs apresentados têm a informação correcta para o utilizador e se essa informação é suficiente para ele desempenhar a sua tarefa de forma mais eficiente e produtiva.

Quanto aos designers, só depois de termos os wireframes aprovados é que vamos começar a pensar em layouts gráficos…

Enfim, este é o meu ponto de vista de ergonomista :)

Muito muito interessante. O curioso é que eu já fiz alguns testes de wireframe em XHTML antes de ler sobre isso. Como eu o faço o trabalho de “arquiteto da informação” ao mesmo tempo que o de design (Leiam Rosenfeld e Morville), e se sou eu que mapeio os processos de criação e se também sou eu que crio bibliotecas modulares de código que podem ser reaproveitados (embeded), wireframes ficam muito mais fáceis de serem feitos e utilizados no produto final.

Concordo contigo Fabrício que se isso torna-se parte da nossa “educação” a produtividade pode crescer…