Webdesign Experience é o blog de Talita Pagani sobre experiências e pensamentos envolvendo desenvolvimento web. Talita é designer de interfaces e programadora web há 3 anos. Reside em Bauru/SP, onde cursa Ciência da Computação na USC e trabalha em uma empresa de desenvolvimento web. Além disso é colunista do Outrolado.
Todos que têm alguma experiência com Arquitetura de Informação e/ou Design de Interface sabem o quão difícil é planejar e documentar uma interface para comunicar as especificações à equipe de desenvolvimento. O fato é que esta documentação por vezes é difícil compreensão por quem precisa lê-la e interpretá-la, por ser muito extensa e cansativa.
Longe de propor um modelo metodológico complexo, recheado de diferentes diagramas de textos de especificação (casos de uso, especificações funcionais, storyboards, etc), o modelo apresentado aqui é principalmente voltado para profissionais independentes e pequenas equipes de desenvolvimento, que necessitam uma documentação consistente, de fácil compreensão, mas, ao mesmo tempo, técnica o suficiente.
Não há como fugir deste tipo de diagrama. Os sitemaps, elaborados durante a etapa de planejamento, assemelham-se ao formato de organogramas e sua função é definir a hierarquia, os níveis, a estrutura e a interligação entre páginas, sinalizando também os caminhos de navegação e elucidando a organização lógica entre as páginas e seções. A esta tarefa é comumente atribuído o nome de Macro-arquitetura de Informação e que pode ser elaborada conjuntamente com o cliente. O problema é que, em muitos casos, estes documentos apenas indicam a estrutura de páginas que os usuários encontrarão. O ideal é possuir também um sitemap com a estrutura de diretórios do site, informando onde encontrarão, por exemplo, diretório de imagens, scripts, códigos reutilizáveis (includes), entre outros, sendo diferente do mapa do site convencional. Ambos os documentos ajudam novos integrantes a se localizar e encontrar mais facilmente os caminhos de navegação e arquivos específicos, servindo também como referência para quem trabalha no projeto a mais tempo. (Exemplo)
Partindo do princípio de que imagens falam mais do que palavras, estes diagramas ajudam a ter uma visão objetiva da estrutura da interface, disposição dos elementos e da Arquitetura de Informação propriamente dita.
São subdivididos em três diagramas que compõem três camadas e são ligeiramente baseados no diagramas de camadas de Jesse James Garrett:
Esta metodologia, livremente baseada em alguns aspectos do artigo de Garrett Dimon, não é absoluta nem definitiva, mas com certeza oferece um bom embasamento sobre uma prática que começa a ganhar um destaque maior entre os designers de interface. Produzi um exemplo, baseado no documento da Information & Design, que pode ser adaptado livremente e possui os exemplos citados acima (com exceção do Diagrama Estrutural preenchido).
Para concluir esta parte da série, podemos dizer que documentações densas e detalhadamente explanadas tornam-se necessárias em dois momentos:
Muitas vezes, um documento que se prolonga demasiadamente em suas especificações tende a não se tornar útil, pois não facilita a busca de informações práticas e objetivas. Para quem desenvolve uma documentação deste porte sem a total necessidade, isto torna-se uma experiência traumática.
No próximo artigo, irei abordar um padrão para documentação de código, o CSSDoc.
Referências:
Documenting Interface Design - Garret Dimon
Information & Design - Documeting User Interface
Extras:
Stencils de Nick Finck para a construção de wireframes e sitemaps
Templates para a construção de wireframes (Visio e Omnigraffle)
:)
Nenhuma pessoa ainda comentou o post.
Na Engenharia de Software, a documentação é compreendida como parte integrante do software e consiste, basicamente, em dois tipos de documentos: o manual do usuário, contendo instruções de como utilizar o sistema, screenshots das telas e operações, etc, sendo geralmente produzido após o término do desenvolvimento; e o manual do sistema, contendo as especificações técnicas, a modelagem do sistema, modelagem de dados, entre outros, sendo construído a partir do planejamento e da análise do sistema, podendo ser complementado ao longo do desenvolvimento, uma vez que será como um guia para a equipe durante a produção e mesmo quando houverem manutenções no sistema.
Os Arquitetos de Software possuem todo o embasamento para escrever estes documentos. Inclusive, há uma linguagem de notação padronizada para escrever diversos diagramas do sistema, a conhecida UML (Unified Modeling Language).
Entretanto, o desenvolvimento para a web trouxe novos paradigmas desafiadores para a Engenharia de Software. Entre eles, a crescente preocupação com o desenvolvimento de interfaces intuitivas, usáveis, de fácil interação e aprendizado, fazendo com que designers de interface, arquitetos de informação, engenheiros de usabilidade e outros profissionais correlacionados tenham papel-chave no desenvolvimento de aplicações web.
Semelhantemente ao desenvolvimento de um software desktop, as aplicações web também devem seguir uma metodologia para a documentação do sistema, mas agora incluindo também os documentos de interface. Há muitas pesquisas e artigos nesta área, mas ainda falta uma metodologia unificada para escrever este tipo de documento, que faz parte de um processo muito trabalhoso.
Partindo desta premissa, nesta série de artigos pretendo, em um primeiro momento, explorar os motivos para se documentar uma interface e, depois, compartilhar a [simples] metodologia que tenho utilizado atualmente, mesclando padrões propostos por diversos especialistas a outros que desenvolvi através de análises empíricas.
Para alguns profissionais, este tipo de documentação é considerada desnecessária, custosa e, até mesmo, perda de tempo que pode comprometer a produtividade. Mas ao planejar e documentar uma interface, consegue-se traçar um plano de desenvolvimento e definir como aquela interface será desenvolvida. Em uma equipe multidisciplinar, isso significa obter ganho de produtividade, uma vez que será evitado o retrabalho e o gasto excessivo de tempo para abstrair o conceito da interface. Além disso, os wireframes ajudam o designer a visualizar melhor a organização da interface e a definir primariamente diversos aspectos de usabilidade. Outra forte característica é que este documento é capaz de comunicar a qualquer outro membro da equipe (programador, gerente de projeto, etc) como a interface da aplicação está sendo projetada.
Adaptando um slide sobre Documentação de Software, da Carnegie-Mellon University, durante o desenvolvimento de um software nós:
A arquitetura de interface serve como uma plante para o site a ser criado:
A documentação responde pela arquitetura hoje, amanhã e daqui a alguns anos.
No próximo artigo, irei mostrar uma metologia de documentação que pode ser facilmente aplicada, principalmente entre freelancer e pequenas equipes.
Referências:
Documenting Interface Design - Garret Dimon
Mini-Curso: Como Documentar Arquitetura de
Software - Paulo Merson
:)
Nenhuma pessoa ainda comentou o post.
O site Lista de Hotéis, projeto desenvolvido pela Arca Solutions (empresa em que atuo), lançou sua nova versão e gostaria de convidar a todos para dar uma conferida. O novo design - mais clean, como novo logo e maior usabilidade - ficou a cargo de meu colega André Garcia que, em minha opinião, fez um excelente trabalho, sem contar, claro, os esforços dos desenvolvedores, gerentes de projetos e QAs.
O Lista de Hotéis é um site de abrangência nacional que possui listagens de hotéis do Brasil todo. Foi desenvolvido com o software eDirectory e é integrado ao Hoteli - Sistemas de Reservas Online (ambos desenvolvidos pela Arca Solutions). O visitante pode encontrar diversas informações sobre o hotel que está procurando, tais como endereço, produtos/serviços, galeria de fotos, vídeo, localização no GoogleMaps, ir diretamente para o site de reservas, além de poder criar uma lista com os hotéis favoritos e comentar o hotel.
Até mais, pessoal :)
1 pessoa comentou o post até agora.
Site no ar, tudo perfeito e funcionando. Este é o último artigo da série e que irá abordar a etapa de produção, onde tudo o que foi planejado, estruturado e conceitualizado torna-se concreto. E até mesmo para quem está trabalhando para si próprio pode encontrar alguns problemas no desenvolvimento que pode desagradar o lado "cliente".
Uma das grandes mudanças que fiz nesta reformulação do site foi a estrutura de diretórios. Antigamente, o site possuía apenas a pasta imagens e o restante (arquivos css, js, páginas de includes, etc) localizavam-se na raiz, o que muitas vezes dificultava encontrar certos arquivos. Desta vez, separei da seguinte forma: arquivos principais na raiz e depois os sub-diretórios imagens, css, scripts, includes e galerias. Quando estou trabalhando no DreamWeaver, a diferença que esta organização trouxe foi significativa. Para quem trabalha com uma equipe de desenvolvimento, seja grande ou pequena, esta é uma boa prática que interfere diretamente na produtividade.
Com o auxílio de alguns recursos de programação, consegui otimizar a SEO, utilizando, por exemplo, títulos, palavras-chaves e descrições distintas para cada página. A aplicação da semântica e o seguimento mais rigoroso dos padrões web também tornou o conteúdo otimizado para os mecanismos de busca.
Editar, excluir, reescrever. Tive um grande trabalho revisando o conteúdo do site e excluindo algumas seções. Com o auxílio de algumas recomendações de webwriting, usabilidade e a reforma da diagramação, as informações estão mais completas, precisas e melhor distribuídas.
Cronogramas podem impedir certas realizações, mesmo quando o trabalho é feito para si próprio. Uma das coisas que não consegui fazer foi tornar dinâmico o conteúdo principal, ou seja, retornar do banco de dados e permitir que seja alterados através de um novo módulo no painel administrativo. O sitemap.xml, arquivo útil para o Google, também foi algo que acabei não implementando por enquanto.
O próximo passo agora é a pós-produção, ou seja, monitorar as estatísticas, mensurar os resultados provenientes desde a reformulação e planejar os ajustes que podem ser feitos para melhorar o site.
:)
1 pessoa comentou o post até agora.
Passadas as festas de fim de ano, era hora de voltar ao trabalho e comecei o ano com as energias renovadas para realizar novos projetos. E foi com esse espírito de "ano novo, vida nova" que resolvi reformular o blog e concluir o redesign do meu portifólio. Resolvi fazer um layout mais moderno e projetado para resoluções de, no mínimo, 1024x768 (resoluções utilizadas por cerca de 90% dos visitantes), o que facilitou a distribuição do conteúdo. Algumas coisinhas faltaram, mas virão com o tempo. Espero que todos aprovem o novo layout e dêem suas opiniões.
Ah, antes de concluir o post, gostaria de comunicar que em janeiro iniciei como colunista do Outrolado, um projeto do Webinsider que funciona como uma comunidade onde as pessoas podem publicar seus artigos.
Bom, pessoal, por enquanto é só :)
5 pessoas comentaram o post até agora.
Feliz Natal a todos e muito obrigada aos amigos, colegas e colaboradores que me ajudaram durante este ano. Se 2007 foi bom, 2008 será melhor ainda, inclusive para nós, profissionais de internet. Falando nisso, aqui vai uma "previsão" para o ano que se aproxima:
"Em 2008, dispositivos móveis vão superar computadores de mesa no acesso à internet."
Revista WebDesign, novembro/2006
Pois é, vamos começar a pensar nisso.
Boas festas :)
Nenhuma pessoa ainda comentou o post.
Isso é apenas uma curiosidade. Hoje em dia, os designers têm mais liberdade para utilizar qualquer cor hexadecimal na hora de desenvolver projetos web, mas quando é necessário trabalhar apenas com cores seguras para a web, é possível converter qualquer cor não-websafe sem utilizar ferramenta alguma e de modo fácil.
Elas são formadas apenas por números múltiplos de 3: 0, 3, 6, 9, C, F.
A principal característica das cores web-safe é que cada par hexadecimal é formado por valores iguais. Sendo assim, F76500 não é web-safe pois, F7 e 65 são pares com valores diferentes, então, neste caso, o certo seria FF6600.
O primeiro valor de cada par é que determinará o valor daquele par:
F7 85 13
Depois é só converter por aproximação:
Portanto, os valores da cor de exemplo seriam FF9900. Como o F já é um valor para web-safe, foi substituir o 7 por F. Simples, não?
Isso é que é falta do que fazer, rs :)
1 pessoa comentou o post até agora.
...e vice-versa. Apesar de muitos profissionais web associarem acessibilidade e usabilidade, ela têm pontos em comum mas não são a mesma coisa e ambas são fundamentais no sucesso de um website. Ao realizar o primeiro acesso a um serviço de internet banking de um determinado banco, o site apontava claramente no topo que era acessível a deficientes visuais. Hoje eu já me acostumei com a interface, mas no primeiro dia em que acessei não consegui encontrar o local onde deveria entrar com os dados para acessar minha conta. Depois, o teclado virtual encontra-se no contraste mínimo e quase não conseguia ver os números. Por fim, não entendi o que deveria ser preenchido em um campo e não encontrei a informação no tópico de "Ajuda". O que eu fiz? Desisti. Voltei no dia seguinte e só então consegui acessar o sistema. O campo que eu não sabia como preencher tinha uma sumária explicação no tópico de "Ajuda", mas não estava destacado e nem tampouco separado de outras informações. A acessibilidade pode ter falhado em alguns pontos, mas a usabilidade mais ainda.
Um site é acessível quando permite que pessoas acessem o conteúdo por outros métodos que não sejam o mouse; quando possui um bom contraste entre fundo e texto; utiliza fontes de tamanho razoável; utiliza o mínimo de imagens possível e, quando as utiliza, insere um texto alternativo; utiliza o mínimo de scripts em eventos intrínsecos que são só podem ser acessados com o mouse (onclick, onmouseover, etc); prove teclas de acessos para determinados links, dentre muitos outros fatores. Em suma, é fazer com que um site possa ser utilizado por pessoas com diferentes limitações e dispositivos.
Mas um site somente é usável se atende às expectativas do que o usuário necessita; não deixa dúvidas sobre como deve prosseguir na realização das tarefas; não o faz parar e pensar sobre a interface, com se tivesse que decifrá-la; oferece informações claras e concisas, provê boa comunicabilidade e feedback sobre as ações realizadas; e, se o usuário recorre à ajuda, deve obter respostas objetivas. Então, basicamente: deve ser de facilmente aprendida e memorizada e orientar o usuário na realização de tarefas.
O tema é amplo e poderia detalhar cada um destes tópicos, mas acredito que estes conceitos expostos já são suficientes para fazer refletir.
A lição que podemos tirar é de que: um site pode ter elementos acessíveis a deficientes visuais, mas possuir uma interface difícil de ser utilizada, que não mostra claramente o que o usuário deve fazer e como fazer, seja ele portador de deficiência ou não. Entretanto, uma interface pode ter de fácil utilização mas que não seja acessível se o usuário utilizar um dispositivo ou browser diferente (como o Lynx).
:)
Nenhuma pessoa ainda comentou o post.
Depois de definir a arquitetura de informação do novo site, é hora de passar para a etapa de design e criação de protótipos. De uns meses para cá, adquiri uma metodologia de trabalho mais rigorosa - graças ao curso da Arteccom - e isso me fez repensar o modo como estava conduzindo o desenvolvimento do redesign.
Até chegar à versão atual, passei por vários estágios ao longo destes 5 meses. O mais interessante de tudo é que muitas idéias surgiram ou amadureceram durante a produção da interface, o que mostra que nem sempre o planejamento inicial é capaz de definir de modo absoluto o andamento do projeto do início ao término.
Na nova versão do site, resolvi mudar o foco e fiz um planejamento completamente distinto, refletindo sobre mudanças que vão desde a resolução de tela escolhida até o conteúdo. Foi como fazer um novo briefing: redefinir conceitos, metas e estratégias. Para começar, o site terá como objetivo ser um meio de divulgação de meus trabalhos e dos meus conhecimentos para outros profissionais da área e não para captar clientes. Esta mudança influenciou no design gráfico, na arquitetura de informação e na produção de conteúdo.
Esta, para mim, é uma das etapas mais complicadas: transformar os conceitos abstratos em idéias concretas. O brainstorming - técnica em que, a partir de um tema devemos buscar várias idéias relacionadas de forma rápida e instantânea, como uma tempestade de idéias - ajudou bastante neste processo. A principal idéia era fazer um design que fosse, ao mesmo tempo, impactante, clean, de boa navegabilidade e com um toque de delicadeza e surrealismo. Difícil, não?
Depois de vários meses e muitos PSDs não finalizados, consegui encontrar uma idéia que me agradou (posteriormente vou postar o layout final). E agora restava pensar na diagramação.
Acho que eu nunca segui um grid tão à risca quanto agora :). Diagramar, ou seja, distribuir o conteúdo uniformemente na página, está diretamente relacionado com arquitetura de informação e usabilidade, pois a organização dos elementos deve prover uma navegação intuitiva (guiar os olhos do usuário), priorizar o conteúdo de maior relevância, tornar a composição visual legível, agradável e hierarquizar a informação. Dessa forma, adotei as seguintes medidas: na página inicial, priorizei a visualização dos trabalhos mais recentes, dos últimos posts do blog e uma pequena apresentação minha; nas páginas internas, dividi o conteúdo principal em duas colunas para facilitar a leitura e encurar a rolagem. A coluna à direita será reservada para outras informações secundárias ou relacionadas.
Bom, este foi apenas um pequeno relato do que venho desenvolvendo. Uma das maiores lições que se pode tirar é que durante o processo de design podem surgir as questões mais pertinentes que influenciarão a produção das etapas seguintes. Algumas coisas nem sempre são possíveis de serem vistas em um briefing ou em um wireframe (isso varia de projeto para projeto, não é uma regra).
Até a próxima (ainda haverá post antes do Natal)!
:)
2 pessoas comentaram o post até agora.
Semana passada, assisti no trabalho à apresentação de um colega e ele comentou sobre algumas implicações que o AJAX traz para a usabilidade, um assunto sobre o qual "ensaiando" a meses para escrever, mas antes tarde do que nunca :)
Não há dúvidas de que o AJAX tem sido um dos recursos mais utilizados atualmente no desenvolvimento de WebApps, sendo inclusive uma das tecnologias-símbolo da ainda tão comentada Web 2.0. O problema é que muitos desenvolvedores, tomados pela empolgação, têm utilizado em demasia e com falta de bom senso. A consequência deste uso mal planejado são inúmeras interfaces com graves problemas de usabilidade (sejam novos ou antigos).
Vale lembrar que existem aplicações fantásticas e inteligentes com o uso do AJAX. Quando realiza cadastro no site Remember the Milk, era verificada a disponibilidade do username automaticamente, sem demora e sem recarregar a página (aliás, este site tem outras boas aplicações do AJAX). Os sites Letras.mus.br e Vagalume exibem a lista de músicas ou artistas disponíveis conforme é digitado no campo de busca. E há muitos outros exemplos por aí.
Não é, portanto, uma crítica ao AJAX, afinal ele aproximou as aplicações web das aplicações desktop, em termos de agilidade e eficiência, mas sim uma intenção de fazer com que todos os desenvolvedores que têm grande interesse nesta técnica (assim como eu) concentrem seus esforços mais na usabilidade e menos em pensamentos hype
:)
2 pessoas comentaram o post até agora.
Nossa, quanto tempo sem atualizações! Estou há alguns meses sem tempo para postar por conta dos trabalhos de faculdade (universitários sofrem, rs). Mas não é somente isso. Durante este período iniciei o curso Web Para Designers, promovido pela Arteccom. O curso é online e conceitual, ou seja, não aborda o uso de ferramentas e linguagens, mas sim os vários conceitos que abrangem o desenvolvimento de websites, especificamente na área de design. O material é ótimo e os exercícios práticos são bem desafiadores, uma experiência - ótima, por sinal - à parte. Para mim, o trabalho mais interessante foi desenvolver uma lista de tarefas para avaliar a usabilidade de um site e aplicar estes testes em usuários. Foi realmente uma experiência curiosa e enriquecedora, pude perceber o quão árdua e complexa é a função do orientador de teste de usabilidade, pois é de grande responsabilidade, afinal, o orientador precisa passar segurança aos usuários, tranquilizá-los a todo momento para que não se sintam "burros" - o que, de fato, não são - ao não conseguir realizar uma tarefa, lembrá-los de que quem está sendo avaliado o site e não eles e, por fim, paciência para orientá-los, pois eles podem esquecer o que deve ser realizado. Tiro o chapéu a todos os engenheiros de usabilidade e orientadores de testes.
Ah, sim, e não poderia esquecer: estive participando da 9ª Jornada de Informática, da UNESP-Bauru, e no dia 23 assisti a palestra do Elcio Ferreira, sobre o tema "Web 2.0, semântica e microformats" e foi simplesmente excelente. Sobre Web 2.0, Elcio disse que usou o tema apenas como "uma isca" para atrai o público, mas não fez falta, como ele mesmo avisou no antes de iniciar palestras. Os participantes, em sua maioria, eram alunos de BSI e BCC e haviam apenas 2 alunos que eram de cursos de design, mas mal sabia ele que haviam alguns designers camuflados nos cursos de informática (eu era uma, rs). Com uma abordagem objetiva e bem-humorada, Elcio explicou desde o surgimento do HTML e dos padrões web propostos pela W3C (que antigamente eram apenas recomendações) até o conceito e aplicações dos microformats, além de semântica, web semântica, RSS, podcasts, as transformações no processo de desenvolvimento web com a consolidação dos padrões, enfim, tantos assuntos que fica quase impossível comentar sobre tudo neste post.
Bom, ficam aí as dicas então ;)
1 pessoa comentou o post até agora.
Há alguns dias, fazendo testes de aplicação de estilos para input button/submit, descobri sem querer como voltar o estilo default dos botões por CSS, no Firefox, como mostra a imagem abaixo:

