Gostaria de pedir a todos que contribuissem com o seu voto (parece até discurso de político, rs):

Vote www.talitapagani.com na categoria Freelancer

Vote blog.talitapagani.com na categoria Blog

Obrigada ;)

Relutando em utilizar outro editor, baixei uma versão portable do DW. Pois ele apresentou o mesmo erro. Reinstalei então o DW e... nada.

Já sem saída, comecei a utilizar o EditPlus. É um bom editor, entretanto não é tão produtivo para designers quanto o DW, pois não oferece Code Hint, o code coloring não é muito bom, não contém os componentes de Spry, etc.

Ah, sim, o Spry. Já estava quase começando a crer que o problema era com estes componentes. Para quem não conhece, o Spry é um framework de Ajax da Adobe, independente de ferramenta, que possui diversos widgets, efeitos de componentes, etc, semelhantemente a JQuery, Mootools, YUI, entre outros, porém é de fácil aprendizado e utilização. Além disso, o DW CS3 já vem com o framework e reconhece as propriedades dele. Enfim, continuando...

(Estamos quase chegando ao final da odisséia...)

Bom, nesta quarta-feira (17/09), já conformada que não utilizaria mais o programa no PC da empresa, resolvi, apenas por curiosidade, tentar iniciar o DW... e desta vez funcionou! Bom, fiquei sem entender o que tinha ocorrido, mas o que interessava era saber que ele tinha voltado a funcionar. Eis que a primeira coisa que fiz foi trabalhar em uma folha de estilos. Alterei - novamente - o valor de um padding de 10px para 0. Sim, ele parou de funcionar mais uma vez.

Até agora você deve estar pensando que o bug tem a ver com este tipo de alteração. Não, este ainda não é o momento hilário.

Pesquisando um pouco, encontrei um tópico em um Google group oficial do Dreamweaver, em que a Adobe dá suporte a usuários (Dreamweaver CS3 Crashes At Start Up). Já havia acessado esta página anteriormente e visto o link the Troubleshooting recomendado pelo funcionário da Adobe, mas não havia adiantado. Porém, resolvi continuar lendo o tópico.

Pelo relato de várias pessoas, parecia que minhas suspeitas estavam certas: o problema poderia ser o website (projeto) no DW que utilizava Spry ou um bug com esta mudança de padding que eu havia feito, pois ambas situações ocorreram com outros usuários que tiveram o mesmo erro. Outras hipóteses seriam conflitos entre DW e Flash ou ZoneAlarm.

Mas, foi David Powers, autor do livro "The Essential Guide to Dreamweaver CS3", que deu o diagnóstico final:

Pasmem, mas o DW tem um bug em uma DLL, reconhecido pela própria Adobe, que faz com que o programa quebre se você criar um arquivo que seja exatamente 8.192 bytes ou múltiplo deste valor. A solução é mover a pasta do projeto para outro local ou renomeá-la e adicionar mais alguns bytes ao arquivo. Vi o relato de outro usuário que comentou que um arquivo dele possuia 16.384 bytes (exatamente o dobro). Verifiquei a folha de estilo principal, onde eu estava realizando a mudança de paddings e ocasionou a quebra do DW: 16.384 bytes. Não acreditei quando vi isso, caí na gargalhada e meus colegas também não acreditaram quando eu contei. Coloquei algumas linhas a mais no CSS e pronto, funcionou!

Apenas complementando: este erro ocorre principalmente com arquivos CSS (ou somente com eles, não tenho certeza).

Então, fiquem de olho no file size dos seus arquivos quando utilizarem o Dreamweaver ;)

Com uma boa utilização do CSSDoc, mesmo que ainda não haja como gerar uma documentação online, é possível fazer com que os arquivos CSS de um projeto sejam mais inteligíveis aos outros membros da equipe, eliminando possíveis dúvidas e facilitando a compreensão das folhas de estilos. Além disso, o conceito do CSSDoc pode ser facilmente aprendido e não necessita de custo algum para sua implementação, o que permite que tanto grandes quanto pequenas equipes possam utilizar utilizá-lo com eficiência e sem restrições.

