http://gov.uk

A equipe de governo digital do Reino Unido publicou a primeira versão das diretrizes de design para site governamentais. O material é tão rico que eu não poderia simplesmente colocar o link no Twitter. Escrevi essa tradução resumida, mas se você sabe ler em inglês, sugiro ir direto para a página original.

Princípios de Design do Governo Digital

1. Comece com as necessidades (do cidadão, não do governo) – O processo de design deve começar com a identificação das necessidades reais do usuário. Devemos criar em torno disso – não da forma como é o atual “processo oficial”. Devemos entender essas necessidades completamente – pesquisa de dados, não apenas suposições – e devemos lembrar que nem sempre o que usuários pedem é o que eles precisam.

2. Faça menos – Governo só deve fazer o que só o governo pode fazer. Se alguém já está fazendo isso – coloque o link. Se podemos fornecer recursos (como APIs) que vão ajudar outras pessoas a construírem coisas – que seja feito. Devemos concentrar-se no núcleo irredutível. (…) O Governo deve oferecer informações sobre impostos e não sobre criação de abelhas.

3. Faça design com dados – Normalmente não estamos começando do zero – usuários já estão usando nossos serviços. Isto significa que podemos aprender com o comportamento do mundo real. Devemos fazer isso, mas devemos ter certeza de que esse seja um processo contínuo de desenvolvimento – protótipos e testes com usuários reais na web. (…) Esta é a grande vantagem de serviços digitais – podemos observar e aprender com o comportamento do usuário, moldando o sistema para atender o que as pessoas fazem ao invés de forçá-las a usar um sistema que inventamos.

4. Faça o trabalho difícil para torná-lo simples – Fazer algo parecer simples é fácil; fazer algo simples de usar é muito mais difícil – especialmente quando os sistemas envolvidos são complexos – mas é o que devemos fazer. Com grande poder vem grande responsabilidade – muitas vezes as pessoas não têm escolha a não ser utilizar nossos serviços. Se não trabalharmos duro para torná-los simples de usar estamos abusando desse poder e desperdiçando o tempo das pessoas. (…) O sistema de licença maternidade é um bom exemplo de como tornar simples algo complicado. O código (…) está disponível no GitHub.

5. Faça iterações. E então faça novamente – A melhor maneira de criar serviços eficazes é começar pequeno e iteragir continuamente. Publique Produtos Mínimos Viáveis, teste com usuários reais, passe do Alpha para o Beta e para o Lançamento, adicionando recursos e aperfeiçoamentos com base no feedback de usuários reais. Iteração reduz o risco. Torna grandes fracassos improváveis e transforma pequenas falhas em lições. Isso evita as 200 páginas de especificações. Isso, novamente, é a principal vantagem do digital: não estamos construindo pontes – as coisas podem ser desfeitas.

6. Construa para inclusão – Design acessível é um bom design. Devemos construir um produto que é tão abrangente e legível quanto possível. Se tivermos de sacrificar a elegância – que assim seja. Não devemos ter medo do óbvio, não devemos tentar reinventar convenções de web design e devemos definir claramente as expectativas. Estamos projetando para todo país – não apenas para aqueles que estão acostumados a usar a web. Na verdade, as pessoas que mais precisam dos nossos serviços são aquelas que tem mais dificuldade em utilizá-los. Se pensarmos nessas pessoas desde o início, faremos um site melhor para todos.

7. Entenda o contexto – Não estamos projetando para uma tela, estamos projetando para pessoas. Precisamos pensar no contexto que os usuários utilizam nossos serviços. Eles estão em uma biblioteca? Eles estão em um telefone? Eles só sabem utilizar o Facebook? Nunca usaram a web antes? Estamos projetando para um grupo muito diversificado de usuários com diferentes tecnologias e necessidades. Precisamos ter certeza das circunstâncias tecnológicas e práticas em que nossos serviços são utilizados. Caso contrário, corremos o risco de criar serviços bonitos que não são relevantes para a vida das pessoas.

8. Construa serviços digitais e não sites – Nossos serviços não começam e terminam no site. Pode começar em um site de busca e acabar no posto dos correios. Precisamos projetar para isso, mesmo sem ter controle sobre todo processo. (…) Isso não é sobre sites, deve ser sobre serviços digitais. Hoje, a melhor maneira de oferecer serviços digitais é através da web – mas isso pode mudar, mais cedo do que podemos esperar.