Não sei se alguém já conhecia esta regra, mas achei bem curiosa e diferente. Para falar a verdade, tive que testar em outro documento em branco para acreditar no que estava vendo.
Vou citar um exemplo simples: suponha que você tenha a seguinte regra CSS e o HTML correspondente:
/* CSS */
input {border:1px solid #CCC;}
/* HTML */
<input type="text" name="campotexto" />
<input type="submit" value="Enviar" />
Nesse caso, ele aplica uma borda para todos os inputs, text, radio, submit, etc... O botão ficaria igual ao da imagem acima, do lado esquerdo. Mas, se você deseja que o botão submit tenha o estilo default, basta criar uma classe com a regra:
/* CSS */
input {border:1px solid #CCC;}
.botao {border:2px outset #E0DFE3;}
/* HTML */
<input type="text" name="campotexto" />
<input type="submit" value="Enviar" class="botao" />
É uma pena que funciona somente no Firefox. A cor #E0DFE3 é default de qualquer input button/submit/reset. Neste caso, eu obtive a cor quando coloquei a borda no input sem modificar o background. Bom, o CSS surpreende a cada dia mesmo.
:)
1 pessoa comentou o post até agora.
Para quem está começando ou já utiliza CSS há algum tempo sabe que a tarefa nem sempre é tão fácil. Trabalhando com CSS há dois anos, aprendi muitas coisas com a prática, com as consultas ao Oráculo e a troca de experiência com colegas e posso dizer que já estou bem "cascuda" para lidar com os seletores. Conversando com colegas, percebi que alguns, iniciantes ou com um pouco mais de prática, têm dificuldades em aplicar os estilos e fazer eles funcionarem corretamente no IError Internet Explorer, Firefox e outros browsers, o que muitas vezes ocasiona o uso de hacks indevidos ou fazem com não seja explorado todo o potencial do CSS. Por isso eu resolvi listar algumas "CSS Tips and Tricks" simples.
Evite declarações como estas em sua folha de estilos:
p {...}
a {...}
.titulo {...}
Declarações "globais" como estas podem gerar conflitos quando você necessitar de um estilo diferente para este seletor. Isso pode fazer com que você tenha que forçar a nova regra com o !important, mas esta não é uma melhor prática. O recomendado é utilizar um seletor contextual, onde o estilo será aplicado somente se o seletor estiver dentro daquele contexto, ou como digo também, hierarquia:
/*Toda tag p que estive em geral > conteudo*/
div.geral div.conteudo p
{font:normal 14px Arial,Helvetica,sans-serif;}
/*Toda tag p que estiver dentro de geral >
conteudo > principal*/
div.geral div.conteudo div.principal p
{font-size:12px;}
/*Toda tag p que estiver dentro de geral >
conteudo > cont_relacionado*/
div.geral div.conteudo div.cont_relacionado p
{font-size:12px;}
/*Qualquer elemento com o seletor titulo
que esteja em geral > conteudo*/
div.geral div.conteudo *.titulo
{font:bold 14px Arial,Helvetica,sans-serif; color:#CC0000;}
Esta aplicação poupa a definição de muitos seletores e evita conflitos.
Sempre tive muito o hábito de utilizar id no css, não para todos os elementos obviamente, mas para algumas divisões do site. Vale ressaltar que a diferença básica entre classe e id é que as classes são definições que podem ser utilizadas por mais de um elemento na mesma página enquanto o id constitui uma definição/identificação única e só pode ser utilizada para apenas um elemento. Com a experiência e dicas de colegas aprendi a utilizar mais as classes do que os IDs. Isso porque os IDs oferecem menos liberdade para a utilização e como melhor prática é mais aconselhável aplicá-los a elementos que serão manipulados por javascript ou elementos únicos em uma página como geral, header, conteudo e footer.
Sim, é possível e válido aplicar mais de um seletor a um elemento. Suponha que você tenha o seletor .textoDestaque aplicado a um elemento qualquer no HTML para várias chamadas de destaque em uma página, uma abaixo da outra. O seletor define uma border-bottom:1px solid #CCC, mas você não deseja esta formatação no último elemento. Ao invés de utilizar um style="border-bottom:none;", crie uma nova classe como .noBorder:
<p class="textoDestaque noBorder"></p>
Funciona tanto no Internet Explorer quanto no Firefox e evita o uso de estilo inline.
Bom, este post seria extenso se conseguisse lembrar muitas outras recomendações, mas estas simples soluções já fazem a diferença.
Link brinde: 70 dicas para escrever CSS.
:)
3 pessoas comentaram o post até agora.
Há algum tempo iniciei o redesign do meu site e tem sido interessante perceber a importância deste processo para rever conteúdo, contexto e organização do site. O redesign não é feito somente com a intenção de melhorar o layout, o design gráfico ou acrescentar/remover conteúdo, a tarefa é mais abrangente. Como já havia lido no livro de Felipe Memória, é quando o site está no ar que podemos validar - e avaliar - tudo o que foi elaborado para o site, colhendo o feedback das pessoas para o processo de redesign. Por isso gostaria de comentar algumas coisas que tenho feito (e aprendido) durante esta etapa de desenvolvimento.
Foi através da análise de métricas do Google Analytics que percebi algumas falhas na arquitetura de informação, tanto em termos de definição de conteúdo quanto peso dos elementos colocados na página inicial. As informações do home não estavam distribuídas de modo que correspondesse às tarefas das pessoas no site (conhecer o portifólio, ver o currículo e os serviços, em ordem de relevância). Conclui também que algumas páginas são irrelevantes e deverão sair da próxima versão do site. A melhor parte foi refazer o wireframe (como sempre digo, a prática leva à perfeição).
Como o site é simples, não existem muitas tarefas complexas a serem realizadas, mas alguns pontos de usabilidade podem ser melhorados. Uma idéia que estava pensando e que também foi sugerida por um web designer que entrou em contato comigo* foi a de diferenciar o item do menu quando a pessoa estiver na página. Simples, mas funciona. Não só a usabilidade, mas a acessibilidade também deverá ser melhorada.
Otimizar o site para os mecanismos de busca não é importante somente para melhorar o posicionamento nos mesmos. Através das diretrizes de SEO acabamos por desenvolver códigos mais semânticos e até mesmo acessíveis.
Pois é, nem todos são perfeitos e eu, ainda como estudante, também cometo alguns (ou vários) erros. Mas é com estes enganos que se aprende. Um dos erros que cometi foi desenvolver o wireframe e partir imediatamente para o protótipo. O que aconteceu foi que eu tive outras idéias para a arquitetura de informação e resolvi aplicá-las no protótipo do design, ao invés de modificar o wireframe e ter certeza de que aquele documento seria definitivo. Portanto: enquanto o wireframe não estiver 100% definido e validado, não parta para a prototipação.
Durante este processo, vou estar compartilhando no blog o que tem sido feito e estou aberta à sugestões dos colegas. :)
* Thanks to Helton Ritter
2 pessoas comentaram o post até agora.
Novamente volto a falar sobre SEO, desta vez para mostrar o resultado de uma pesquisa feita por uma companhia alemã chamada Sistrix, uma empresa que desenvolve projetos para a internet. Os resultados são interessantes e ajudam a reforçar ou desmistificar algumas teorias sobre a otimização de sites para os sistemas de busca.
Abaixo, segue a tradução que fiz do artigo, que pode ser conferido na íntegra no site Axandra.
A empresa alemã Sistrix analisou os elementos de web pages do topo das páginas posicionadas no Google para encontrar quais elementos conduzem aos rankings elevados no Google. Eles analisaram 10.000 palavras-chaves aleatórias e, para cada palavra-chave, analisaram as 100 que se encontravam no topo dos resultados de busca.
Quais elementos de uma página levam aos rankings elevados do Google?
A Sistrix analisou a influência dos seguintes elementos das páginas: título da página, corpo da página, tags de cabeçalho/título, tags bold e strong, nomes de arquivos de imagens, texto alternativo de imagens (alt), nome do domínio, caminho, parâmetros, tamanho do arquivo, links que levam ao site e PageRank.
- Palavras-chaves na tag title parecem ser mais importantes para os posicionamentos elevados no Google. É também importante que as palavras-chaves de alvo estejam mencionadas na tag body, embora a tag title pareça ser mais importante.
- Palavras-chaves nas tags H2-H6 parecem ter uma influência no posicionamento enquanto que palavras-chaves na tag H1 parecem não ter efeito.
- O uso de palavras-chaves nas tags bold ou strong parecem ter um efeito insignificante no topo do ranking. Páginas que usam as palavras-chaves em nomes de imagens muitas vezes possuem posicionamentos mais elevados. O mesmo parece ser verdadade para palavras-chaves no atributo alt.
- O websites que utilizam suas palavras-chaves no nome do domínio freqüentemente têm posicionamentos mais elevados. Pode ser que estes sites possuem muitos links que levam ao site com o nome do domínio como texto do link.
- Palavras-chaves no caminho dos arquivos parecem não ter um efeito positivo no ranking do Google dos sites analisados. Páginas que usam poucos parâmetros na URL (?id=123, etc.) or nenhum parâmetro tendem a conseguir um posicionamento maior do que as URLs que contêm muitos parâmetros.
- O tamanho do arquivo parece não influenciar o posicionamento de uma página no Google embora sites menores tendêm a ter um posicionamento ligeiramente mais elevado.
- Não é surpresa que o números de links que levam ao site e o PageRank tiveram uma grande influência no posicionamento de páginas no Google. O topo dos resultados no Google têm, de modo geral, aproximadamente quatro vezes mais links que o resultado número 11.
:)
Nenhuma pessoa ainda comentou o post.
A Comunidade Brasileira Overmundo, site colaborativo que busca expandir a produção e divulgação da cultura do Brasil no digimundo, ganhou o prêmio mais importante do Prix Ars Electronica 2007, o Golden Nica, na categoria Comunidades Digitais.
Este é o primeiro projeto brasileiro a vencer a premiação, considerada um Oscar dos projetos de tecnologia, artes e sociedade, que existe desde 1987.
Para se ter uma idéia da responsa dos brasucas, a Wikipédia venceu a mesma categoria em 2004 e a premiação já teve vencedores de peso como Linus Torvalds (Linux), Industrial Light and Magic, Toy Story, Creative Commons, entre outros.
O Overmundo é uma inciativa de Alexandre Youssef, Hermano Vianna, José Marcelo Zacchi e Ronaldo Lemos. Parábens a todos da equipe e ao pessoal que está sempre colaborando.
:)
Nenhuma pessoa ainda comentou o post.
Dando continuidade à série sobre o Google Analytics, desta vez indico a série de posts escrita a alguns dias pelo Revolução Etc:
Estratégia de métricas parte 1: Métricas para ProBloggers
Estratégia de métricas parte 2: Google Analytics e a Função urchinTracker
Fica aí uma excelente dica. :)
Nenhuma pessoa ainda comentou o post.
As técnicas para otimização dos sites para sistemas de busca (SEO) tem sido requeridas por diversos sites que desejam melhorar seu posicionamento nos resultados das buscas na internet (PageRank).
Tenho estudado este assunto a algumas semanas e percebi que os padrões web e a semântica de código estão diretamente relacionadas com as técnicas de SEO. Por isso, aqui vão algumas dicas interessantes de webstandards que ajudam a indexação e o posicionamento do site.
Utilize corretamente as tags hn (h1, h2, h3) para expressar a hierarquia de títulos dos textos em uma página e insira textos relevantes entre as tags.
Certifique-se que as tags de imagem possuem o atributo alt com textos descritivos e relevantes. Além de facilitar a indexação, os deficientes visuais podem saber do que se trata a imagem.
Títulos de página devem ser únicos e estar de acordo com o conteúdo da página, além de (obviamente) serem descritivos. Este é um fator muito relevante e um dos primeiros a ser considerado ao buscar conteúdo na web.
Provenha informações sobre o seu site para auxiliar os bots. Muito cuidado com a meta-tag keywords: não tente enganar os bots utilizando palavras-chaves que não estejam relacionadas com o conteúdo do site
Estas são apenas algumas dicas, mas há muito outros aspectos das estrutura de código e conteúdo que são levados em consideração pelos mecanismos de pesquisa.
SEO: Como melhorar o ranking do site - Paulo Rodrigo, colunista do iMasters
Diretrizes para webmasters - Google
Nenhuma pessoa ainda comentou o post.
Ajude a manter a Wikipédia no ar - mesmo sem colocar a mão no bolso!
O BR-Linux.org lançou uma campanha para ajudar a Wikimedia Foundation a manter a Wikipédia no ar. Se você puder doar diretamente, é sempre a melhor opção. Mas se não puder, veja as regras da promoção do BR-Linux e ajude a divulgar - quanto mais divulgação, maior será a doação do BR-Linux, e você ainda concorre a um pen drive!
Contribua da maneira que puder para que a enciclopédia livre continue existindo.
Nenhuma pessoa ainda comentou o post.
Continuando o post sobre o uso do Google Anaytics como ferramenta de medição para a usabilidade e arquitetura de informação, hoje vou apresentar alguns relatório que o serviço disponibiliza e podem ajudar muito os profissionais envolvidos no desenvolvimento e manutenção de um website.
Eis uma ferramenta interessante para avaliar macroarquitetura de informação, fluxo de navegação e o comportamento dos usuários, de um modo geral, ao acessar um site. Este relatório mostra quais foram os caminhos de navegação feitos pelos usuários a partir de pontos principais de entrada no site, ou seja, para quais páginas os usuários normalmente seguem depois de entrar em uma determinada página. Para os arquitetos de informação, ajuda a monitorar a eficiência dos mapas de arquitetura de informação, qual é o fluxo de navegação normalmente percorrido pelos usuários e a partir de que ponto eles estão deixando o site.
É um menu da categoria Otimização de conteúdo, que contém vários relatórios. Para os analistas da usabilidade e acessibilidade, eles relatórios oferecem informações importantes sobre questões que, geralmente, causam conflitos na hora de desenvolver um projeto: qual a plataforma mais utilizada pelos usuários? qual a resolução mínima de tela? Qual a velocidade de conexão? E as versões de navegadores e plug-in dio flash? Normalmente, os profissionais web se baseiam em métricas genéricas, mais hipotéticas, geralmente encontrada na literatura especializada. Mas esta ferramenta oferece uma visão real e específica do seu projeto e é fundamental, principalmente, para os processos de manutenção e redesign.
Bem, apresentei apenas algumas ferramentas do Analytics, mas vale a pena conferir todos os recursos que ele disponibiliza. Faça um teste. Se você tem uma conta Google, inscreva seu site no Google Analytics.
:)
Nenhuma pessoa ainda comentou o post.
Combinando alguns relatórios dos mais de 50 que o serviço Google Analytics possui, é possível obter uma análise sobre a eficiência da arquitetura de informação e usabilidade. O Analytics já oferece diversos relatórios para analisar resultados de campanha de marketing e ROI, para sites integrados com o AdWords, mas esta característica das metas qualitativas é pouco comentada.
Este primeiro post é apenas uma canjinha e apresenta a ferramenta Cobertura do site.
Permite navegar pelas páginas do site e mostra a quantidade de cliques nos links internos do site. Ainda mostra a quantidade e a porcentagem de visitantes que saíram daquela página e do site sem passar pelas outras páginas.
Ajuda a saber:
No próximo post trarei análises interessantes de outras ferramentas.
Nenhuma pessoa ainda comentou o post.
Enfim, atendendo a pedidos e antes tarde do que nunca, o WDXP agora tem feed RSS!
Depois de alguns dias quebrando a cabeça e fazendo vários testes, consegui montar um feed, mas ainda em uma versão, digamos, Beta, pois o meu blog não possui gerenciador de conteúdo à la Wordpress :(... ele é administrado pelo sistema que eu desenvolvi, que gerencia o blog e várias seções do meu site.
Se alguém tiver problemas com o feed, me comunique.
:)
3 pessoas comentaram o post até agora.
Há algumas semanas terminei de ler uma tese de doutorado na área de Engenharia de Produção, desenvolvida por Mônica Stein (Design de interface para sites: Desenvolvimento de Uma Metodologia Orientadora Considerando a Comunicação entre Clientes e Usuários, 2003, UFSC).
A tese apresenta considerações importantes sobre informação, comunicação, marketing, usabilidade, layout e gestalt, além de, claro, propor uma modelo metodológico detalhado sobre o desenvolvimento de sites, desde a definição dos objetivos até a implementação e manutenção do site. No documento há, ainda, tabelas de considerações e checklist que servem de base para organizar melhor o projeto em cada uma das etapas. Nos anexos, há várias tabelas de definições que vão desde os conceitos sobre informação e comunicação até gestalt e servem como guia de consulta rápida.
Este é um dos documentos mais completos que já li sobre metodologias de projetos e desenvolvimento web. Leitura recomendada para todos que estão começando na área ou desejam ampliar seus conhecimentos.
O último anexo apresenta uma sugestão de grade para cursos superiores em Webdesign. Frederick van Amstel, do Usabilidoido, citou esta tese em Necessidades Formativas do Tecnólogo em Web Design na Sociedade da Informação.
1 pessoa comentou o post até agora.
A Microsoft, como nunca gosta de ficar atrás dos maiores concorrentes, lançou já algum tempo o Windows Live Mail (Beta), para competir principalmente com o GMail, da poderosa Google.

