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.
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.
Twitter
Del.icio.us
Facebook
LinkedIn
Orkut
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…
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? ;-)
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.
quanto_mais_simples_o_wireframe
_melhor.html
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.
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 :)
Concordo contigo Fabrício que se isso torna-se parte da nossa “educação” a produtividade pode crescer…