9. Seja consistente, não uniforme – Sempre que possível devemos usar a mesma linguagem e padrões de design – isto ajuda as pessoas a se familiarizar com nossos serviços. Mas quando não for possível, devemos nos certificar que nossa abordagem é consistente. (…) Esta não é uma camisa de força ou um livro de regras. (..) Não temos como imaginar todos os cenários e escrever regras para isso. Cada circunstância é diferente e deve ser abordada em seus próprios termos. O que une as coisas, portanto, deve ser uma abordagem consistente – uma que os usuários venham a entender e confiar.

10. Faça coisas open source: isso as torna melhores – Devemos compartilhar o que estamos fazendo sempre que pudermos. Com colegas, usuários e com o mundo. Compartilhe códigos, design, ideias, intenções e falhas. Quanto mais olhos em um serviço melhor ele fica. (…) Em parte, porque muito do que estamos fazendo só é possível por causa do código aberto e da generosidade da comunidade de web design. (…) Mas principalmente porque essa abertura torna os serviços melhores – mais compreendido e mais analisado. Se nós damos o nosso código, vamos ser reembolsado com um código melhor. É por isso que nós estamos dando tudo isso…

Tradução livre de Government Digital Service
Design Principles

Se você chegou até aqui, não deixe de ler o guia de estilo para produção de conteúdo.

Pode parecer estranho comparar um poderoso iPad (U$400) com um simples Kindle (U$79), mas quando o assunto é leitura a briga esquenta.

Há 3 meses comprei um iPad2 com o objetivo principal de ler livros eletrônicos. Adorei o aparelho e uso para receber emails, navegar na web, acessar redes sociais, jogar e assistir filmes. Tudo menos ler. É impressionante, você abre o iPad para iniciar uma leitura e sempre cai na tentação de algum outro aplicativo.

Recentemente comprei um Kindle Touch e em menos de uma semana já estou terminando meu primeiro e-book. Na carta de apresentação, Jeff Bezos explica que o objetivo do Kindle é fazer você esquecer que está lendo um livro através de um dispositivo eletrônico. E é exatamente isso, ele é focado na leitura, sem interrupções, sem funcionalidades extras.

Pode parecer loucura, mas um fator determinante para a minha compra foi descobrir que existe uma capa de couro com uma lâmpada embutida que permite a leitura no escuro e utiliza bateria do próprio aparelho (que dura semanas!). Um outro detalhe importante é que o Kindle pesa apenas 240g, você não precisa das duas mãos para segurá-lo, diferente do iPad que tem 600g.

Para leitura rápida de blogs e notícias, eu continuo ainda com o iPad e o excelente Instapaper. Você instalar uma extensão no browser e ele envia diretamente para o iPad. Além disso, o aplicativo limpa todo layout do site, deixando apenas texto e imagem. Para o Kindle existe um serviço similar chamado Klip.me, mas a interface do aparelho realmente parece não ter sido feita para esse consumo rápido de informação.

Para mim, o Kindle se mostrou o melhor dispositivo para livros eletrônicos e o iPad para leitura rápida de blogs, notícias e todas as outras atividades online.

UPDATE: Se você se interessou pelo assunto, não deixe de ler o artigo do Tiago Dória com uma ótima comparação sobre leitura de livros digitais.

www.modularhtml.com.br

Um código HTML bem feito precisa ser semântico. Isso quer dizer que você deve marcar um parágrafo com a tag P, uma lista com a tag UL e uma tabela com a tag TABLE. Mas cada desenvolvedor escreve o código semântico do seu jeito. Alguns gostam de envolver tudo com uma tag DIV, outros usam muitas listas (UL/LI) e tem ainda aqueles que não economizam na tag SPAN.

Na maioria dos casos não existe certo ou errado, mas sem uma regra você nunca terá um código padronizado. A padronização permite a reutilização, agiliza a montagem HTML e cria um estilo único entre todos os desenvolvedores de uma equipe, incluindo designers e programadores.

Existem guias de estilo para Jornalismo (Manual de Redação), Design Gráfico (Manual de Identidade Visual) e mesmo para Programação (Padrão de Codificação). Inspirados por um artigo de Anna Debenham na 24ways, resolvemos criar o ModularHTML, um guia de estilo para código HTML semântico e padronizado.