Uma das vantagens é poder acessar os e-mails sem sair da caixa de entrada, como visto na imagem do painel de leitura (acima). Outra coisa, como não poderia deixar de ser nos produtos MS, é poder customizar as cores do layout, escolhendo um esquema da preferência do usuário. E agora permite também realizar buscas dentro dos e-mail (antes tarde do que nunca).
Mas como a Microsoft é sempre a Microsoft, os bugs já são previsíveis: não funciona 100% no Firefox (principalmente ao redimensionar do painel de leitura) e é muito pesado para carregar, fora outros erros que ocorrem como, por exemplo, sumir a caixa de edição de texto quando você seta o foco com a tecla tab.
A interface é boa, tem um bom menu de acesso rápido, mas tem gráficos pesados e deveria abolir a página de boas vindas ("Hoje"). Um erro de usabilidade: a mensagem de feedback à solicitação do usuário ("Trabalhando em sua solicitação...") fica quase camuflada e em uma área pouco visível:

Apesar da boa tentativa, o GMail ainda está na frente.
Nenhuma pessoa ainda comentou o post.
Resolvi fazer algumas modificações em meu site. Os artigos agora podem ser comentados.
Enjoy :)
1 pessoa comentou o post até agora.
O design de produtos pode nos ajudar a entender melhor a importância da usabilidade e ergonomia e - por que não? - é possível aprender algumas lições para aplicar nos projetos web.
Por isso, recomendo uma visita ao site Bad Designs. O site aborda desde bad designs em coisas simples até o mau uso de signos, nomenclaturas e rótulos, mostrando como as coisas do dia-a-dia se mal projetadas podem causar confusão, fazer as pessoas se enganarem ou ter alguma dificuldade no uso. Dá para tirar boas reflexões sobre design, ergonomia, usabilidade e até mesmo arquitetura de informação.
O engraçado é que, com certeza, você encontrará situações pelas quais já passou ao não conseguir utilizar um produto.
Leitura recomendada:
Emotional Design - Why We Love or Hate Everyday Things - Donald Norman
The Design of Everyday Things - Donald Norman
Don't Make me Think - Steve Krug
Nenhuma pessoa ainda comentou o post.
Jakob Nielsen foi buscar nas produções Hollywoodianas os 10 maiores erros envolvendo a facilidade de uso das interfaces e escreveu este artigo irônico na sua coluna AlertBox, mostrando como os heróis têm uma incrível capacidade de aprender em poucos segundos a utilizar sistemas e interfaces que eles nunca viram.
Veja também: Interoperabilidade excessiva em Independence Day.
Nenhuma pessoa ainda comentou o post.
Vejo muitos sites sendo desenvolvidos totalmente em flash e, inclusive, muitos colegas têm me cobrado para que eu use mais o mesmo. Não que eu seja contra o flash - muito pelo contrário - mas acredito que depende do contexto do projeto e vários sites têm pecado nesse aspecto, abusando demais de animações.
Pareço o Jakob Nielsen falando, né? Mas não é isso, não estou levantando bandeira contra o flash, que proporciona uma experiência rica em interatividade e animação, mas quero propor que seja bem planejado o seu uso.
Em alguns casos, uma pequena animação em flash (ex.: menu) pode ser substituída por CSS e/ou JavaScript.
Ok?
Nenhuma pessoa ainda comentou o post.
Pode parecer estranho, mas esta é a frase em destaque da página de login do site Livra Pesquisas que, inclusive, não se chama Login e sim "Identifique-se". Achei interessante o modo como eles exploram a comunicação e a linguagem, que acaba se tornando mais humanizada do que a maioria dos websites, independente do conteúdo.
Mesmo sendo um site pequeno, em termo de número de páginas, a arquitetura de informação é fundamental e o Livra não deixa nada a desejar. As principais informações são facilmente encontradas. Ainda se valem positivamente da redundância de links para facilitar o acesso, por exemplo, à página de cadastramento.
Confesso que nas primeiras vezes que utilizei o site, estranhei alguns termos e expressões que eles usavam, achei um pouco abusivo. Talvez seja por que estamos mais acostumados com a mecanicidade da linguagem de websites e de sistemas. É como uma tirinha que vi certa vez, do Frank e Ernest: "Entrei em pânico e desliguei! Que tipo de empresa deixaria uma pessoa de verdade atende o telefone?".
Algumas frases são curiosas e chegam a ser engraçadas na página Minha Conta:
Alterar senha: Foi parar em mão inimigas? Respire fundo, pode modificá-la.
Quer anular o seu cadastro? Vamos sentir a sua falta.
As idéias são interessantes, uma boa jogada de marketing que motiva os membros da comunidade, mas mesmo assim devemos tomar cuidado com a linguagem e o vocabulário empregado, para não ser invasivo e abusivo com o usuário.
Vale a pena dar uma conferida.
Só mais uma pergunta: Qual é o sentido da vida? O Livra Pesquisas quer saber.
Nenhuma pessoa ainda comentou o post.
Já faz algum tempo que eu estava com esta idéia na cabeça e alguns rascunhos no papel. Pensando sobre fatores - alguns muito comuns aos designer, outros nem tanto - que influenciam a abstração, compreensão e aceitação dos produtos e aplicações web, cheguei ao gráfico mostrado logo abaixo. As idéias e o próprio gráfico ainda não são definitivos. Sugestões serão bem aceitas.

