­­

Apresentando… Woopra­

­Foi lançado recentemente um concorrente de peso para o Google Analytics, Woopra.

Woopra é um sistema de web estatísticas e web tracking digno de notícia.

Segue abaixo alguns dos recursos e detalhes que você só pode conhecer usando, e são eles:

­
• Live­ Tracking
  Retrear a ação dos seus visitantes em tempo real.
• Rich Interface
  Combinação perfeita entre design e informação rica.
• Visitor Tagging
  Sistema permite que você atribua tags a determinado grupo de usuários para poder gerar relatórios.
• Instant Messaging
  Ótimo recurso, principalmente para quem tem blogs, permite que você abra uma sessão de chat com o seus visitantes em tempo real.
• Real-time Analytics
  Estatísticas em tempo real.
• Custom Notifications
  Com este recurso você pode criar notificações para você de acordo com
  que os visitantes entram e saem, inclusive avisar quando um determinado
  visitante ou um visitante de um determinado país entra.
• Developer Tools
  Para os que gostam de criar suas aplicações personalizadas e usufruir dos dados de uma outra forma, o Woopr­a disponibiliza a sua API para o uso.

Para mais informações: http://www.woopra.com ­

• 1 Comentário

Em seu artigo desta semana, Jakob Nielsen – um dos mais conceituados profissionais da Usabilidade – propõe que paremos de utilizar máscaras em campos de senha.

Para ele, as máscaras de senha não aumentariam a segurança, visto que qualquer mal-intencionado habilidoso poderia olhar para o teclado e guardar quais teclas compõe a senha. Por outro lado haveria um custo (de usabilidade) no uso dessas máscaras relacionado às repetidas falhas no login. A afirmação está baseada em uma das 10 heurísticas de usabilidade que diz respeito a dar um “feedback” correto ao usuário sobre o que está acontecendo no sistema.

A solução que ele propõe não é ruim: um checkbox ao lado do campo para colocar a máscara ou não, de acordo com a necessidade do usuário, mas aberta por padrão.

Gosto de provocações deste tipo, que nos fazem pensar, e a solução é inteligente; mas acho a proposta pouco viável. Acredito que tenha grande importância considerar:

1. Experiência padrão: os usuários já se acostumaram com a existência das máscaras, e há um risco óbvio em modificá-lo por essa razão; a menos que modifiquem o padrão de renderização dos navegadores, ou esta solução tenha muitos adeptos e se popularize, utilizar isto em uma aplicação teria um choque nos usuários o qual, julgo, não deve ser desconsiderado;

2. Sensação de segurança: baseado nesse experiência padrão, a sensação de segurança de um usuário com o campo bloqueado é maior do que com o campo aberto. Assim, fica difícil implantar uma solução que deixe a senha aberta especialmente em sites públicos (talvez seja mais fácil em aplicações corporativas de redes internas), dado que há um risco dos usuários temerem pela segurança e não acessarem o sistema.

Discutindo aqui na Dextra, alguns desenvolvedores questionaram se o problema está realmente no campo de senha, já que para eles a experiência ruim para o usuário seria o fato de ter que colocar usuário e senha sempre. Seguindo esta lógica, iniciativas como lembrar senha e autenticação unificada (via OpenID ou algo semelhante que possa vir a se consolidar) teriam mais ganhos.

De qualquer forma, faremos alguns testes com usuários e contaremos o resultado.

O que vocês acham?

• 0 Comentários

Escrever e manter arquivos de formatação css só parece simples no início. Conforme o projeto vai crescendo, novas solicitações de alterações são sugeridas pelo cliente. O tempo sempre exíguo muitas vezes leva a soluções mais rápidas mas, quase sempre conceitualmente erradas. O que era para ser solução, a possibilidade de determinar em um único local os atributos de um objeto html, torna-se um problema pelo seu efeito em cascata. Se este cenário já é caótico, imagine trabalhar e manter estes arquivos em um time de desenvolvimento, com profissionais com experiências e estilos diversos. É preciso definir um padrão e regras claras e simples de desenvolvimento.

Modularização

Uma abordagem possível é dividir os arquivos css em módulos. Por exemplo, agrupar as definições de fontes, cor, posicionamento (layout), formulários e navegação (menus) em arquivos diversos. Depois, pode-se definir um arquivo index.css e colocar todos juntos utilizado o elemento @import url(‘fonts.css’), por exemplo.

Esta é uma boa técnica, ajuda bastante na manutenção do código. Porém, exige um grau alto de organização e gera um trabalho inicial extra, pois algumas, senão todas as classes, ids e tags terão que ser escritas várias vezes em arquivos diversos.

Ex:

main.css

h1{
    font-size: 10px;
    color: black;
    margin: 10px 0;
}

No método modular:

font.css

h1{
    font-size: 10px;
}

color.css

h1{
    color: black;
}

layout.css

h1{
    margin: 10px 0;
}

A vantagem é óbvia: para mudar a cor de uma tag, basta abrir o arquivo color.css. A manutenibilidade aumenta em razão proporcional a qualidade do esforço inicial. Recomendável somente para projetos que sofrerão diversas alterações ou que posteriormente necessitarão de manutenção. Além do trabalho inicial maior, outra desvantagem desta técnica é a quantidade multiplicada de requisições http. Em sites com muitos acessos que precisem economizar cada bit, esta técnica pode não ser a mais adequada. Porém há uma vantagem adicional: a possibilidade de usar alguns arquivos em outros projetos, aproveitando definições de classes e ids. E isto leva a idéia da definição de um padrão, de um framework em css, como mostra este artigo.

