Design de epicentro foca na verdadeira essência da página — o epicentro — e então constrói para fora. Isso significa que, no começo, você ignora as extremidades: a navegação/menus, rodapé, cores, barra lateral, logotipo, etc. Em vez disso, você começa o epicentro e faz o design das peças de conteúdo mais importantes primeiro.

Seja qual for a página ela não pode viver sem seu epicentro. Por exemplo, se estiver fazendo o design de uma página que mostra a publicação de um blog, a publicação por si é o epicentro. Não as categorias na barra lateral, não o cabeçalho no topo, não o formulário de comentários embaixo, mas a unidade de publicação de mensagem do blog. Sem essa unidade de publicação, a página não é a publicação de um blog.

Somente quando essa unidade está completa você começaria a pensar no segundo elemento mais crítico da página. Então, depois desse segundo elemento mais crítico, se moveria para o terceiro, e assim por diante. Isso é design de epicentro.

Design de epicentro evita o tradicional modelo “vamos construir a moldura então jogar o conteúdo dentro”. Nesse processo, o formato da página é construída, então a navegação é incluída, então as “coisas” de marketing são inseridas e então, finalmente, o núcleo da funcionalidade, o verdadeiro propósito da página, é enfiado em um espaço qualquer que tenha sobrado. É um processo de trás para frente que tira o que deveria ser a prioridade principal e deixa isso para o fim.

Design de Epicentro vira esse processo e permite que você foque no que realmente interessa no dia um. Essenciais primeiro, extras em segundo. O resultado é uma tela mais amigável, focada e usável para os clientes. Além disso, permite que você comece o diálogo entre designer e desenvolvedor logo de cara em vez de esperar por todos os aspectos da página caírem na linha primeiro.

Do livro ‘Getting Real’, aqui você encontra a tradução completa em português do mesmo.

É o que eu sempre digo para a moçada, concentre-se no conteúdo, foque na essência do produto, no que realmente ele se propõe a transmitir, o resto é só firula.

Evitar especificações funcionais é um bom começo, mas não é tudo: é necessário evitar o excesso de papelada em todo o projeto. A menos que um documento vá efetivamente transformar-se em algo real, ele não deve ser escrito.

Construa, não escreva. Se você precisar explicar alguma coisa, tente construir um protótipo em vez de redigir um longo documento. Uma interface de verdade ou um protótipo tende a seguir caminho em direção a um produto real. Um punhado de folhas de papel, por sua vez, somente seguirá caminho rumo a uma lixeira.

Se um documento provavelmente nunca evoluirá para um design real, não se preocupe em escrevê-lo. Se o intuito de um documento é transformar-lo em um modelo, vá em frente.

Documentos que existem separadamente da aplicação são inúteis. Eles não levarão a lugar nenhum. Todos os esforços de projeto devem ser usados na evolução do produto real. Se um documento é congelado antes de se tornar uma peça real, ele está morto.

Ninguém nunca irá lê-lo

Eu sequer consigo lembrar quantas especificações ou documentos de requerimentos de negócio ficaram de escanteio, juntando poeira enquanto minha equipe de desenvolvimento codificava, discutia problemas, fazia perguntas e conduzia testes de usabilidade ao longo de nossos projetos. Também já trabalhei com desenvolvedores que desperdiçaram horas escrevendo longos e minuciosos emails ou documentos de padrões de codificação que sempre acabaram não sendo lidos por ninguém.

Aplicações web não avançam graças a um grande punhado de documentos. O desenvolvimento de software é um processo em constante evolução e que envolve iterações e decisões rápidas, à medida que problemas imprevisíveis aparecem pelo caminho. Nada disso pode ou deveria ser registrado em folhas e folhas de papel.

Não desperdiçe seu tempo escrevendo aquele longo e visionário documento: ninguém irá lê-lo. Console-se com o fato de que, se o seu produto tiver espaço o suficiente para crescer adequadamente, no final ele nem de longe parecerá com qualquer coisa que você tenha escrito sobre ele.

— Gina Trapani, desenvolvedora web e editora do Lifehacker, o guia de produtividade e software

Do livro ‘Getting Real’, aqui você encontra a tradução completa em português do mesmo.

Logo do google.com em Homenagem a Charles Darwin

A Dell lançou oficialmente seu mininotebook, o Inspiron Mini 9, que já está disponível rodando com Windows XP. Ele usa memória SSD, vem com tela de 8,9 polegadas em LED e teclado que a Dell promete ser “grande e fácil para navegar”.

Wi-Fi virá embutido como padrão, mas a webcam e bluetooth serão opcionais. O preço inicial para a versão com XP é de 527 dólares, incluindo taxa de exportação e entrega.

Já a versão que usará o sistema operacional da Ubuntu 8.04 e uma interface customizada desenvolvida pela Dell será a partir de 478 dólares.

Fonte: Computerworld

[...]
O que um web designer precisa saber? Eu destacaria duas coisas: 1) A natureza do mark up; 2) Rewritebility.

O primeiro versa que o HTML não é uma linguagem visual, mas estrutural. Como ensinar alguém a diferença? Mande-o usar Lynx, browser de texto. O Opera tem um modo de visualização que o emula. Ou simplesmente, mande-o usar browsers que permitam desligar os estilos.

Então a natureza do mark up saltam aos olhos. Acessibilidade e SEO inclusos.

“Reescrevibilidade” (caceta, nunca consegui conjugar este nome, em português ou inglês) é a segunda. É a capacidade de terceiros assumir o código e não achar que aquilo é um criptograma. Como se consegue isto? Simplicidade, essencialmente. Via uma noção que o HTML não é uma coisa autoral, uma rosa dentro duma redoma. Estamos criando para a internet, não para nós mesmos (o que reside 99% dos problemas dos web designers: O ego do próprios).

O que, afinal de contas, os dois itens são a mesma coisa. A natureza do mark up era a possibilidade de terceiros pudessem ter acesso ao source, hackear, adaptar, processar, dar novos usos.

Não criamos sites para nós. Nós estruturamos informações. Quem vai dar uso é o usuário. Por isto o ambiente é essencialmente, social. Por isto Flash é um contrasenso na web. Por isto quando inventamos de controlar que fim darão ao conteúdo, esbarramos sempre na questão da acessibilidade.
[...]

Pronto, fechou.

Se você observar as imagens abaixo sentado na distância normal do monitor, o Sr. Raiva está à esquerda e a Sra. Calma está à direita. Agora, levante-se do seu lugar e mova-se para trás uns 3 metros e verá que eles trocam de lugar!!!

Este desenho deve ter sido criado por JMF (c) 2005, o grande cérebro do século 21. Isto prova que nós talvez não estejamos a ver “o que realmente existe num determinado lugar, o tempo todo.”

Faça o download e rode direto do seu pendrive!

Animação da música A Flor.

Tá ai, reclamaram que isso tinha sumido dos meus arquivos, que os links que apontavam pra ele não funcionava mais, blá, blá, blá… Meus amigos eu já disse que perdi tudo que é post entre 2003 e 2007, os poucos que restaram estão por aqui, mas sempre que sentirem falta de algum se eu conseguir reparar, farei.

No formato do famoso ícone de pasta/diretório de arquivo. Mimoso, né? :]

Fonte: Art. Lebedev Studio

Animação da música A Flor.