Todas as idéias são interligadas e interdependentes, onde:
- A Psicologia Cognitiva visa analisar e avaliar o processo mental de percepção e assimilação de informações através dos sentidos e sua influência nos aspectos racionais e comportamentais;
- A Semiótica estuda os sinais naturais e artificiais e os sistemas de sinais, considerando a linguagem como um sistema de códigos;
- Semântica é o estudo dos significados da linguagem em sentido referencial, afetivo, contextual e sensorial, avaliando a relação entre as palavras e os conceitos que elas simbolizam;
- A Psicologia de Massas é um ramo da psicologia que estuda a intensidade com que um indivíduo muda seu comportamento pessoal e se rende ao poder da massa ao estar dentro de multidões;
- Já a Psicologia Social estuda como as pessoas se compreendem, se influenciam e se relacionam em sociedade, mas sob uma perspectiva individual da imagem e do comportamento de si mesma e das pessoas à sua volta.
Referências: Enciclopédia Ilustrada Folha v. 2. Folha de São Paulo. 1995.
Dúvidas? Críticas? Falei besteira? Comente.
Nenhuma pessoa ainda comentou o post.
Que tal simular como seria sua navegação na internet em um celular?
No site do navegador Opera eles possuem um aplicativo Java que simula o uso da internet no celular usando o Opera-mini. Muito interessante para podermos testar como os usuários de dispositivos móveis vêm a nossa web, projetada apenas para os pc. Interessante também a todos os designer que queiram saber como seus sites estão sendo visualizados em celulares, o meu até que ficou legal (viva o CSS e web standards!!).
Dá uma olhada:http://www.opera.com/products/mobile/operamini/demo.dml
Nenhuma pessoa ainda comentou o post.
Oba! Finalmente, o post de inauguração! Nesse espaço pretendo compartilhar com os colegas de profissão e curiosos informações e links interessantes sobre desenvolvimento para a internet. Então vamos começar com um assunto polêmico: o Divless.
No meu site escrevi um artigo falando mais detalhadamente sobre esta nova técnica que consiste em organizar os blocos de conteúdo e <ul> ao invés de <div>. Para quem quiser saber mais, tenho uns brindes:
http://somerandomdude.net/projects/webdev/divless/
http://www.tableless.com.br/a-semantica-e-que-manda - O que o Tableless diz sobre o assunto
http://www.w3.org/QA/Tips/unordered-lists - Com a palavra, o Sr. W3C
Nenhuma pessoa ainda comentou o post.