Estudos de rastro visual exibem que usuários geralmente lêem páginas web em um formato padrão em ‘F’: Duas linhas horizontais, seguidas de uma linha vertical.

“‘F’, de Fast. É como usuários comumente lêem o conteúdo de nossas páginas e blogs. Movendo os olhos velozmente em um padrão bem diferente do que aprendemos na escola.”

Estudos do Grupo Nielsen Norman, comprovam que a maioria das leituras de páginas web concidem no padrão de leitura utilizado:

• Primeiramente, o usuário lê uma primeira linha horizontal superior à página.
• Em seguida o usuário desce um pouco e lê mais rapidamente uma segunda linha horizontal ou parte desta.
• Por último, o usuário escaneia rapidamente as linhas abaixo, formando uma linha vertical na página, correspondente aos inícios dos parágrafos subseqüentes.

O estudo deste padrão de leitura foi feito com o uso de uma tecnologia de escaneamento de rastro visual. A tecnologia destaca, como zonas de calor, os locais onde o usuário mantém seus olhos fixos por mais tempo. Veja os exemplos abaixo:

As áreas mais próximas do vermelho são as em que o usuário gastou mais tempo com seus olhos fixos, enquanto as em azul são as que foram vagamente visualizadas. As zonas de calor desenham um formato que lembra, na maioria dos casos, a letra ‘F’.

Este estudo é um tanto útil para designers e redatores de páginas, uma vez que exibe quais áreas em geral recebem mais atenção do usuário. Assim, seguem algumas dicas para dar uma boa leitura aos visitantes de seu blog ou site:

• Escreva um título chamativo e atraente, que dê uma boa idéia do tema que será abordado na página. Este será a linha superior do ‘F’ e, conseqüentemente, a que receberá mais atenção.
• Presenteie o usuário com um breve resumo so material apresentado no parágrafo logo abaixo do título. Este resumo pode ser uma rápida conclusão do assunto, ou um breve comentário sobre os principais pontos desde. Este será a segunda linha horizontal do ‘F’ e, possivelmente, muitos leitores terminarão por ler apenas até aqui, caso não se interessem mais pelo assunto. Em resumo, os dois primeiros parágrafos devem apresentar a parte mais importante da informação.
• Destaque cada início de parágrafo do texto principal com um objetivo bem definido. Não enrole o texto com citações ou comentários desnecessários, comece diretamente no assunto, e lembre de separar cada tópico em um novo parágrafo. Estes inícios de parágrafos formarão a linha vertical do ‘F’. O desafio é incentivar o leitor a não parar nas primeiras duas ou três palavras do parágrafo.

Obviamente, este padrão não se aplica a páginas com estruturas diferentes de um artigo em comum. Como páginas de FAQ e separadas em tópicos, mas é predominante na maioria.

Uma vez que é a nossa missão como designers web, redatores e/ou blogueiros, dispor informações para rápido e fácil acesso aos nossos queridos leitores, não custa nada seguir esta pequenas regrinhas. Certamente elas trarão mais e mais leitores para nossas páginas, atraídos pelos textos bem elaborados e objetivos.

Fonte: www.useit.com

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Como um bom desenvolvedor Web, tenho andado muito interessado nas qualidades do Firefox 3 e resolvi testá-lo em meu PC, assim como ver minhas páginas ficam no novo navegador da Mozilla.

Acontece que a Mozilla não libera binários para sistemas 64 bits (os 32 bits do ff3b4 podem ser obtidos aqui), então, enquanto não saem os binários para o Debian, o jeito é baixar o código fonte e compilar eu mesmo.

Os fontes podem ser obtidos aqui, mas não vou explicar o processo de instalação agora, isso fica pra um próximo post (quem sabe amanhã).

Pois é… Então que eu baixei os fontes, compilei, e após iniciar o bichinho, me aparece uma janelinha animada me parabenizando por ter compilado e instaladocom sucesso o Minefield 3.0 beta 4… Huh!? Instalado o que??

Bem, apesar da estranheza do logo e nome do programa, ele é, obviamente, o nosso querido Mozilla Firefox.