Código auto-documentado

A idéia é usar classes e ids com nomes semânticos, ou seja, que tenham significado. Além de ser uma prática recomendável na edição de documentos html bem escritos, também é uma técnica de SEO (search engine optimization) que melhora a classificação das páginas nos sistemas de busca. Definir o caminho absoluto de um objeto protege o restante das aplicações de heranças indesejáveis.

Por exemplo, considere a seguinte estrutura.

    <div id="header">
        <ul id="menu">>
            <li><p>[...]</p></li>
                [...]
            <li><p>[...]</p></li>
        </ul>
    </div>
    <div id="content">
        <p>[...]</p>
        </div>
    <div id="footer">
        <p>[...]</p>
    </div>>

div#header é mais legível que #header, pois neste caso fica claro que a regra css estará associada somente a uma div cujo id é “header”. Se tivessemos definido a regra somente como #header, ela poderia ser usada por qualquer elemento html. Por isso, div#header ul#menu p{color:red} vai aplicar a cor vermelha somente na tag p que estiver dentro da ul#menu, que por sua vez está dentro da div#header, e não nas outras tags que aparecem em content e footer. Desse modo, além de conseguir escrever um código mais legível para a equipe, adicionalmente evitamos a propagação em cascata da propriedade para outras tags da página (técnica da caixa-de-areia).

Do geral para o específico

Mas a beleza e poder do css está justamente na propagação em cascata, na herança. Ou seja, é a possibilidade de indicar em um único lugar atributos que afetarão todo sistema. Tendo isto em mente, acredito que uma boa prática é partir do geral para o o específico. Definir, logo no início do arquivo, propriedades que serão usadas em toda aplicação, notadamente definições de fontes e cores de letras atribuídas a elementos básicos como h1, h2, h3 até h6, p, span, td, tr, hr, etc.

Um arquivo css para cada página? Não!

O maior problema de definir um css para cada página é o aumento da quantidade de requisições ao servidor e diminuição da manutenibilidade do sistema devido a inevitável redundância que fatalmente ocorrerá. Além disso, é mais fácil dar manutenção em um único arquivo do que em dezenas deles.

Comentários

Se usarmos comentários aliados a técnica da caixa-de-areia não precisaremos lançar mão de vários arquivos css:

/* cadastro de clientes : begin */
div.cadastroDeClientes{
    padding: 10px 0 0 5px;
    margin: 0;
    background: #ccc;
}
    /* box begin */
    div.cadatroDeClientes div {
    padding: 0 5px;
    margin: 0;
    }
        div.cadastroDeClientes div p{
            font-size: 12px;
        }
    /* box end */
/* cadastro de clientes : end */

O código comentado ajuda no consumo posterior do css por outros membros da equipe. A identação, simulando a hierarquia das tags html, aumenta a legibilidade do código. Tudo isto junto evita a redefinição de propriedades em locais impróprios, como no fim do arquivo css, que se por um lado sobrescrevem atributos anteriormente declarados, geram efeitos e defeitos imprevisíveis. A utilização destas técnicas darão ao desenvolvedor pistas concretas e legíveis do local exato onde deve proceder com as alterações sem que elas propaguem incontrolavelmente por toda a aplicação. Adicionalmente, sobrescrever, dentro de cada definição, elementos de layout (margin, padding, position, display, float, etc) evita problemas de layout ocasionados por herança.

Ressetando o CSS

Outra sugestão é usar sempre um arquivo para neutralizar propriedades indesejáveis de layout definidas como padrão e de maneira não padronizada pelos diversos browsers.

Nomenclatura padronizada

Nem sempre conseguimos dar bons nomes às classes e ids do css, nem sempre há tempo hábil ou inspiração para isto. Porém, estas definições são fundamentais para a legibilidade e posterior manutenção e desenvolvimento conjunto do código. Parte do problema pode ser resolvido definindo um framework, já que provavelmente poucas coisas novas surgirão no desenvolvimento de vários projetos e boa parte do código poderá ser re-utilizado.

Revisão do código

Equipes estáticas são teóricas, não existem no mundo real. Na verdade, parece ser bastante comum a entrada e saída de novos membros no decorrer dos projetos. Membros novos, sem a devida orientação, tenderão a cometer falhas. O código comentado e devidamente organizado minimizará este problema, mas não o solucionará completamente. Níveis diversos de conhecimento e experiência, aliados a urgência podem também conduzir a defeitos e soluções funestas. Criar um fluxo de trabalho onde o código seja continuamente revisado pelos membros da equipe pode contribuir positivamente para minimizar defeitos.

Conclusão

Longe de almejar uma resposta definitiva, o objetivo deste texto é apresentar técnicas para a elaboração de guidelines simples, fáceis e úteis, tendo como foco a redução de problemas de layout gerados por efeitos de propagação da herança do CSS, do comportamento diferenciado dos diversos browsers e da conjunção destas variáveis com outras que surgem ao realizar este trabalho coletivamente.

Referências:

• http://www.contentwithstyle.co.uk/content/modular-css
• http://www.contentwithstyle.co.uk/content/playing-nice-with-the-other-css-kids
• http://www.contentwithstyle.co.uk/content/a-css-framework
• http://developer.yahoo.com/yui/reset/
• http://stopdesign.com/archive/2005/05/03/css-tip-flags.html
• http://stopdesign.com/archive/2005/03/04/staying-organized.html

• 0 Comentários