O ModularHTML é formado por uma lista de módulos, pedaços de código HTML que compõem uma página web. Você vai encontrar módulos simples como breadcrumbs e mais complexos como um slideshow de imagens. Ao montar uma página HTML, abra o ModularHTML no browser e copie os pedaços de código para sua página.

Inicialmente seria uma ferramenta de uso interno, mas resolvemos torná-la pública para que outros desenvolvedores possam usar, testar e contribuir. Todo conteúdo do ModularHTML está sob licença MIT e seu código disponível no Github. Acesse a página de demonstração e participe do projeto.

Um profissional freelancer costuma orçar seus projetos pelo número de horas trabalhadas. Essa estimativa é feita através da experiência acumulada em trabalhos anteriores. Sabendo da importância desse controle de horas, como medir o tempo de forma precisa sem que isso se torne uma tarefa chata e burocrática?

Os softwares mais comums de controle de tempo (time tracking) são basicamente cronômetros que você liga e desliga enquanto realiza suas tarefas. Isso pode funcionar nos primeiros dias, mas com o tempo você acaba esquecendo ou cansando de anotar os horários.

Além do controle de tempo, o Paymo permite fazer a gestão completa de um projeto

Existem ferramentas de time tracking que registram automaticamente os segundos que cada aplicativo fica aberto no computador. Isso é interessante para ter uma ideia de como utilizamos nosso tempo ao longo do dia, mas é difícil isolar cada tarefa, principalmente quando você trabalha com diversos softwares.

Eu já uso o Paymo há algum tempo e recentemente eles lançaram o PaymoPlus, uma excelente ferramenta de controle de tempo integrada ao aplicativo. Com ele você pode ter o melhor dos dois mundos: registrar automaticamente o tempo gasto no computador e relacionar cada registro a uma tarefa específica.

Quando vou começar um projeto, eu crio as listas de tarefas no Paymo e durante o trabalho o PaymoPlus registra minhas atividades. No final do dia eu arrasto esses horários para dentro de cada tarefa. É muito simples, rápido e permite um acompanhamento preciso de horas trabalhadas em um projeto.

Detalhe de um wireframe com as marcações das áreas editáveis

Softwares de gestão de conteúdo como WordPress e Drupal permitem que as pessoas tenham mais autonomia sobre o conteúdo do site, sem depender de um desenvolvedor para fazer alterações simples. Mas ter um CMS instalado não significa que tudo pode ser editado em uma página.

Algumas barras de navegação não permitem inclusão de novos itens por questões de espaço, alguns textos são fixos (como o nome da empresa) e se ainda assim fosse possível alterar tudo, o painel de administração teria tantos botões quanto um cockpit de avião.

Em um projeto recente que participei, descobrimos tarde demais que uma área da homepage seria constantemente atualizada pelo cliente. Isso ocasionou atraso e retrabalho. Durante a retrospectiva resolvemos que nos próximos projetos iríamos definir as áreas editáveis na criação do sitemap e detalhar cada página durante a produção dos wireframes.

Essa simples mudança agilizou a instalação do CMS pois deixamos de nos preocupamos em com áreas que não seriam atualizadas e atendeu melhor as expectativas do cliente na administração do site.

Fazer a retrospectiva depois de terminar um projeto web (ou uma fase) é importante mesmo que você não trabalhe com metodologias ágeis. É bem simples: reúna a equipe e discuta o que funcionou, o que deu errado e o que pode ser feito para melhorar o processo.

Uma dinâmica interessante que aprendi com o pessoal de Scrum é a do mural com os pontos positivos e negativos:

• Cada membro da equipe recebe uma caneta e um bloco de post-it
• Todos anotam os pontos positivos e negativos, um em cada post-it
• Os post-its devem ser colados em um mural, separados entre pontos positivos e negativos
• Um voluntário agrupa os post-its com opiniões similares e lê cada conjunto em voz alta
• Os assuntos são discutidos um a um e são anotadas possíveis soluções

Lembre-se que não há culpados, o objetivo é celebrar os acertos, detectar as falhas e discutir o que pode ser melhorado no futuro. A partir do próximo projeto (ou fase) já comece a aplicar as melhorias combinadas na última reunião de retrospectiva.

No vocabulário da maioria das pessoas, design significa aparência. É decoração de interiores. É o tecido de cortinas, do sofá. Mas para mim, nada poderia estar tão longe do significado de design. Design é a alma fundamental de uma criação humana, que acaba se expressando em camadas externas sucessivas do produto ou serviço.