A diferença no nome e logo tem, segundo comentários em #developers@irc.mozilla.org, dois motivos: 1. Os direitos autorais do nome e logo do Firefox, pertencentes à Mozilla, e 2.Como ainda é uma versão beta, ele pode apresentar vários bugs, e sendo compilado por usuários, pode apresentar ainda mais, então não seria saudável, para o nome Firefox, ter tantos bugs. Ou seja, algo como: “Use-me e abuse-me a vontade, e se eu apresentar algum bug, lembre-se, eu não sou o Firefox, sou o Minefield que você mesmo compilou”.

Hehe… Brincadeiras a parte. Logo vou postar um tutorial detalhado resumido de como compilar e instalar corretamenta o Mozila Firefox Minefield em seu Debian GNU/Linux, e também como utilizar perfis diversos, para não precisar compartilhar as extensões e configurações entre as versões 2.0 e 3.0 (o que causaria problemas de compatibilidade).

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Não é uma espécie de youtube para vídeos open source, uma vez que não hospeda os vídeos, mas sim exibe uma série de vídeos sobre linux e software livre de outros websites.

Trata-se de uma adição, pelo menos interessante, contendo alguns vídeos bem-humorados, como este a seguir:

Fontes: http://www.lintube.com, http://br-linux.org/2008/lintube-site-agrega-videos-sobre-codigo-aberto-do-youtube/

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Uma curiosidade que um amigo me falou hoje que nunca havia me dado conta… Os apelidos das versões do Debian são baseados nos personagens do desenho Toy Story:

Buzz, Rex, Bo, Hamm, Slink, Potato, Woddy, Sarge, Etch e Lenny.

Segue um breve resumo sobre as versões:

A Debian 1.0 nunca foi lançada: Acidentalmente, Infomagic, uma empresa vendedora de CD, lançou a versão em desenvolvimento do Debian e a chamou de 1.0. Em 11 de Dezembro de 1995, Debian e Infomagic juntamente anunciaram que este lançamento foi indevido. Bruce Perens explicou que os dados colocados no conjunto de 5 CDs, “Fonte para Desenvolvedores Linux”, de novembro de 1995, com “Debian 1.0″ não era a versão 1.0 do Debian, mas uma versão em desenvolvimento que estava parcialmente no formato ELF, que provavelmente não iniciaria ou seria executada corretamente, e não apresentaria a qualidade de uma versão Debian. Para evitar confusões entre o CD prematuro e a atual versão do Debian, o projeto Debian renomeou sua próxima versão para “Debian 1.1″. A Debian 1.0 prematura, incluída no CD, é desaprovada e não deveria ser usada.

Debian 1.1 Buzz (Junho de 1996): Esta foi a primeira versão Debian com um codinome. Este foi retirado, como todos os outros, de uma personagem do filme Toy Story… nesse caso, Buzz Lightyear. Neste momento, Bruce Perens tomava a liderança do Projeto de Ian Murdock e Bruce trabalhava na Pixar, a companhia que produziu o filme. Esta versão era toda em ELF, usada pelo kernel Linux 2.0 e continha 474 pacotes.

Debian 1.2 Rex (12 de Dezembro de 1996): Apelidada com o nome do dinossauro de plástico do filme. Esta versão consistia em 848 pacotes mantidos por 120 desenvolvedores.

Debian 1.3 Bo (5 de Julho de 1997): Apelidada de Bo Peep, a pastora. Esta versão consistia em 974 pacotes mantidas por 200 desenvolvedores.

Debian 2.0 Hamm (24 de Julho de 1998): Nomeada com o nome do porquinho do filme. Esta foi a primeira versão do Debian para múltiplas arquiteturas, adicionando o suporte para as arquiteturas da série Motorola 68000. Com Ian Jackson como líder do Projeto, esta versão fez a transição para a libc6 e consistia em torno de 1500 pacotes mantidos por 400 desenvolvedores.

Debian 2.1 Slink (09 de Março de 1999): Nomeada com o nome do cachorro-mola do filme. Mais duas arquiteturas foram adicionadas, Alpha e SPARC. Com Wichert Akkerman como líder do projeto, esta versão consistia em cerca de 2250 pacotes e requeria 2 CDs no conjunto oficial. A inovação técnica foi a inclusão do apt, uma nova interface de gerenciamento de pacotes. Mundialmente copiado, apt é o grande responsável pelo crescimento contínuo do Debian e estabeleceu um novo paradigma para a aquisição e instalação de pacotes em sistemas operacionais de fonte aberta.