O projeto open-source idealizado por Tom Klingenberg, Timo Derstappen e Dirk Jesse ainda está em fase de desenvolvimento e, apesar de relativamente novo – foi criado em meados de 2007 –,  já possui grande parte da sintaxe definida. Um breve esboço sobre a técnica está disponível no site do CSSDoc.

A sintaxe básica é a seguinte

Onde @tag são as possíveis tags que têm a função de definir uma propriedade do bloco de código ou do arquivo.

É necessário entender, também, os tipos de comentários que o CSSDoc permite.

Comentário do Arquivo

É a principal descrição de um arquivo CSS, sendo utilizada apenas uma vez por arquivo, no topo. É composta tanto por texto quanto pelas tags que fornecem meta informações sobre o arquivo, tais como o author do arquivo, versão, etc.

Comentários de Seção

São comentários que abrem seções em arquivos CSS e que pode, ser utilizados para estruturar o código CSS. Não há uma definição específica do que seria uma seção, pois cada designer pode definir de uma forma diferente. Alguns exemplos seriam: Reset, Layout, Tipografia, Header, Footer, Conteúdo, etc.

Comentários padrões do CSS

O uso do CSSDoc não limita o uso os comentários padrões do CSS, que podem ser utilizados normalmente para fornecer informações adicionais aos arquivos CSS.

Para conferir a lista de tags e como utilizá-las, basta conferir a primeira documentação fornecida por Tom Klingenberg. Um bom exemplo da aplicação do CSSDoc é o framework YAML - Yet Another Multicolumn Layout, desenvolvido por Dirk Jesse.

Espero que todas as práticas abordadas durante está série de artigos sejam de grande ajuda, principalmente para os profissionais freelancers e pequenas equipes de desenvolvimento que sempre tentam aplicar uma boa metodologia de trabalho, mesmo vivendo sob a tensão dos prazos de desenvolvimento.

;)

Bom, vamos a uma rápida lista de mudanças.

Layout e Arquitetura de Informação

Na versão anterior do blog, não gosto muito do header, principalmente. Então resolvi deixar ele e os outros elementos da página consistentes com a identidade visual do meu portifólio, apenas modificando levemente o estilo. Dessa forma, a associação entre ambos os sites é fortalecida.

Outra grande mudança foi a organização do conteúdo. Os posts agora estão do lado esquerdo, em uma área mais valorizada. A primeira coluna secundária contém links relativos ao conteúdo do blog (feed, bookmark, arquivo, etc.), enquanto que a última coluna é para informações mais pessoais, com um breve perfil sobre o blog e sobre mim, além de links para outros blogs interessantes. A caixa de busca também ganhou nova localização, ficando mais destacada no topo.

Compartilhamento

Resolvi colocar novamente a API de compartilhamento do delicious, que havia ficado de fora da versão anterior por um pequeno lapso de memória.

E o melhor: o famoso widget Add This agorá está presente na página de cada post, facilitando o compartilhamento do conteúdo do blog com o serviço favorito do visitante.

Paginação

Este é um recurso que tem grande impacto sobre a performance. Antigamente, todos os artigos postados até hoje apareciam na página inicial, o que fazia com que o site demorasse muito tempo para carregar. Agora, com os registros paginados, são mostrados apenas 5 posts por página.

Os rótulos de navegação também seguem uma nomenclatura lógica: na página 1 (default) o link ativo é "Anteriores" e não "Próximos", afinal, o visitante deseja ver os posts anteriores. Me baseei em sistemas atuais como o GMail e o Delicious para adotar este padrão.

Espero que todos apreciem as mudanças e enviem seu feedback.

:)

Com uma boa utilização do CSSDoc, mesmo que ainda não haja como gerar uma documentação online, é possível fazer com que os arquivos CSS de um projeto sejam mais inteligíveis aos outros membros da equipe, eliminando possíveis dúvidas e facilitando a compreensão das folhas de estilos. Além disso, o conceito do CSSDoc pode ser facilmente aprendido e não necessita de custo algum para sua implementação, o que permite que tanto grandes quanto pequenas equipes possam utilizar utilizá-lo com eficiência e sem restrições.