Playboy, 1987 – via gizmodo.com.br

Diagrama GIT + Dropbox

Esse artigo explica como criar um ambiente compartilhado para desenvolvimento web utilizando ferramentas que tornam o seu trabalho mais fácil, prático e profissional. Esse processo é útil para compartilhar com outros desenvolvedores (front-end ou programador), mas também serve para trabalhar sozinho utilizando máquina diferentes (em casa e no trabalho, por exemplo).

Antes de explicar o processo, vamos fazer uma breve introdução sobre GIT e Dropbox. Se você já está familiarizado com esses aplicativos, pule direto para a seção Criando um repositório no Dropbox.

Esse artigo explica como criar um ambiente compartilhado para desenvolvimento web utilizando ferramentas que tornam o seu trabalho mais fácil, prático e profissional. Esse processo é útil para compartilhar com outros desenvolvedores (front-end ou programador), mas também serve para trabalhar sozinho utilizando máquina diferentes (em casa e no trabalho, por exemplo).

Introdução ao GIT

GIT é um tipo de sistema de controle de versão desenvolvido por Linus Torvalds (sim, o mesmo do Linux). Um sistema de controle de versão é um aplicativo que gerencia as versões de um ou mais arquivos, muito utilizado no desenvolvimento de softwares e que vêm se popularizando também entre desenvolvedores web. Existem outros tipos de sistemas de controle de versão como o CVS, Subversion, Bazaar, Mercurial e outros.

De uma forma bem resumida o GIT funciona assim: após criar um repositório GIT em um computador qualquer desenvolvedor pode clonar esse repositório para sua máquina, editar os arquivos e enviá-lo novamente para a origem. O software fará o controle das versões e caso dois desenvolvedores alterem o mesmo arquivo, as alterações serão comparadas e consolidadas em um único arquivo.

Você não precisa saber linha de comando para usar o GIT, aplicativos como o Gitbox fazem o trabalho sujo por você

Depois de baixar e instalar o GIT (Mac ou Windows) é comum utilizá-lo através de linha de comando, mas se você é designer, como eu, e gosta de apertar botões recomendo o Gitbox SourceTree (para Mac) ou a própria GUI que vem junto com o msysgit para Windows.

Nota: Essa é uma introdução rápida, feita por um designer que não utiliza os termos técnicos corretamente. Caso você queira uma explicação mais precisa, consulte a documentação oficial.

Introdução ao Dropbox

Dropbox é um excelente serviço gratuito para compartilhamento de arquivos. Além da versão web, você pode instalá-lo no Mac, Windows ou Linux. Ele funciona como uma pasta de 2G dentro do seu computador que pode ser acessada e compartilhada facilmente com outros usuários.

O Dropbox fica invisível depois de instalado no computador, se comportando como uma pasta comum no seu HD

Nota: Se você não tem uma conta no Dropbox, cadastre-se por esse link e me ajude a ganhar 250M de espaço extra!

1º Passo – Criando um repositório no Dropbox

Baixe e instale o Dropbox, crie uma pasta com o nome do seu projeto e dentro dela uma pasta vazia chamada, por exemplo, “www” “repo.git”. Baixe e instale o GIT e a GUI de sua preferência (Gitbox ou msysgit). Abra o aplicativo e clique em adicionar um repositório. O GIT criará uma pasta oculta dentro da “www” “repo.git” chamada “.git”.

2º Passo – Compartilhando o diretório com os outros desenvolvedores

Clique com o botão da direita sobre a pasta “www” “repo.git” e selecione Dropbox > Share This Folder. Inclua o email dos desenvolvedores do seu grupo que devem ter uma conta Dropbox associada a esse email. Se tiver dúvidas de como fazer isso, acesse a página de ajuda do Dropbox.

3º Passo – Trabalhando localmente e realizando commits

Abra novamente a sua GUI do GIT e selecione “clonar um repositório”. Selecione a pasta onde você vai trabalhar localmente (no Mac eu costumo usar a pasta “Sites”). O repositório master será sua pasta local e a origem será o repositório compartilhado no Dropbox.

Edite localmente os arquivos (use o Xampp para rodar PHP e MySQL na sua máquina) e quando terminar realize um commit para consolidar os arquivos e depois envie essas alterações para o repositório origem através do comando PUSH. Os outros desenvolvedores trabalharão da mesma forma e o repositírio origem no Dropbox terá todas os arquivos atualizados.