Debian 2.2 Potato (15 de Agosto de 2000): Apelidada com o nome do personagem “Sr Cabeça de Batata” do filme. Esta versão adicionou o suporte para as arquiteturas PowerPC e ARM. Com Wichert ainda atuando como líder do projeto, esta versão consistia em mais de 3900 pacotes derivados de 2600 pacotes fontes mantidos por mais de 450 desenvolvedores Debian.

Debian 3.0 woody (19 de Julho de 2002): Nomeada com o nome da personagem principal do filme: “woody”, o cowboy. Mais arquiteturas foram adicionadas a esta versão: Ia-64, HP PA-RISC, MIPS (big endian), MIPS (little endian) e S/390. Esta também foi a primeira versão a incluir software com criptografia devido as restrições de exportação que foram iniciadas nos EUA e a primeira a incluir o KDE, agora que os problemas com a licença da QT foram resolvidas. Com Bdale Garbee recentemente eleito Líder do Projeto e mais de 900 desenvolvedores Debian, esta versão continha 8900 pacotes e 7 CDs binários no conjunto oficial.

Debian 3.1 Sarge (06 de junho de 2005).

Debian 4.0 Etch (15 de Agosto de 2007) .

O codinome para a próxima grande versão do Debian após o etch é o lenny. Ainda sem previsão de lançamento.

Fonte: http://debian.org

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Um website teve a algum tempo a iniciativa de economizar enegia substituindo a página de pesquisas do google por uma página preta.

A idéia é economizar MegaWatts/h ao exibir uma página negra, que gera menos luz e consome menos energia que uma página branca.

“Em Janeiro de 2007 um artigo num blogue com o titulo Um Google Negro Salvaria 750 MegaWatts/hora Por Ano, propunha a teoria de que uma versão negra do motor de busca Google iria salvar muita energia devido á popularidade do motor de busca.”

A proposta do Blackle.com é utilizar-lo como alternativa ao google para efetuar pesquisas web enquanto se economiza energia. Ele também mostra ums estatística de quantos Watts/h já foram economizados pela página desde sua criação.

Um outro website com a mesma iniciativa é o http://www.pretog.com:

Para exibir uma tela inteira branca, seu computador usa cerca de 74 watts, enquanto para mostrar uma preta o consumo é de 59 watts.
O excesso de luminosidade produzida por um fundo totalmente branco é muito mais prejudicial aos olhos que um fundo totalmente preto.

Ambos se basearam no post deste blog: Um Google Negro Salvaria 750 MegaWatts/hora Por Ano (em inglês).

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Na última sexta-feira meu professor de DSI (Desenvolvimento em Sistemas de Informação) apresentou uma nova abordagem em desenvolvimento de software com a aula mais dinâmica que já tive. Trata-se da Extreme Programming (XP) .

Esta é uma nova metodologia de desenvolvimento de software (com cerca de 8 anos), voltada a interatividade com o cliente, ao trabalho em grupo e a dinâmica. Recomendada para desenvolvimento de softwares com requisitos vagos e que necessitem de constantes mudanças.

É baseada nas seguintes regras e práticas:

• Planejamento
  • Problemas do usuário
    • São escritos pelos clientes especificando o que o sistema deve fazer por eles;
    • Estes Problemas assemelham-se ao uso de cenários, mas não limitados a descrever uma interface e são expressados em cerca de três sentenças escritas pelo cliente;
  • Plano de Lançamento
    • Após os Problemas serem escritos, encontros são realizados para para criar o Plano de Lançamento;
    • Este Plano de Lançamento especifica que cartões serão implementados para cada lançamento e as datas destes lançamentos;
  • Lançamentos Periódicos
    • O Time de desenvolvimento deve liberar pequenas versões interativas aos clientes periodicamente;
    • No próximo encontro os clientes expõe suas opiniões e satisfações sobre o projeto (Teste de Aceitação), o que permite ao time melhorar este de acordo com as necessidades do cliente;
  • Velocidade do Projeto
    • A Velocidade do Projeto é medida conforme quanto trabalho é realizado no projeto;
    • Para medí-la, simplesmente adicione as estimativas de cada Problema resolvido durante a iteração;
  • O projeto é dividido em Iterações
    • Desenvolvimento iterativo adiciona agilidade ao processo de desenvolvimento;
    • Divida o projeto em cerca de uma dúzia de iterações com uma a três semanas de duração;
    • Mantenha essa duração constante durante o projeto, é esta constante que torna a medida de progresso e o planejamento simples e confiável na XP;
  • Plano de Iteração
    • Uma reunião é feita no início de cada Iteração para criar o plano daquela Iteração, os trabalhos de programação a serem realizados;
    • Problemas são escolhidos pelo cliente para esta Iteração, a partir do Plano de Lançamento, na ordem do mais importante para cliente primeiro;
    • O total de problemas é estimado de acordo com a velocidade do Projeto da última Iteração;
    • Testes de Aceitação falhos e que precisem de reparos também são selecionados;
    • Estes Problemas do Cliente e Testes de Aceitação são divididos em tarefas e anotados em Cartões;
    • Enquanto os Problemas são descritos na linguagem do Cliente, os Cartões são escritos na Linguagem doProgramador;
    • Programadores responsabilizam-se por estes Cartões e estimam quanto tempo suas tarefas levarão para serem completadas (geralmente 1 a 3 dias);
  • Mude os Papéis
    • Os papéis de cada membro do time de programação devem ser trocados constantemente para evitar desperdício de conhecimento e “codificação viciada” destes;
    • Se apenas um membro é capaz de trabalhar em certa área, será um problema se esta pessoa sair do projeto ou você pode acabar com acumulo de tarefas para este;
  • Reuniões em pé
    • Uma reunião em pé é realizada diariamente;
    • Comunicação entre o time de projeto é a intenção desta reunião;
    • O conhecimento de cada um é dispersado e compartilhado, assim como uma visão geral do andamento do projeto;
    • Reuniões em pé tentem a ser rápidas e dinâmicas, e impede que o time distraia-se com futilidades;
  • “Conserte a XP quando ela quebrar”
    • Nào dizemos ’se’ porque obviamente serão necessárias modificações e adaptações para cada projeto;
    • Não exite em descartar as opções que não funcionarem e adicionar novas.

Estas são as práticas da fase de planejamento, não pretendo me extender aqui a ponto de descrever todas as fases, mas vou ressaltar alguns outros pontos importantes:

• Simplicidade
  • Um projeto simples leva menos tempo para ser desenvolvido que um complexo;
  • Sempre faça o mais simples possível que funcione;
• O Cliente está sempre disponível
  • Um dos principais requerimentos das Programação XP é comunicação constante com o cliente, preferencialmente face a face;
  • Não apenas para ajudar a equipe de projeto, mas sim como parte da própria equipe;
• Programação em duplas
  • Toda a programação a ser incluída no projeto deve ser realizada por duas pessoas trabalhando juntas no mesmo computador;
  • Programação em duplas aumenta a qualidade do software sem impacto no prazo de entrega.

É notavel na programação XP que suas práticas são voltadas muito mais para a programação do que para a documentação e planejamento do projeto. Isto pode causar um grande impacto sobre os tabus de que a documentação é até mais importantes que a programação em si. Obviamente a documentação não deve ser descartada, mas também pode ser realizada dinamicamente durante os encontros/reuniões, desde anotações simples até gravação das sessões.

O suporte também não fica prejudicado pela falta de documentação apropriada. Uma vez que o conhecimento sobre o projeto é difundido sobre a equipe, fica relativamente fácil realizar modificações e aprimoramentos.

A imagem a baixo é um diagrama interativo da metodologia de programação XP. Hospedado em http://www.extremeprogramming.org/, que também foi minha maior fonte para este artigo. Leitura recomendada…

Fontes: http://www.extremeprogramming.org, http://en.wikipedia.org/wiki/Extreme_programming, http://pt.wikipedia.org/wiki/Extreme_programming

Se você gostou deste artigo, inscreva-se em meu RSS feed!