O projeto open-source idealizado por Tom Klingenberg, Timo Derstappen e Dirk Jesse ainda está em fase de desenvolvimento e, apesar de relativamente novo – foi criado em meados de 2007 –,  já possui grande parte da sintaxe definida. Um breve esboço sobre a técnica está disponível no site do CSSDoc.

A sintaxe básica é a seguinte

Onde @tag são as possíveis tags que têm a função de definir uma propriedade do bloco de código ou do arquivo.

É necessário entender, também, os tipos de comentários que o CSSDoc permite.

Comentário do Arquivo

É a principal descrição de um arquivo CSS, sendo utilizada apenas uma vez por arquivo, no topo. É composta tanto por texto quanto pelas tags que fornecem meta informações sobre o arquivo, tais como o author do arquivo, versão, etc.

Comentários de Seção

São comentários que abrem seções em arquivos CSS e que pode, ser utilizados para estruturar o código CSS. Não há uma definição específica do que seria uma seção, pois cada designer pode definir de uma forma diferente. Alguns exemplos seriam: Reset, Layout, Tipografia, Header, Footer, Conteúdo, etc.

Comentários padrões do CSS

O uso do CSSDoc não limita o uso os comentários padrões do CSS, que podem ser utilizados normalmente para fornecer informações adicionais aos arquivos CSS.

Para conferir a lista de tags e como utilizá-las, basta conferir a primeira documentação fornecida por Tom Klingenberg. Um bom exemplo da aplicação do CSSDoc é o framework YAML - Yet Another Multicolumn Layout, desenvolvido por Dirk Jesse.

Espero que todas as práticas abordadas durante está série de artigos sejam de grande ajuda, principalmente para os profissionais freelancers e pequenas equipes de desenvolvimento que sempre tentam aplicar uma boa metodologia de trabalho, mesmo vivendo sob a tensão dos prazos de desenvolvimento.

;)

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.

1º passo: Sitemaps – Macro-arquitetura de Informação

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)

2º passo: Diagramas de Interface

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:

• 1ª camada – Wireframes: para muitos, eles já são conhecidos. Desenvolvidos também durante a etapa de planejamento, eles não especificam o design gráfico, mas são responsáveis por representar a organização e a distribuição dos elementos de interface de acordo com a relevância e o relacionamento entre os conteúdos. São fundamentais tanto para a documentação como para orientar os designers, programadores e testers durante todas as etapas de desenvolvimento, além de prover ao cliente uma visão de como a aplicação estará estruturada. (Exemplo 1, Exemplo 2)
• 2ª camada – Diagramas Estruturais: produzidos já durante a etapa de desenvolvimento, estes diagramas são como verdadeiros esqueletos do site, ideais para indicar a estrutura física dos documentos, incluindo medidas, dimensões, tipos de elementos HTML de cada componente, nome de seletores CSS aplicados, etc. É o diagrama que possui menor número de detalhes dos elementos de interface, entretanto, é o que possui maior objetividade em termos de especificação técnica e grande capacidade de orientação nas tarefas de desenvolvimento, manutenção e treinamento. (Exemplo 1, Exemplo 2)
• 3ª camada – Diagramas estruturais preenchidos: opcionais, são baseados nos Diagramas Estruturais, mas possuem também algumas definições de cores e bordas, indicando o valor das mesmas.

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:

• Quando há uma grande equipe de desenvolvimento e/ou alto grau de multidisciplinaridade;
• Quando o software/website é complexo e necessita descrever adequadamente os diversos componentes da interface, evoluções, problemas, correções, compatibilidade, dúvidas e respostas freqüentes, padrões e convenções de interface, entre outros fatores, a fim de evitar ambigüidades, incoerências, dúvidas e falta de sincronia durante o desenvolvimento.

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)

:)

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.

Motivos para documentar uma interface

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:

• Criamos uma arquitetura de interface (utilizando arquitetura de informação, padrões de design, táticas e experiência);
• Avaliamos a arquitetura;
• Refinamos, corrigimos, atualizados e refazemos a arquitetura ao longo do caminho;
• A arquitetura é utilizada para guiar a implementação;
• Reforçamos a arquitetura durante a implementação.