Usando o GitHub como alternativa ao Dropbox

O GitHub é uma ótima alternativa para compartilhar um ambiente de desenvolvimento em GIT. Para repositório públicos o uso é gratuito, mas para repositórios fechados é preciso pagar pelo serviço. Eles lançaram recentemente uma fácil e prática GUI chamada Github for Mac.

Conclusão

Pode parecer um pouco complicado no início, mas trabalhar com GIT é bem simples e você logo se acostuma. Depois de passar pela curva inicial de aprendizado você terá uma ambiente compartilhado eficiente e com um ótimo histórico e documentação das alterações realizadas. Dúvidas? Deixe um comentário que eu tentarei responder.

UPDATE: Como lembrou o Eder Prado nos comentários, os arquivos HTML da sua pasta local não aparecem normalmente na pasta do Dropbox, eles ficam compactados dentro da pasta .git.

A nova interface da página inicial de busca

O Google apresentou sua nova interface com o lançamento do Google+. Ela será aplicada gradualmente em todos os produtos da empresa, mas já pode ser vista nas páginas de busca, no Calendário e no Gmail (usando o tema “Preview”).

É uma revolução para uma empresa conhecida por testar 41 variações de azul e que sempre seguiu a filosofia do design funcionalista (forma seguindo a função). Um dos responsáveis por isso é Andy Hertzfeld, membro da equipe que criou o primeiro Apple Macintosh e atualmente responsável pelo design do Google+.

A nova interface é fundamentada em três princípios: Foco, Flexibilidade e Facilidade.

• Foco: Se você estiver na pesquisa do Google, enviando um e-mail ou olhando um mapa, sua única preocupação deve ser conseguir o que deseja. Nosso trabalho é oferecer as ferramentas e os recursos para que você alcance seu objetivo de maneira rápida e fácil. Com as mudanças de design que ocorrerão nas próximas semanas e meses, vamos colocar em primeiro plano as coisas que importam para você, tirando tudo que atrapalhar da frente. Até mesmo alterações simples, como estabelecer cores mais fortes para botões ou ocultar botões de navegação até que você precise deles, podem ajudar a focalizar apenas no que você necessita no momento.

• Flexibilidade: No começo, havia praticamente apenas uma maneira de usar o Google: em um computador de mesa com um monitor de tamanho normal. Mais de uma década depois, basta você dar uma olhada, no escritório ou em sua casa, nos celulares, tablets, televisores e monitores de alta resolução para ver uma infinidade de maneiras de acessar a web. O novo design permitirá, em breve, uma transição sem transtornos de um dispositivo para outro, com uma experiência visual sólida. Nosso objetivo é oferecer esta flexibilidade sem sacrificar estilo ou função.

• Facilidade: Nossa filosofia de design é combinar poder com simplicidade. Queremos manter o visual simples e limpo. Mas, por trás do design aparentemente simples, usamos novas tecnologias, como HTML5, WebGL e os navegadores mais novos e rápidos, para garantir que você tenha todo o poder da web em suas mãos.

via googlebrasilblog.blogspot.com

A atual complexidade dos websites e aplicativos torna cada vez mais abrangente a função de um designer dentro do processo de desenvolvimento web. Arquitetura de informação, usabilidade, interface gráfica, HTML, CSS, e até JavaScript são habilidades comuns para um profissional com poucos anos de experiência. O conceito de UX (User Experience) expande ainda mais essa esfera de atuação.

Essa visão abrangente do processo tem transformado designer em ótimos gestores. Na 37signals, por exemplo, cada time é formado por 2 programadores e 1 designer, sendo este também responsável pela gestão do projeto.

Cindy Chastain, diretora de criação da R/GA, fez uma interessante analogia comparando o trabalho do designer ao de um diretor de cinema, que é responsável por manter o conjunto e a harmonia na produção do filme.

Para Aarron Walter, da MailChimp, o designer acaba sendo um diplomata dentro do projeto, negociando cada alteração e traduzindo o idioma de cada departamento. Ele deixa claro que essa função não supre a necessidade de um gerente de projeto, principalmente com relação a controle de orçamento, prazos e relação com o cliente.

Acredito que designers tendem a ser mais generalistas porque precisam olhar o projeto como um todo. Um arquiteto de informação precisa testar a usabilidade do início ao fim do projeto, um designer de interface precisa participar da montagem HTML e verificar a instalação do CMS.