A arquitetura de interface serve como uma plante para o site a ser criado:

• Define as atribuições de trabalho;
• É o portador primário dos atributos de qualidade;
• É o melhor artefato para análise;
• É a chave para o processo de pós-produção (manutenção).

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

:)

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 :)

Organizando a estrutura do site

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.

Melhores práticas de SEO

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.

Revisão de conteúdo

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.

O que não foi possível fazer

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.

:)

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ó :)

"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 :)

A composição das cores web-safe

Elas são formadas apenas por números múltiplos de 3: 0, 3, 6, 9, C, F.

Características dos pares RGB

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.

Regras para a conversão

O primeiro valor de cada par é que determinará o valor daquele par:

F7 85 13

Depois é só converter por aproximação:

• 1 para 0
• 2 e 4 para 3
• 5 e 7 para 6
• 8 e A para 9
• B e D para C
• e E para F

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 :)

Mas, afinal, o que é um site acessível e o que é um site usável?

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).

:)

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.

Conceito e público-alvo

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.

Brainstorming e abstração de idéias

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.

Diagramação, AI e Usabilidade

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)!

:)

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).

Os principais problemas

• Quebra do botão refresh e voltar/avançar do navegador: quando uma página ou sistema inteiro é feito em AJAX, o sistema de navegação tradicional tende a ser quebrado. Para o usuário, significa que se ele só consegue acessar uma determinada página depois de executar x ações e quiser voltar, recarregar a página ou desfazer uma ação feita na etapa anterior, não conseguirá realizar isso com êxito. Ou seja, há uma quebra no modelo mental que o usuário possui de navegação.
• O "fantasma" do carregamento infinito: esta era uma da grandes promessas de extermínio do AJAX quando obteve ascensão. Mas ainda acontece, em um contexto diferente: se não há um tratamento de erro para uma requisição que falhou ou que não retornou resultado, o sistema permanece em eterno carregamento, fazendo com que o usuário fique sem um feedback sobre a ação executada.
• Longo tempo de espera no carregamento: sim, por incrível que pareça. Mas isso acontece apenas com sistemas feito quase que inteiramente com o uso de AJAX, são casos mais isolados. O que ocorre são várias partes das páginas de um sistema que são carregadas assincronamente, ou seja, várias requisições HTTP em uma mesma página podem gerar um sobrecarregamento daquela página e tornar o sistema lento para o usuário.

Mas há bons exemplos...

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

:)

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 ;)

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:

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:

É 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.

:)

Evitar definir seletores sem um contexto

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 difente para este seletor. Isso pode fazer com que você tenha que forçar a nova rega 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.

Classe x ID

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.

Utilizando mais de um seletor

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.

:)

Arquitetura de Informação

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).

Para melhorar a usabilidade

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.

SEO

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.

Primeiros erros...

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

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.

:)

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.

:)

Fica aí uma excelente dica. :)

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.

Hierarquia de títulos

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.

Atributo alt para imagens

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.

Tag title

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.

Meta-tags

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.

Para saber mais

SEO: Como melhorar o ranking do site - Paulo Rodrigo, colunista do iMasters
Diretrizes para webmasters - Google

Contribua da maneira que puder para que a enciclopédia livre continue existindo.

Navegação inicial

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.

Parâmetros de aparência

É 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.

:)

Este primeiro post é apenas uma canjinha e apresenta a ferramenta Cobertura do site.

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:

• Se os links relevantas da página estão bem organizados e distribuídos e se têm o retorno de acesso esperado;
• Se o conteúdo está sendo suficiente e interessante para que as pessoas não saiam da página na primeira visita;
• Se o fluxo de navegação previsto na arquitetura de informação é efetivamente realizado pelo usuário;
• Se o mapa do site está sendo muito acesso, o que significa que as pessoas provavelmente não estão conseguindo encontrar o conteúdo que precisam.

No próximo post trarei análises interessantes de outras ferramentas.